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. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs