Public bug reported: The GNU GRUB Manual 2.12 contains the following:
"GRUB avoids this problem nowadays by using UUIDs or file system labels when generating grub.cfg, and we advise that you do the same for any custom menu entries you write." (4.3 The map between BIOS drives and OS devices) The manual further explains three variables that control grub.cfg use of dev, partUUID, or UUID, additionally providing a logic table; those variables being: ‘GRUB_DISABLE_LINUX_UUID’, ‘GRUB_DISABLE_LINUX_PARTUUID’, ‘GRUB_DISABLE_UUID’ and further explains: "Normally, grub-mkconfig will generate menu entries that use universally-unique identifiers (UUIDs) to identify the root filesystem to the Linux kernel," (6.1 Simple configuration handling) 6.2 Root Identifcation Heuristics then explains the details of which identifier will be used: UUID, part UUID, or dev name [ref https://www.gnu.org/software/grub/manual/grub/grub.html] --- From all this, me as a user, gleans the following: grub.cfg *normal use case* produces: Linux root device = UUID. Except it doesn't. Further reading the manual, LVM receives mention, specifically on the issue of LVM cache. LUKS also receives mention, which we'll return to. --- USE CASE and ENCOUNTERED BUG I recently installed Linux Mint (downstream of ubuntu) on an Acer Nitro ANV15-51. Install consisted of replacing the stock nvme, with 2x Crucial T500 1TB PCIe Gen4 NVMe M.2 SSD - so completely blank disk space. Multiple hard drives have been around since x486 days, and though once extremely rare on laptop, seem to be more common. I've used full disk encryption on my Linux installs for the last decade, and upon understanding how LUKS used the device mapper, deciding to use LVM seemed trivial. The first disk space contains /boot, EFI, LUKS - within LUKS, an LVM for root (logical vol); second drive LUKS - within LUKS extended physical volume extending the volume mananger for home (logical vol). I immediately encountered an issue, with doing a custom install, namely GRUB got stuck, waiting for an interactive encryption key that it didn't prompt for. As a work around, I tried to see if the default, blast the storage volume, and install Mint would work, which it did. However, post- installation, I wanted to change the LVM Volume Group name. I had a number of hard drives from previous systems, that I wanted to pull data from, and to additionally future proof my drives, I try to name the Volume Group off something based on the unique hardware - i.e. vg_ANV15-51. This caused the issue I am now reporting. Were both the /boot/grub/grub.cfg and /etc/fstab using UUIDs, the vgrename would have been trivial. Rename, reboot. When digging into the issue, on why dev was used instead of UUID, I drilled down to this (~line 52): # btrfs may reside on multiple devices. We cannot pass them as value of root= parameter # and mounting btrfs requires user space scanning, so force UUID in this case. if ( [ "x${GRUB_DEVICE_UUID}" = "x" ] && [ "x${GRUB_DEVICE_PARTUUID}" = "x" ] ) \ || ( [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ] \ && [ "x${GRUB_DISABLE_LINUX_PARTUUID}" = "xtrue" ] ) \ || ( ! test -e "/dev/disk/by-uuid/${GRUB_DEVICE_UUID}" \ && ! test -e "/dev/disk/by-partuuid/${GRUB_DEVICE_PARTUUID}" ) \ || ( test -e "${GRUB_DEVICE}" && uses_abstraction "${GRUB_DEVICE}" lvm ); then LINUX_ROOT_DEVICE=${GRUB_DEVICE} elif [ "x${GRUB_DEVICE_UUID}" = "x" ] \ || [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ]; then LINUX_ROOT_DEVICE=PARTUUID=${GRUB_DEVICE_PARTUUID} else LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID} fi [ref grub-2.12/util/grub.d/10_linux.in] My knowledge of bash scripting isn't the greatest, and without knowing how "x${}" = "x" or "x${}" = "xtrue", it seems to me, under a btrfs comment, if GRUB encounters Linux using LVM, LINUX_ROOT_DEVICE=${GRUB_DEVICE} applies, contrary to the manual. As an inelegant work around, I commented around thru ~ line 66, leaving LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID} intact. --- Further thoughts LVM caching, and in turn, LVM raid, both provide a UUID indicating the group of devices. This would still satisfy GRUB's LINUX_ROOT_DEVICE being a UUID, rather than a dev mapping. Having learned the complications of LVM, caching and RAID were both added on secondarily, thus indicating the primary use case of LVM is singular logical volume with a volume group. LUKS, by contrast, also "uses_abstraction", so the logic under the btrfs comment seems like a kludge. Lastly, the issue of a Linux Mint custom install incorrectly handling interactive prompt for encryption keys, appears to be addressed, and solved with: sudo vi /etc/initramfs-tools/hooks/00-crypttab #!/bin/sh cp /etc/crypttab "${DESTDIR}/cryptroot/crypttab" exit 0 sudo chmod +x /etc/initramfs-tools/hooks/00-crypttab Itself, perhaps another bug. [ref https://unix.stackexchange.com/questions/708445/etc-crypttab-not-updating-in-initramfs] kuroi-tonbo ~ 20:15 lsb_release -rd No LSB modules are available. Description: Linux Mint 22.1 Release: 22.1 kuroi-tonbo ~ 20:17 apt-cache policy grub2-common grub2-common: Installed: 2.12-1ubuntu7.3 Candidate: 2.12-1ubuntu7.3 lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:0 0 931.5G 0 disk ├─nvme0n1p1 259:3 0 512M 0 part /boot/efi ├─nvme0n1p2 259:4 0 2G 0 part /boot └─nvme0n1p3 259:5 0 729G 0 part └─nvme0n1p3_luks 252:0 0 729G 0 crypt └─vg_ANV15--51-lv_root 252:2 0 100G 0 lvm / nvme1n1 259:1 0 931.5G 0 disk └─nvme1n1p1 259:2 0 731.5G 0 part └─nvme1n1p1_luks 252:1 0 731.5G 0 crypt └─vg_ANV15--51-lv_home 252:3 0 640G 0 lvm /home ** Affects: grub2 (Ubuntu) Importance: Undecided Status: New ** Tags: dev grub installation luks lvm mapper uuid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2115932 Title: 10_linux.io & LVM incorrectly builds grub.cfg with Root=dev To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2115932/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
