...JuergIs there ongoing work for this (automated builiding/booting/testing)?
On Wed, Jul 9, 2014 at 9:29 PM, Anders Ingemann <email@example.com> wrote:
> On 9 July 2014 21:09, Tomasz Rybak <firstname.lastname@example.org> 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
>> I've found GRUB bug related to UUIDs but I am not sure whether
>> it is related to our case or not:
>> I also tried fix proposed in
>> 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
> 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.