group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1379080@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package cloud-init - 0.7.5-0ubuntu1.22

---------------
cloud-init (0.7.5-0ubuntu1.22) trusty; urgency=medium

  * debian/update-grub-legacy-ec2:
    - Correctly detect kernels ending in -aws as kernels that can boot on EC2
      (LP: #1655934)
    - Consider kernels with CONFIG_XEN=y bootable on aws. (LP: #1379080)

 -- Scott Moser <smoser@xxxxxxxxxx>  Thu, 08 Jun 2017 19:25:41 -0400

** Changed in: cloud-init (Ubuntu Trusty)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1379080

Title:
  update-grub-legacy-ec2 fails to detect xen kernel

Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Trusty:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released

Bug description:
  The update-grub-legacy-ec2 script (which ships with grub-legacy-ec2,
  which is presumably included under cloud-init umbrella) includes a
  check to determine whether a kernel is Xen-capable or not. It uses
  this check in a feature designed to ignore non-Xen kernels on Xen
  guests, presumably as a safety mechanism. The way in which the check
  is executed is flawed - it matches against the kernel name. This means
  that if you are loading a kernel that has an 'unexpected' name,
  update-grub-legacy-ec2 will ignore the new kernel, regardless of
  whether or not it is actually Xen-capable. Output looks like this:

  Searching for GRUB installation directory ... found: /boot/grub
  Searching for default file ... found: /boot/grub/default
  Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
  Searching for splash image ... none found, skipping ...
  Ignoring non-Xen Kernel on Xen domU host: vmlinuz-3.13.0-36-custom
  Found kernel: /boot/vmlinuz-3.13.0-36-generic
  Updating /boot/grub/menu.lst ... done

  This has been fixed on grub-legacy. Instead of matching the kernel
  name, it checks the config for CONFIG_XEN=y. In addition, Linux
  kernels come with CONFIG_XEN=y by default for some time now, and it is
  perfectly safe to run a Xen-capable kernel on non-Xen hosts.

  Steps to reproduce:
  1. Compile and generate debs for custom kernel with version string not including '-generic' or '-virtual'
  2. Install debs on ec2 system (ami-a94e0c99)
  3. Reboot

  Expected results:
  System comes up with new kernel

  Actual results:
  System comes up with old kernel, and new kernel is not present in /boot/grub/menu.lst

  Impact:
  Running ami-a94e0c99, and likely many others, a user can not install a custom kernel without manually editing files. Furthermore, those writes will likely be overwritten by administrative operations in the future.

  Recommendation:
  Update detection logic to search for CONFIG_XEN=y in the kernel config, and remove version string detection.

  Please let me know how I can help this along. I can submit a proposed
  fix, but am not sure where to send it.

  Related bugs:
   * bug 1655934: update-grub-legacy-ec2 should detect -aws kernels as appropriate for EC2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1379080/+subscriptions