[Bug 665235] Re: attaching a volume to maverick instance may boot off it

[Scott Moser]

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.

-- 
attaching a volume to maverick instance may boot off it
https://bugs.launchpad.net/bugs/665235
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in ubuntu.