Processed: Re: Bug#1086685: cryptsetup-initramfs: Fails to include all LUKS LVM PVs required to activate VG

[Debian Bug Tracking System]

unarchive 1018730

Bug #1018730 {Done: Bastian Blank <***@debian.org>} [lvm2] lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure
Bug #1034836 {Done: Bastian Blank <***@debian.org>} [lvm2] initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Bug #1038731 {Done: Bastian Blank <***@debian.org>} [lvm2] initramfs-tools: LVM setup becomes unbootable when adding to the VG additional encrypted PVs
Unarchived Bug 1018730
Unarchived Bug 1034836
Unarchived Bug 1038731

reassign -1 lvm2 2.03.15-1

Bug #1086685 [cryptsetup-initramfs] cryptsetup-initramfs: Fails to include all LUKS LVM PVs required to activate VG
Bug reassigned from package 'cryptsetup-initramfs' to 'lvm2'.
No longer marked as found in versions cryptsetup/2:2.6.1-4~deb12u2.
Ignoring request to alter fixed versions of bug #1086685 to the same values previously set
Bug #1086685 [lvm2] cryptsetup-initramfs: Fails to include all LUKS LVM PVs required to activate VG
Marked as found in versions lvm2/2.03.15-1.

forcemerge 1018730 -1

Bug #1018730 {Done: Bastian Blank <***@debian.org>} [lvm2] lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure
Bug #1034836 {Done: Bastian Blank <***@debian.org>} [lvm2] initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Bug #1038731 {Done: Bastian Blank <***@debian.org>} [lvm2] initramfs-tools: LVM setup becomes unbootable when adding to the VG additional encrypted PVs
Bug #1086685 [lvm2] cryptsetup-initramfs: Fails to include all LUKS LVM PVs required to activate VG
Severity set to 'serious' from 'important'
Marked Bug as done
Added indication that 1086685 affects cryptsetup-initramfs
Marked as found in versions lvm2/2.03.16-1.
Added tag(s) patch.
Bug #1034836 {Done: Bastian Blank <***@debian.org>} [lvm2] initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Bug #1038731 {Done: Bastian Blank <***@debian.org>} [lvm2] initramfs-tools: LVM setup becomes unbootable when adding to the VG additional encrypted PVs
Merged 1018730 1034836 1038731 1086685

affects -1 cryptsetup-initramfs

Bug #1086685 {Done: Bastian Blank <***@debian.org>} [lvm2] cryptsetup-initramfs: Fails to include all LUKS LVM PVs required to activate VG
Bug #1018730 {Done: Bastian Blank <***@debian.org>} [lvm2] lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure
Bug #1034836 {Done: Bastian Blank <***@debian.org>} [lvm2] initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Bug #1038731 {Done: Bastian Blank <***@debian.org>} [lvm2] initramfs-tools: LVM setup becomes unbootable when adding to the VG additional encrypted PVs
Ignoring request to set affects of bug 1086685 to the same value previously set
Ignoring request to set affects of bug 1018730 to the same value previously set
Ignoring request to set affects of bug 1034836 to the same value previously set
Ignoring request to set affects of bug 1038731 to the same value previously set

[Tj]

Package: lvm2
Version: 2.03.16-2
Followup-For: Bug #1086685
X-Debbugs-Cc: ***@proton.me

This really is not an lvm problem; lvm never should try to activate an
incomplete volume group especially if some of the logical volumes span
the physical volume that is missing - and that is the case here due to
the cryptroot hook script not ensuring all PVs within an encrypted
container are configured to unlock.

I wrote a small patch yesterday that handles it correctly. I need to
work up some tests to ensure it doesn't cause any regressions elsewhere
but it is quite simple.

I'll add a merge request once it is ready.

[Guilhem Moulin]

Post by Tj
This really is not an lvm problem; lvm never should try to activate an
incomplete volume group especially if some of the logical volumes span
the physical volume that is missing - and that is the case here due to
the cryptroot hook script not ensuring all PVs within an encrypted
container are configured to unlock.

On a sid system, after creating a new PV and extending the LV holding /
to use some of its extents, the new PV shows up in its slaves devices
and is configured to unlock at initramfs stage.

Post by Tj
I wrote a small patch yesterday that handles it correctly. I need to
work up some tests to ensure it doesn't cause any regressions elsewhere
but it is quite simple.
I'll add a merge request once it is ready.

I'm reluctant to accept LVM-specific handling for what I consider a
regression outside src:cryptsetup.