grub-legacy-ec2: attaching a volume to maverick instance may boot off it

[Scott Moser]

Binary package hint: grub-legacy-ec2

I booted a maverick instance, modified it a bit, and created a snapshot of that volume.

I then, booted another maverick instance like:
run-instances ami-548c783d --instance-type t1.micro --block-device-mapping /dev/sdh=${SNAPSHOT}:${SIZE}

the surprising result was that the instance booted with root = /dev/sdh.

The reason for that is that menu.lst in the instance says:
kernel /boot/vmlinuz-2.6.35-22-virtual root=LABEL=uec-rootfs ro console=hvc0
initrd /boot/initrd.img-2.6.35-22-virtual

In this instance, there were, then 2 filesystems that had LABEL=uec-rootfs.
The kernel just chose /dev/sdh.

update-grub-legacy-ec2 is what writes the 'LABEL=uec-rootfs'.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: cloud-init 0.5.15-0ubuntu3
ProcVersionSignature: User Name 2.6.35-22.33-virtual 2.6.35.4
Uname: Linux 2.6.35-22-virtual x86_64
Architecture: amd64
Date: Fri Oct 22 17:19:50 2010
Ec2AMI: ami-548c783d
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: t1.micro
Ec2Kernel: aki-427d952b
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: cloud-init

[Clint Byrum (clint-fewbar)]

I tried the same steps and did not get /dev/sdh as the root, but I see that they do both have the same label, and concur that labels may not be the best way to differentiate these volumes.

UUID also isn't unique, so I'm at a loss to identify a good way to determine which is which.

Either way, this is definitely an undesirable behavior, so I'm marking this Confirmed.

[Eric Hammond (esh)]

EBS volumes and snapshots create this sort of problem regularly for me, generally with conflicting duplicate XFS UIDs which I have to override.

The best solution for EC2 AMIs may be to always accept that /dev/sda1 is the boot disk.

[Scott Moser (smoser)]

On Sat, 6 Nov 2010, Eric Hammond wrote:

> EBS volumes and snapshots create this sort of problem regularly for me,
> generally with conflicting duplicate XFS UIDs which I have to override.
>
> The best solution for EC2 AMIs may be to always accept that /dev/sda1 is
> the boot disk.

Well, I chose to use label because LABEL= is much "newer" way of booting,
and with UUID even more so. I would have used UUID, but at the time that
the initial /boot/grub/menu.lst is written in the vmbuilder code, there is
no UUID because the filesystem has not been written yet (its in a chroot).

update-grub-legacy-ec2 is what ends up writing this. That is largely a
copy of 'update-grub' from the 'grub' package (not grub2). I
intentionally left as much the same as I could get a way with. Because of
that, the problem is even further complicated because when
update-grub-legacy-ec2 runs (on kernel installation or dpkg-reconfigure),
it will end up writing with UUID (which is its prefered mechanism).

That behavior was generally OK to me, but can cause other issues (just as
label does) like bug 671427.

/dev/sda1 does seem like the simplest answer, but its not ideal for 2
reasons
a.) /dev/sda1 is really not what the device should be named (we carry a
patch to turn xen pv disk devices from xvdX to sdX)
b.) on UEC (and on openstack) the root device is likely to be named
/dev/vda1. This is not *really* a problem, as grub2 loads the kernels on
UEC and pv-grub via update-grub-legacy-ec2's /boot/grub/menu.lst does so
on ec2.

So, lost of info there, but thats why its not as simple as it might first
appear.

[Scott Moser (smoser)]

Two more things to note
1.) I just opened bug 672986 that euca-bundle-vol should copy uuid
2.) above, I stated that grub2 loads the kernel on uec and pv-grub. It may have similar issues.

[Scott Moser (smoser)]

I've added that this "also effects" ubuntu-on-ec2. The reason being that the images are created with lp:~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/ , and the vmbuilder-fixups has some code that would have to change to get this sorted.