[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GRUB and HVM on EC2



On Thu, Jul 10, 2014 at 4:35 AM, Juerg Haefliger <juergh@gmail.com> wrote:
>
>
>
> On Thu, Jul 10, 2014 at 9:35 AM, Anders Ingemann <anders@ingemann.de> wrote:
>>
>> On 10 July 2014 08:52, Juerg Haefliger <juergh@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>> On Wed, Jul 9, 2014 at 9:29 PM, Anders Ingemann <anders@ingemann.de>
>>> wrote:
>>> >
>>> > On 9 July 2014 21:09, Tomasz Rybak <tomasz.rybak@post.pl> wrote:
>>> >>
>>> >> Hello everyone.
>>> >> I've been trying to understand what is going on when we try
>>> >> to build HVM Wheezy image using GRUB 1.99 on GRUB 1.99.
>>> >>
>>> >> The host is run from /dev/xvda (PVM with pvgrub).
>>> >> It contains following entries in /boot/grub/device.map
>>> >> (hd0) /dev/xvda
>>> >> (hd1) /dev/xvdf
>>> >> IMO it is left-over from creation of AMI; xvda is from
>>> >> host, xvdf is from AMI - and now what was xvdf during AMI
>>> >> creation is xvda when this AMI is run.
>>> >>
>>> >> Target (chroot) contains following entries in device.map
>>> >> (hd0) /dev/xvdf
>>> >> (hd0,msdos1) /dev/mapper/xvdf1
>>> >> This might be the first source of problems; when I run
>>> >> grub-install with --recheck, it created device.map
>>> >> like in the first case (in host).
>>> >>
>>> >> /dev/mapper/xvdf1 points to /dev/dm-0. It points
>>> >> to it from the very beginning, it is set by kpartx -as
>>> >> Neither link_fn() nor unlink_fn() from common.tasks.boot.InstallGrub
>>> >> are called.
>>> >> Similarly, neither _before_link_dm_node nor _before_unlink_dm_node
>>> >> from base.fs.volume.Volume are called.
>>> >>
>>> >> /etc/fstab on target contains UUID, not /dev/mapper/xvdf1
>>> >> for root partition. I've tried changing that, but it did not help.
>>> >>
>>> >> >From my point of view, this is rather messy.
>>> >>  * we have target / mounted to /dev/mapper/xvdf1, while
>>> >> there exists /dev/xvdf1.
>>> >>  * /etc/fstab uses UUID
>>> >>  * grub-install is called with /dev/xvdf
>>> >>  * but later grub puts UUIDs into grub.cfg in root=*
>>> >>
>>> >> OTOH setting DISABLE_LINUX_UUID in grub configuration does not change
>>> >> anything.
>>> >>
>>> >> I've found GRUB bug related to UUIDs but I am not sure whether
>>> >> it is related to our case or not:
>>> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741342
>>> >>
>>> >> I also tried fix proposed in
>>> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544577#10
>>> >> but it didn't help.
>>> >>
>>> >> Currently I feel lost with all of this.
>>> >>
>>> >> Maybe time will help - it looks like GRUB from Jessie does
>>> >> not have those problems ;-). OTOH now Debian stable cannot be run
>>> >> on the new cheep (or free) machines like t2 which use HVM.
>>> >>
>>> >> Best regards.
>>> >>
>>> >> --
>>> >> Tomasz Rybak  GPG/PGP key ID: 2AD5 9860
>>> >> Fingerprint A481 824E 7DD3 9C0E C40A  488E C654 FB33 2AD5 9860
>>> >> http://member.acm.org/~tomaszrybak
>>> >>
>>> >
>>> > Nice job analyzing Tomasz. I am glad I'm not the only one looking at
>>> > this, I thought I was going completely insane and that there had to be
>>> > something simple I missed. It seems like that is not the case.
>>> > I completely agree with you regarding the mix and matching of UUIDs and
>>> > devpaths, it should be cleaned up at some point. And I feel that work would
>>> > become easier once there is an automated way of building, booting and
>>> > testing.
>>>
>>>
>>> Is there ongoing work for this (automated builiding/booting/testing)?
>>>
>>> ...Juerg
>>>
>>
>> Yes, definitely. The latest commits have been in preparation for that.
>
> Is that work/process documented anywhere? What are the plans? What images
> will be produced and how? What packages will they contain? How are they
> configured and tested and distributed? What's the build cadence and update
> strategy?
> Sorry for bombarding you with all these questions but I've been thinking
> about how to get this going (Debian building official cloud images) and in
> fact just scheduled a open discussion at the next DebConf to talk about
> this.
>
> How can I help?

Juerg, I would be interested in attending such a session. Can you provide the
link, so I can register interest? (I will unfortunately be there for <
50% of debconf.)

Thanks,
Brian


Reply to: