[Bug 665235] Re: attaching a volume to maverick instance may boot off it
Scott Moser
smoser at canonical.com
Sun Nov 7 00:19:28 GMT 2010
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.
More information about the Ubuntu-server-bugs
mailing list