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

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.

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.

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.

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.

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.