** Description changed: Binary package hint: grub2 I'm investigating backporting support for guest managed kernels into 10.04 guest UEC images. Doing so would allow 10.04 guest images that were running on EC2 and 10.10 UEC hosts to run 'apt-get dist-upgrade && reboot' and boot into their new kernel. Currently, the 10.04 guests cannot manage their own kernel under either UEC or EC2. The solution in place for 10.10 is to use grub-pc to load the kernel on UEC and legacy-grub-ec2 to load the kernel on EC2. That same solution will almost work for 10.04. The one point of failure is that 10.04 images have 2 kernels in them (linux-ec2 and linux- virtual). Currently the linux-ec2 kernel is 2.6.32.309.10 and linux- virtual is 2.6.32.25.27. That would mean that when update-grub runs, it will choose the linux-ec2 kernel as the newest, and, on reboot, the guest would reboot into that -ec2 kernel on UEC. To avoid that, we need to have update-grub explicitly ignore the -ec2 kernel. I had a discussion on this solution with cjwatson at http://irclogs.ubuntu.com/2010/11/03/%23ubuntu-devel.html . The key point of that discussion is that it will *never* be useful for the -ec2 kernel to be loaded by grub-pc. the only possible case that would occur is the future development of a grub2 based xen pv-grub. One other bit of information, is that the upgrade path from lucid to maverick is preserved. The maverick based grub-pc do not exclude the linux-ec2, but do not need to. Maverick does not include a linux-ec2 kernel (well, it is in the archive, but not updated). Thus, when a do- release-upgrade from lucid->maverick would occur, there will be a -virtual kernel installed that will appear to maverick's grub-pc to be newest. It would be selected, and all future upgrades would have -virtual kernels that were newer than -ec2 kernel. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: grub-pc 1.98-1ubuntu7 ProcVersionSignature: Ubuntu 2.6.32-309.18-ec2 2.6.32.21+drm33.7 Uname: Linux 2.6.32-309-ec2 i686 Architecture: i386 Date: Thu Nov 4 18:34:45 2010 Ec2AMI: ami-480df921 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-1d Ec2InstanceType: t1.micro Ec2Kernel: aki-6603f70f Ec2Ramdisk: unavailable ProcEnviron: PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: grub2 + + + ===== SRU Information ===== + * impact of the bug: In the maverick cycle, work was done to make instances launched from UEC images capable of managing their own kernel using grub-legacy-ec2 on EC2 and grub2-pc on UEC. Without those changes, lucid images are not able to manage their kernel. What that means is that an instance running in UEC cannot have a security upgrade applied to a kernel by a simple 'apt-get upgrade && reboot'. + In the lucid images, we have 2 flavors insalled (linux-ec2 and linux-virtual). The linux-ec2 version is higher than the linux-virtual version. As such, update-grub from grub-pc would select the the ec2 kernel for booting on UEC, and the instance would fail to reboot. + * how the bug has been addressed: In maverick, the linux-ec2 kernel was removed entirely. There is no '-ec2' kernel to be ignored. In lucid, the fix is to explicitly ignore kernels named '*-ec2'. + * minimal patch: The changes are available in my branch at [1], the diff can be seen from tip of that branch to revision 69 (current lucid-updates) [2]. + * instructions on how to reproduce the bug: + * Run grub-install /dev/sda1 and update-grub in a uec image. + * verify that the linux-ec2 kernel is the first kernel listed in /boot/grub/grub.cfg + * regression potential: The possibility for regression is very low. There is no current situation where grub-pc would ever be intended to load an Ubuntu 'linux-ec2' kernel. + -- + [1] https://code.launchpad.net/~smoser/ubuntu/lucid/grub2/lucid-kernel-upgrades + [2] http://bazaar.launchpad.net/~smoser/ubuntu/lucid/grub2/lucid-kernel-upgrades/revision/71?remember=69&compare_revid=69 + =====
-- update-grub needs to ignore linux-ec2 kernels https://bugs.launchpad.net/bugs/671097 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
