Bug#1038731: initramfs-tools: LVM setup becomes unbootable when adding to the VG additional encrypted PVs
Package: initramfs-tools
Version: 0.142
Severity: important
After upgrading one of my systems running Debian 11 to bookworm, I've noticed the system has become unbootable. I think it's due to a regression in the initramfs-tools package, that doesn't properly activate the LVM VG with the rootfs if some of its PVs are not available at the initramfs stage. This will happen when using, for example, encrypted PVs (LUKS cryptsetup), or PVs with integrity protection (integritysetup), that require proper activation by systemd. In the tests I've performed, the bug occurs as long the VG with the rootfs has some missing PV at the early initramfs stage.
----------------------------------------
Steps to reproduce (using an encrypted PV as an example, as I guess it's the most common scenario for the majority of users).
Perform a clean install of Debian 12 on a virtual machine, using LVM (you can use any of these Debian installer's options: "Guided - use entire disk and set up LMV" or "Guided - use entire disk and set up encrypted LMV")
Update everything to the latest versions available:
apt update && apt upgrade
Now add a second disk to the VM and boot it.
Create a partition for the LVM PV and format it with cryptsetup:
parted /dev/vdb mklabel gpt
Information: You may need to update /etc/fstab.
parted /dev/vdb mkpart vdb1 xfs 1MiB 100%
Information: You may need to update /etc/fstab.
cryptsetup luksFormat /dev/vdb1
WARNING!
========
This will overwrite data on /dev/vdb1 irrevocably.
Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/vdb1:
Verify passphrase:
cryptsetup open /dev/vdb1 crypt_vdb1
Enter passphrase for /dev/vdb1:
pvcreate /dev/mapper/crypt_vdb1
Physical volume "/dev/mapper/crypt_vdb1" successfully created.
(Now you can edit /etc/crypttab so that systemd activates the mapping, but this is not necessary for showing how to reproduce the bug.)
Now, extend the LVM VG with the new encrypted PV.
vgextend vg00 /dev/mapper/crypt_vdb1
Volume group "vg00" successfully extended
After the last step, the system will become unbootable and the initramfs will drop you to an emergency shell. In order for the system to be able to boot, you have to manually activate the LVM VG:
(Command issued at the initramfs shell)
vgchange -ay
WARNING: Couldn't find device with uuid yaTV5V-EkG3-3QvY-eYr4-rwfE-3U3I-vcbrA4.
WARNING: VG vg00 is missing PV yaTV5V-EkG3-3QvY-eYr4-rwfE-3U3I-vcbrA4 (last written to /dev/mapper/crypt_vdb1).
2 logical volume(s) in volume group "vg00" now active
(The warning message is expected as at this stage the VG has some missing PVs. The LV containing the rootfs can be activated because it has no extents on those missing PVs. In prior Debian versions the initramfs would properly activate such LVM VGs, with the available LVs at that time. Now a manual activation is needed.)
After exiting the initramfs shell, the system will boot just fine.
As a workaround, it's possible to split the LVM VG, so that it has no missing PVs at the initramfs stage. But there are some setups such as LVM cache that require that all involved PVs be on the same VG, so there is some loss of functionality with this workaround.
vgsplit vg00 vg01 /dev/mapper/crypt_vdb1
After the last step, the system will again boot fine.
----------------------------------------
Expected results: the initramfs should behave in a similar way to previous versions, activating the LVM LVs available at that stage, so that the rootfs can be properly mounted.
Reply to: