** Description changed: - I triaged this to cryptsetup 2:2.7.0-1ubuntu4.2, and to whatever version - of the ubuntu installer was used to build my 24.04.03 system. + Affects: + * cryptsetup version 2:2.7.0-1ubuntu4.2 + * Ubuntu 24.04.3 installer (subiquity / d-i variant used to produce 24.04.3 images) - System fails to boot, drops into busybox rescue shell in initramfs on - first boot after a fresh installation of Ubuntu 24.04.03. This is - because the encrypted logical volume isn't present due to LVM - initialization failure, due to incomplete decryption of underlying - physical volumes. + Symptoms: + * Fresh install fails to boot. + * System drops to initramfs BusyBox shell on first boot. + * Root LV is missing because LVM never activates the VG. + * LVM activation fails because one or more encrypted PVs are not decrypted, leaving the VG incomplete. - System is configured with the root partition on a LV (logical volume) on - a VG (volume group) created across two encrypted PVs (physical volumes, - here they are two partitions each on separate disks). + Conditions: + * Root filesystem is on an LVM logical volume. + * LVM VG spans two encrypted PVs, each on its own disk. + * Failure occurs during initramfs stage inside /usr/share/initramfs-tools/hooks/cryptroot and the dynamic generation of /cryptroot/crypttab. + * Occurs immediately after a fresh installation of Ubuntu 24.04.3. + * Reproducible 100% on first boot. - There are two bugs in play, from my perspective: - 1. Installer-related: In /etc/crypttab in /target on the fresh install, - the installer didn't include the initramfs option for the PVs it - created. + Why + --- - This made it so the logic in /usr/share/initramfs-tools/hooks/cryptroot - didn't simply copy the entries over from /etc/crypttab when building the - initrd image. Instead, it fell back to trying to automatically detect - the necessary encrypted volumes to dynamically build /cryptroot/crypttab - inside the image. + Two independent bugs interact: - The process of building the list of volumes looks up the major/minor - number of the root filesystem, checks entries under - /sys/dev/block/<major>:<minor>/slaves, and captures those in the list. + --- - This can fall apart when the logical volume for the root filesystem - resides entirely within one physical volume on the volume group. The - volume group will not scan successfully unless all physical volumes - within it are decrypted, so the logical volume will not be available at - boot until all of the physical volumes are decrypted. + 1. Installer Bug: Missing initramfs Option in /etc/crypttab - One fix that could work here is for the Ubuntu installer to make sure - the partitions it adds to /etc/crypttab to support the volume group - containing the root filesystem's logical volume have the initramfs - option set. If this is done, update-initramfs will reliably copy those - entries into /cryptroot/crypttab and allow for successful bootup. + Symptoms: + * Installer writes /target/etc/crypttab entries for PVs without the initramfs option. - Sorry, I have not patched the installer yet, I focused on the cryptsetup - patch first. + Consequence: + * update-initramfs does not copy these crypttab entries into the initramfs image. + * cryptroot hook then attempts auto-discovery of encrypted devices. - 2. cryptsetup 2:2.7.0-1ubuntu4.2 - In the cryptroot hook in the - cryptsetup package, the logic to automatically determine which encrypted - devices need to be decrypted at boot doesn't account for this particular - edge case. This may not be a common setup, but it is in fact a viable - one. I use it along with a clevis tang server to support unattended - decryption while pooling multiple disks into a larger volume group. + Failure Mechanism: - I've attached a patch against the hook in the source package that I - verified will generate the correct crypttab entries + cryptroot scans `/sys/dev/block/<major>:<minor>/slaves` to identify + underlying encrypted volumes. + + This logic fails when: + * The root LV happens to live entirely inside one PV, and + * LVM cannot scan/activate the VG until all PVs are decrypted, even if the LV’s blocks reside only on one. + + Result: + * Auto-detection misses the second encrypted PV. + * VG activation fails. + * Root LV never appears. + * Boot drops to BusyBox. + + + Proposed Fix + ------------ + Installer should always set the initramfs option for any encrypted PVs participating in the VG that contains the root LV. + + This ensures crypttab entries are reliably included in + /cryptroot/crypttab, bypassing the fragile auto-detection logic. + + --- + + 2. cryptsetup Bug: cryptroot Auto-Detection Does Not Handle Mixed-PV LVs + + Symptoms: + * The cryptroot hook tries to infer which encrypted devices to unlock based on root LV’s backing devices. + * It does not account for VGs where: + * The root LV is contained entirely within one PV, but + * The VG cannot activate unless all PVs are unlocked. + + Consequence: + * Only one PV is considered “required” for unlocking. + * Other PVs skip decryption. + * VG activation fails at boot. + * Root LV missing → initramfs shell. + + Proposed Fix + ------------ + + Patch hooks/cryptroot to ensure all PVs in a VG that contains the root + LV are added to /cryptroot/crypttab, regardless of where the LV’s + extents are physically located. + + Status: + + Patch attached: Verified to generate correct crypttab entries and fix + boot. + ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: udisks2 2.10.1-6ubuntu1.3 ProcVersionSignature: Ubuntu 6.8.0-88.89-generic 6.8.12 Uname: Linux 6.8.0-88-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.28.1-0ubuntu3.8 Architecture: amd64 CasperMD5CheckResult: pass CustomUdevRuleFiles: ubuntu--vg-ceph--osd.rules ubuntu--vg-ubuntu--lv.rules md0.rules Date: Tue Nov 25 07:37:18 2025 InstallationDate: Installed on 2025-11-25 (0 days ago) InstallationMedia: Ubuntu-Server 24.04.3 LTS "Noble Numbat" - Release amd64 (20250805.1) MachineType: System manufacturer System Product Name ProcEnviron: - LANG=en_US.UTF-8 - PATH=(custom, no user) - SHELL=/bin/bash - TERM=xterm-256color + LANG=en_US.UTF-8 + PATH=(custom, no user) + SHELL=/bin/bash + TERM=xterm-256color ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.8.0-88-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro - SourcePackage: udisks2 + SourcePackage: cryptsetup Symptom: storage - Title: Internal hard disk partition cannot be mounted manually + Title: + cryptroot: LVM root on VG with multiple encrypted PVs only emits one encrypted PV into /cryptroot/crypttab in initramfs after fresh install of Ubuntu 24.04 UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/13/2021 dmi.bios.release: 5.12 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2801 dmi.board.asset.tag: Default string dmi.board.name: ROG STRIX Z370-E GAMING dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2801:bd01/13/2021:br5.12:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXZ370-EGAMING:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: System manufacturer
** Summary changed: - cryptroot: LVM root on VG with multiple encrypted PVs only emits one encrypted PV into /cryptroot/crypttab in initramfs after fresh install of Ubuntu 24.04 + cryptroot: initramfs fails to include all encrypted PVs for LVM root VG spanning multiple LUKS devices after fresh Ubuntu 24.04 install ** Description changed: Affects: - * cryptsetup version 2:2.7.0-1ubuntu4.2 - * Ubuntu 24.04.3 installer (subiquity / d-i variant used to produce 24.04.3 images) + * cryptsetup version 2:2.7.0-1ubuntu4.2 (likely older versions too) + * Ubuntu 24.04.3 installer (subiquity / d-i variant used to produce 24.04.3 images) Symptoms: - * Fresh install fails to boot. - * System drops to initramfs BusyBox shell on first boot. - * Root LV is missing because LVM never activates the VG. - * LVM activation fails because one or more encrypted PVs are not decrypted, leaving the VG incomplete. + * Fresh install fails to boot. + * System drops to initramfs BusyBox shell on first boot. + * Root LV is missing because LVM never activates the VG. + * LVM activation fails because one or more encrypted PVs are not decrypted, leaving the VG incomplete. Conditions: - * Root filesystem is on an LVM logical volume. - * LVM VG spans two encrypted PVs, each on its own disk. - * Failure occurs during initramfs stage inside /usr/share/initramfs-tools/hooks/cryptroot and the dynamic generation of /cryptroot/crypttab. - * Occurs immediately after a fresh installation of Ubuntu 24.04.3. - * Reproducible 100% on first boot. - + * Root filesystem is on an LVM logical volume. + * LVM VG spans two encrypted PVs, each on its own disk. + * Failure occurs during initramfs stage inside /usr/share/initramfs-tools/hooks/cryptroot and the dynamic generation of /cryptroot/crypttab. + * Occurs immediately after a fresh installation of Ubuntu 24.04.3. + * Reproducible 100% on first boot. Why --- Two independent bugs interact: --- 1. Installer Bug: Missing initramfs Option in /etc/crypttab Symptoms: - * Installer writes /target/etc/crypttab entries for PVs without the initramfs option. + * Installer writes /target/etc/crypttab entries for PVs without the initramfs option. Consequence: - * update-initramfs does not copy these crypttab entries into the initramfs image. - * cryptroot hook then attempts auto-discovery of encrypted devices. + * update-initramfs does not copy these crypttab entries into the initramfs image. + * cryptroot hook then attempts auto-discovery of encrypted devices. Failure Mechanism: cryptroot scans `/sys/dev/block/<major>:<minor>/slaves` to identify underlying encrypted volumes. This logic fails when: - * The root LV happens to live entirely inside one PV, and - * LVM cannot scan/activate the VG until all PVs are decrypted, even if the LV’s blocks reside only on one. + * The root LV happens to live entirely inside one PV, and + * LVM cannot scan/activate the VG until all PVs are decrypted, even if the LV’s blocks reside only on one. Result: - * Auto-detection misses the second encrypted PV. - * VG activation fails. - * Root LV never appears. - * Boot drops to BusyBox. - + * Auto-detection misses the second encrypted PV. + * VG activation fails. + * Root LV never appears. + * Boot drops to BusyBox. Proposed Fix ------------ Installer should always set the initramfs option for any encrypted PVs participating in the VG that contains the root LV. This ensures crypttab entries are reliably included in /cryptroot/crypttab, bypassing the fragile auto-detection logic. --- 2. cryptsetup Bug: cryptroot Auto-Detection Does Not Handle Mixed-PV LVs Symptoms: - * The cryptroot hook tries to infer which encrypted devices to unlock based on root LV’s backing devices. - * It does not account for VGs where: - * The root LV is contained entirely within one PV, but - * The VG cannot activate unless all PVs are unlocked. + * The cryptroot hook tries to infer which encrypted devices to unlock based on root LV’s backing devices. + * It does not account for VGs where: + * The root LV is contained entirely within one PV, but + * The VG cannot activate unless all PVs are unlocked. Consequence: - * Only one PV is considered “required” for unlocking. - * Other PVs skip decryption. - * VG activation fails at boot. - * Root LV missing → initramfs shell. + * Only one PV is considered “required” for unlocking. + * Other PVs skip decryption. + * VG activation fails at boot. + * Root LV missing → initramfs shell. Proposed Fix ------------ Patch hooks/cryptroot to ensure all PVs in a VG that contains the root LV are added to /cryptroot/crypttab, regardless of where the LV’s extents are physically located. Status: Patch attached: Verified to generate correct crypttab entries and fix boot. - ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: udisks2 2.10.1-6ubuntu1.3 ProcVersionSignature: Ubuntu 6.8.0-88.89-generic 6.8.12 Uname: Linux 6.8.0-88-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.28.1-0ubuntu3.8 Architecture: amd64 CasperMD5CheckResult: pass CustomUdevRuleFiles: ubuntu--vg-ceph--osd.rules ubuntu--vg-ubuntu--lv.rules md0.rules Date: Tue Nov 25 07:37:18 2025 InstallationDate: Installed on 2025-11-25 (0 days ago) InstallationMedia: Ubuntu-Server 24.04.3 LTS "Noble Numbat" - Release amd64 (20250805.1) MachineType: System manufacturer System Product Name ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.8.0-88-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro SourcePackage: cryptsetup Symptom: storage - Title: + Title: cryptroot: LVM root on VG with multiple encrypted PVs only emits one encrypted PV into /cryptroot/crypttab in initramfs after fresh install of Ubuntu 24.04 UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/13/2021 dmi.bios.release: 5.12 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2801 dmi.board.asset.tag: Default string dmi.board.name: ROG STRIX Z370-E GAMING dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2801:bd01/13/2021:br5.12:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGSTRIXZ370-EGAMING:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: System manufacturer -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2132383 Title: cryptroot: initramfs fails to include all encrypted PVs for LVM root VG spanning multiple LUKS devices after fresh Ubuntu 24.04 install To manage notifications about this bug go to: https://bugs.launchpad.net/cryptsetup/+bug/2132383/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
