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.