| 2014-10-09 01:02:53 |
evan2645 |
bug |
|
|
added bug |
| 2014-10-09 10:59:24 |
Robie Basak |
cloud-init (Ubuntu): importance |
Undecided |
Medium |
|
| 2017-01-12 13:11:01 |
Jon Grimm |
bug |
|
|
added subscriber Jon Grimm |
| 2017-01-12 14:14:41 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/314623 |
|
| 2017-01-19 16:07:51 |
Scott Moser |
nominated for series |
|
Ubuntu Yakkety |
|
| 2017-01-19 16:07:51 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Yakkety) |
|
| 2017-01-19 16:07:51 |
Scott Moser |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-01-19 16:07:51 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Zesty) |
|
| 2017-01-19 16:07:51 |
Scott Moser |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-01-19 16:07:51 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Xenial) |
|
| 2017-01-19 16:08:00 |
Scott Moser |
cloud-init (Ubuntu Zesty): status |
New |
Fix Committed |
|
| 2017-01-19 16:08:05 |
Scott Moser |
cloud-init (Ubuntu Yakkety): status |
New |
Confirmed |
|
| 2017-01-19 16:08:09 |
Scott Moser |
cloud-init (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2017-01-19 16:08:12 |
Scott Moser |
cloud-init (Ubuntu Yakkety): importance |
Undecided |
Medium |
|
| 2017-01-19 16:08:15 |
Scott Moser |
cloud-init (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2017-01-19 16:09:26 |
Scott Moser |
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. |
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 |
|
| 2017-02-06 15:43:10 |
Brian Murray |
cloud-init (Ubuntu Xenial): status |
Confirmed |
Fix Committed |
|
| 2017-02-06 15:43:14 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-02-06 15:43:20 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2017-02-06 15:43:23 |
Brian Murray |
tags |
|
verification-needed |
|
| 2017-02-09 02:01:40 |
Scott Moser |
tags |
verification-needed |
verification-done |
|
| 2017-02-09 02:05:00 |
Scott Moser |
cloud-init (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-02-09 18:01:07 |
Łukasz Zemczak |
cloud-init (Ubuntu Yakkety): status |
Confirmed |
Fix Committed |
|
| 2017-02-09 18:01:16 |
Łukasz Zemczak |
tags |
verification-done |
|
|
| 2017-02-09 18:01:17 |
Łukasz Zemczak |
tags |
|
verification-needed |
|
| 2017-02-09 21:28:32 |
Jon Grimm |
tags |
verification-needed |
verification-done-xenial verification-needed-yakkety |
|
| 2017-02-10 13:16:16 |
Scott Moser |
tags |
verification-done-xenial verification-needed-yakkety |
verification-done-xenial verification-done-yakkety |
|
| 2017-02-22 00:42:21 |
Launchpad Janitor |
cloud-init (Ubuntu Yakkety): status |
Fix Committed |
Fix Released |
|
| 2017-02-22 00:42:33 |
Chris Halse Rogers |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-02-22 00:43:01 |
Launchpad Janitor |
cloud-init (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-06-22 12:56:35 |
Robie Basak |
cloud-init (Ubuntu Trusty): status |
New |
Fix Committed |
|
| 2017-06-22 12:56:36 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-06-22 12:56:42 |
Robie Basak |
tags |
verification-done-xenial verification-done-yakkety |
verification-done-xenial verification-done-yakkety verification-needed |
|
| 2017-06-27 13:43:06 |
Kamal Mostafa |
tags |
verification-done-xenial verification-done-yakkety verification-needed |
verification-done-trusty verification-done-xenial verification-done-yakkety |
|
| 2017-06-29 17:13:54 |
Launchpad Janitor |
cloud-init (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
