Bug#1023716: cryptsetup: cryptroot-unlock in initramfs fails with lvm
On Sun, 15 Jan 2023 at 21:49:33 +0100, Hauke Mehrtens wrote: > I have the output I see on the terminal when a monitor is connected. Unfortunately that doesn't help much, please use the aforementioned README.debug.html instructions to get a log file. > The comments look like a udev rule should create this. I can not find any > udev rule doing anything with lvm on my system. lvm2 ≥2.03.15-1 ships /usr/share/initramfs-tools/hooks/lvm2 , /lib/udev/rules.d/56-lvm.rules, and /lib/udev/rules.d/69-lvm.rules , and the hook script install both files in the initramfs image (in /usr/lib/udev/rules.d). -- Guilhem. signature.asc Description: PGP signature
Bug#1023716: cryptsetup: cryptroot-unlock in initramfs fails with lvm
On 11/9/22 15:14, Guilhem Moulin wrote: Control: tag -1 moreinfo unreproducible Hi, On Tue, 08 Nov 2022 at 22:36:39 +0100, Hauke Mehrtens wrote: Unlocking and mounting of the root partitions does not work any more from the initramfs. When I call cryptroot-unlock and provide the disk password I see some error messages about mdadm, but the bootup process does not continue. If needed I can provide the detailed messages, they are not in a log file, but only printed on screen. Normally I unlock the system over the network from the initramfs, then I do not get any error message, but the system continues to stay in initramfs. An LVM-specific regression in the `cryptroot-unlock` logic wouldn't have broken the dropbear-initramfs autopkgtests since we don't use LVM there anymore, but I tested it again after reverting the commit and the test still pass. https://salsa.debian.org/debian/dropbear/-/jobs/3489869 It looks like this when unlocking the system unsuccessfully from the initramfs over ssh: -- $ ssh root@192.168.10.15 To unlock root partition, and maybe others like swap, run `cryptroot-unlock`. BusyBox v1.35.0 (Debian 1:1.35.0-2) built-in shell (ash) Enter 'help' for a list of built-in commands. ~ # vi /scripts/local-top/cryptroot ~ # cryptroot-unlock Please unlock disk sda3_crypt: cryptsetup: sda3_crypt set up successfully ~ # -- I see nothing wrong in the above, `cryptroot-unlock` has only one job which is to unlock the disk, and that appears to have worked. Did the system terminate the remote session before 2:2.5.0-2 and continued with the boot process? If so, perhaps the boot process is now blocking on that shell session; does it help to type `exit` after `cryptroot-unlock`? Otherwise, please compare your system messages withe the aforementioned autopkgtest output, and/or provide debug output; See /usr/share/doc/cryptsetup/README.debug or https://cryptsetup-team.pages.debian.net/cryptsetup/README.debug.html for how to save it into a file. Sorry for the long delay and thank you for the pointers. I have the output I see on the terminal when a monitor is connected. This is after I successfully entered the passphrase: https://hauke-m.de/files/PXL_20230115_192349603.jpg It looks like it can not find the root volume. After issuing this command the root volume is available: lvm lvchange -a ay --sysinit -- system https://hauke-m.de/files/PXL_20230115_195232849.jpg The comments look like a udev rule should create this. I can not find any udev rule doing anything with lvm on my system. Hauke
Bug#1023716: cryptsetup: cryptroot-unlock in initramfs fails with lvm
On Wed, 09 Nov 2022 at 15:14:08 +0100, Guilhem Moulin wrote: > An LVM-specific regression in the `cryptroot-unlock` logic wouldn't have > broken the dropbear-initramfs autopkgtests since we don't use LVM there > anymore, but I tested it again after reverting the commit and the test > still pass. > >https://salsa.debian.org/debian/dropbear/-/jobs/3489869 Sorry, the correct link for the autopkgtest output is https://salsa.debian.org/debian/dropbear/-/jobs/3491358/raw . The first part is setting up the target system, then starting from “Grub loading.” (line 3172) booting into it. -- Guilhem. signature.asc Description: PGP signature
Bug#1023716: cryptsetup: cryptroot-unlock in initramfs fails with lvm
Control: tag -1 moreinfo unreproducible Hi, On Tue, 08 Nov 2022 at 22:36:39 +0100, Hauke Mehrtens wrote: > Unlocking and mounting of the root partitions does not work any more > from the initramfs. When I call cryptroot-unlock and provide the disk > password I see some error messages about mdadm, but the bootup process > does not continue. If needed I can provide the detailed messages, they > are not in a log file, but only printed on screen. Normally I unlock the > system over the network from the initramfs, then I do not get any error > message, but the system continues to stay in initramfs. An LVM-specific regression in the `cryptroot-unlock` logic wouldn't have broken the dropbear-initramfs autopkgtests since we don't use LVM there anymore, but I tested it again after reverting the commit and the test still pass. https://salsa.debian.org/debian/dropbear/-/jobs/3489869 > It looks like this when unlocking the system unsuccessfully from the > initramfs over ssh: > -- > $ ssh root@192.168.10.15 > To unlock root partition, and maybe others like swap, run > `cryptroot-unlock`. > > BusyBox v1.35.0 (Debian 1:1.35.0-2) built-in shell (ash) > Enter 'help' for a list of built-in commands. > > ~ # vi /scripts/local-top/cryptroot > ~ # cryptroot-unlock > Please unlock disk sda3_crypt: > cryptsetup: sda3_crypt set up successfully > ~ # > -- I see nothing wrong in the above, `cryptroot-unlock` has only one job which is to unlock the disk, and that appears to have worked. Did the system terminate the remote session before 2:2.5.0-2 and continued with the boot process? If so, perhaps the boot process is now blocking on that shell session; does it help to type `exit` after `cryptroot-unlock`? Otherwise, please compare your system messages withe the aforementioned autopkgtest output, and/or provide debug output; See /usr/share/doc/cryptsetup/README.debug or https://cryptsetup-team.pages.debian.net/cryptsetup/README.debug.html for how to save it into a file. -- Guilhem. signature.asc Description: PGP signature
Bug#1023716: cryptsetup: cryptroot-unlock in initramfs fails with lvm
Package: cryptsetup Version: 2:2.5.0-6 Severity: important Dear Maintainer, Unlocking and mounting of the root partitions does not work any more from the initramfs. When I call cryptroot-unlock and provide the disk password I see some error messages about mdadm, but the bootup process does not continue. If needed I can provide the detailed messages, they are not in a log file, but only printed on screen. Normally I unlock the system over the network from the initramfs, then I do not get any error message, but the system continues to stay in initramfs. It looks like this when unlocking the system unsuccessfully from the initramfs over ssh: -- $ ssh root@192.168.10.15 To unlock root partition, and maybe others like swap, run `cryptroot-unlock`. BusyBox v1.35.0 (Debian 1:1.35.0-2) built-in shell (ash) Enter 'help' for a list of built-in commands. ~ # vi /scripts/local-top/cryptroot ~ # cryptroot-unlock Please unlock disk sda3_crypt: cryptsetup: sda3_crypt set up successfully ~ # -- The system was installed using Debian bookworm in July 2022 and unlocking worked fine at that time. Then this change was introduced which broke the unlocking: https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/3854ce68641ba84b04df35828ccb9abcb569e5c6 When I revert this change and generate a new initramfs it works again. Hauke -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-6.0.0-2-amd64 root=/dev/mapper/system-root ro rd.luks.options=discard -- /etc/crypttab sda3_crypt UUID=aabe34b0-d2e8-4e3f-9243-655acdc286bc none luks,discard data1_crypt UUID=d835f05f-a68d-445a-b7b0-75092049d23b /etc/cryptkeyfile luks data2_crypt UUID=e2cf01d0-2982-48b0-837f-d83cf1445185 /etc/cryptkeyfile luks -- /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # systemd generates mount units based on this file, see systemd.mount(5). # Please run 'systemctl daemon-reload' after making changes here. # # /dev/mapper/system-root / ext4errors=remount-ro 0 1 # /boot was on /dev/sda2 during installation UUID=1a2f9f2a-4d12-49bf-a170-bb6536cf2a97 /boot ext4 defaults0 2 # /boot/efi was on /dev/sda1 during installation UUID=25FC-83BA /boot/efi vfatumask=0077 0 1 /dev/mapper/system-swap noneswapsw 0 0 -- lsmod Module Size Used by vhost_net 36864 2 vhost 57344 1 vhost_net vhost_iotlb16384 1 vhost tap28672 1 vhost_net tun61440 5 vhost_net ctr16384 2 ccm20480 6 dm_cache_smq 28672 1 dm_cache 73728 2 dm_cache_smq dm_persistent_data106496 1 dm_cache dm_bio_prison 20480 1 dm_cache dm_bufio 40960 1 dm_persistent_data qrtr 49152 4 dm_raid45056 3 bridge311296 0 stp16384 1 bridge llc16384 2 bridge,stp binfmt_misc24576 1 nls_ascii 16384 1 nls_cp437 20480 1 vfat 24576 1 intel_rapl_msr 20480 0 fat90112 1 vfat intel_rapl_common 28672 1 intel_rapl_msr amdgpu 9347072 0 iwlmvm376832 0 btusb 65536 0 btrtl 28672 1 btusb btbcm 24576 1 btusb btintel45056 1 btusb btmtk 16384 1 btusb mac80211 1159168 1 iwlmvm bluetooth 954368 6 btrtl,btmtk,btintel,btbcm,btusb snd_hda_codec_hdmi 81920 1 libarc416384 1 mac80211 snd_hda_intel 57344 0 edac_mce_amd 40960 0 snd_intel_dspcfg 36864 1 snd_hda_intel jitterentropy_rng 16384 1 iwlwifi 356352 1 iwlmvm snd_intel_sdw_acpi 20480 1 snd_intel_dspcfg snd_hda_codec 184320 2 snd_hda_codec_hdmi,snd_hda_intel gpu_sched 53248 1 amdgpu sha512_ssse3 49152 1 kvm_amd 155648 4 sha512_generic 16384 1 sha512_ssse3 drm_buddy 20480 1 amdgpu eeepc_wmi 16384 0 drm_display_helper184320 1 amdgpu evdev 28672 2 snd_hda_core 122880 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec drbg 45056 1 kvm 1122304 1 kvm_amd asus_wmi 61440 1 eeepc_wmi cec61440 1 drm_display_helper cfg80211 1118208 3 iwlmvm,iwlwifi,mac80211 rc_core69632 1 cec snd_hwdep 16384 1 snd_hda_codec drm_ttm_helper 16384 1 amdgpu ansi_cprng 16384 0 platform_profile
