[Bug 2115932] [NEW] 10_linux.io & LVM incorrectly builds grub.cfg with Root=dev
Justin M. Bennett
2115932 at bugs.launchpad.net
Fri Jul 4 01:12:28 UTC 2025
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
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/2115932
Title:
10_linux.io & LVM incorrectly builds grub.cfg with Root=dev
Status in grub2 package in Ubuntu:
New
Bug description:
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2115932/+subscriptions
More information about the foundations-bugs
mailing list