cc_grub_dpkg: determine idevs in a more robust manner with grub-probe
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
Undecided
|
Matthew Ruffell |
Bug Description
Currently, we populate the debconf database variable grub-pc/
- /dev/sda
- /dev/vda
- /dev/xvda
- /dev/sda1
- /dev/vda1
- /dev/xvda1
[1] https:/
While this is a simple elegant solution, the hardcoded list does not match real world conditions, where grub is installed to a disk which is not on this list.
The primary example is any cloud which uses NVMe storage, such as AWS c5 instances.
/dev/nvme0n1 is not on the above list, and in this case, falls back to a hardcoded /dev/sda value for grub-pc/
The thing is, the grub postinstall script [2] checks to see if the value from grub-pc/
[2] https:/
[3] https:/
This breaks scripts that don't set DEBIAN_
I propose that we modify the cc_grub_dpkg module to be more robust at selecting the correct disk grub is installed to.
Why not simply add an extra directory to the hardcoded list?
Lets take NVMe storage as an example again. On a c5d.large instance I spun up just now, lsblk returns:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 46.6G 0 disk
nvme1n1 259:1 0 8G 0 disk
└─nvme1n1p1 259:2 0 8G 0 part /
We cannot hardcode /dev/nvme0n1, as the NVMe naming conventions are not stable in the kernel, and some boots the 8G disk will be /dev/nvme0n1, and others will be /dev/nvme1n1.
Instead, I propose that we determine which grub has been installed to by following the grub2 debian/postinst.in script, and implementing the algorithm behind usable_
[3] https:/
This uses grub-probe to find the root disk where the /boot directory is located, and then turns the disk name into a /dev/disk/by-id/ value.
This is robust to unstable kernel device naming conventions.
On Nitro, this returns:
/dev/disk/
On Xen, this returns:
/dev/xvda
On a typical QEMU/KVM machine, this returns:
/dev/vda
On my personal desktop computer, this returns:
/dev/disk/
I have tested this on AWS, on Xen, Nitro, on KVM, with BIOS and EFI based instances, in LXC, and on bare metal with a BIOS based MAAS machine.
All give the correct results in my testing.
TESTING:
You can fetch grub-pc/
$ echo get grub-pc/
Reset with:
$ echo reset grub-pc/
description: | updated |
Changed in cloud-init: | |
status: | In Progress → Fix Committed |
summary: |
- cc_grub_dpkg: determine idevs in a more robust manner with grub- - mkdevicemap + cc_grub_dpkg: determine idevs in a more robust manner with grub-probe |
Upstream pull request: https:/ /github. com/canonical/ cloud-init/ pull/358