LVM on LUKS no password asked
emperor06 opened this issue · comments
Booster does not ask for my luks password at boot. I must be missing something but I can't figure out what.
The system is a basic lvm-on-luks with /boot on a separate partition. It happens both on bare metal and on VM, with both CachyOS and EndeavourOS.
# lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 vfat FAT32 ESP 1429-BF09 298,8M 0% /boot/efi
├─sda3 ext4 1.0 cachy-boot fbbf7943-ceb7-443c-977e-6bd2a03ef060 241,8M 27% /boot
└─sda5 crypto_LUKS 2 f9943df4-20d6-4955-8753-75aaa1a62bdf
└─cryptlvm LVM2_member LVM2 001 iVve05-ZEzb-TqBw-S01D-o1IX-oaTZ-f9xxJK
├─vm-swap swap 1 swap cbcaa9b3-a936-4387-9b87-cd91420fe935
├─vm-cachy_root ext4 1.0 cachy-root f49a7f65-d9f1-44a2-abbc-25998e86132c 10,8G 39% /
sr0
zram0
My booster config:
# cat /etc/booster.yaml
compression: zstd
mount_timeout: 15s
strip: true
extra_files: nano,fsck,fsck.ext4
vconsole: true
enable_lvm: true
enable_mdraid: false
And my grub entry:
menuentry 'CachyOS Linux, with Linux linux-cachyos (booster initramfs)' --class cachyos --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-cachyos-booster-f49a7f65-d9f1-44a2-abbc-25998e86132c' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='hd0,gpt3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 fbbf7943-ceb7-443c-977e-6bd2a03ef060
else
search --no-floppy --fs-uuid --set=root fbbf7943-ceb7-443c-977e-6bd2a03ef060
fi
echo 'Loading Linux linux-cachyos ...'
linux /vmlinuz-linux-cachyos root=/dev/mapper/vm-cachy_root rw rd.luks.name=f9943df4-20d6-4955-8753-75aaa1a62bdf=cryptlvm booster.log=info,console
echo 'Loading initial ramdisk ...'
initrd /intel-ucode.img /booster-linux-cachyos.img
}
At boot, I get:
setfont parameters are not specified
loading keymap file /console/keymap
found a new device /dev/sr0
[ 1.139447] booster: /dev/sr0: open /dev/sr0: no medium found
/dev/sr0: open /dev/sr0: no medium found
[ 15.772941] booster: Timeout waiting for root filesystem
booster: Timeout waiting for root filesystem
Press ENTER to reboot
I attached my luks header.
luks_header.txt
Yeah, it look like booster does not see the crypted partition. It could be that your sda devices needs extra drivers to enumerate or there might be something else.
Could you please enable debug logs with booster.log=debug,console and then share it?
What version of booster do you use? is it the latest released version?
I wish I could give you a real log file but since the root partition cannot be unlocked, booster has nowhere to write (except maybe for /boot, I don't know if it's possible to drop the logs there).
This one is the boot from a VM. The same happens on my laptop, although I cannot be sure the debug messages are the same.
Booster version is Archlinux' extra/booster 0.11-1
Thank you @emperor06 for the screenshots.
I checked it and it looks like the sda* devices are not detected. It might be that the bus requires some extra drivers.
It is difficult to grep these screnshots though, having a text logs would be easier to debug.
One way to get the debug text is to boot into an emergency shell with extra_files: busybox and enable universal: true just in case. Once you boot into the emergency shell you can inspect the host, in particular dmesg will give you the boot logs; lsmod will show what modules are loaded. You can then compare the modules list with system that boots properly and see what modules are missed.
So please add
extra_files: busybox
universal: trueinto your booster.yaml then rebuild the image, boot into it and provide output of lsmod and lsblk.
I finally got the logs. There is no writable/detected device in the initramfs so I used booster's network ability to send the logs through tftp. That's very convenient.
You'll find the output of:
- lsmod (booster, busybox)
- dmesg
- ls /dev
- lsmod (on a successful boot)
Note: blkid returns nothing (exit status 0)
Thank you @emperor06, having the debug logs makes it much easier to grep/debug the issue.
So here is the list of modaliases that booster received from kernel but misses the modules:
input:b0019v0000p0001e0000-e0,1,k74,ramlsfw
acpi:LNXPWRBN:
acpi:ACPI0003:
acpi:LNXCPU:
acpi:PNP0C02:
acpi:PNP0001:
acpi:PNP0100:
acpi:PNP0103:PNP0C01:
acpi:PNP0200:
platform:i8042
acpi:PNP0800:
acpi:PNP0501:
acpi:PNP0A05:
acpi:PNP0C0F:
acpi:PNP0B00:
acpi:PNP0A03:PNP0A08:
input:b0011v0001p0001eAB41_e0,1,4,11,14,k71,72,73,74,75,76,77,79,7A,7B,7C,7D,7E,7F,80,8C,8E,8F,9B,9C,9D,9E,9F,A3,A4,A5,A6,AC,AD,B7,B8,B9,D9,E2,ram4,l0,1,2,sfw
acpi:LNXSYBUS:
acpi:LNXSYSTM:
pci:v00008086d00007190sv000015ADsd00001976bc06sc00i00
pci:v00008086d00007191sv00000000sd00000000bc06sc04i00
pci:v00008086d00007110sv000015ADsd00001976bc06sc01i00
pci:v00008086d00007113sv000015ADsd00001976bc06sc80i00
pci:v000015ADd00000740sv000015ADsd00000740bc08sc80i00
pci:v000015ADd00000405sv000015ADsd00000405bc03sc00i00
pci:v00001000d00000030sv000015ADsd00001976bc01sc00i00
pci:v000015ADd00000774sv000015ADsd00001976bc0Csc03i00
usb:v1D6Bp0001d0604dc09dsc00dp00ic09isc00ip00in00
pci:v00001274d00001371sv00001274sd00001371bc04sc01i00
pci:v000015ADd00000770sv000015ADsd00000770bc0Csc03i20
usb:v1D6Bp0002d0604dc09dsc00dp00ic09isc00ip00in00
pci:v000015ADd00000790sv000015ADsd00000790bc06sc04i01
pci:v000015ADd000007A0sv000015ADsd000007A0bc06sc04i00
platform:efi-framebuffer
platform:efivars
input:b0011v0001p0001eAB41-e0,1,4,11,14,k71,72,73,74,75,76,77,79,7A,7B,7C,7D,7E,7F,80,8C,8E,8F,9B,9C,9D,9E,9F,A3,A4,A5,A6,AC,AD,B7,B8,B9,D9,E2,ram4,l0,1,2,sfw
platform:pcspkr
platform:reg-dummy
platform:rtc-efi
platform:serial8250
platform:alarmtimer
dmi:bvnVMware,Inc.:bvrVMW201.00V.20904234.B64.2212051119:bd12/05/2022:svnVMware,Inc.:pnVMware20,1:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:sku:
hid:b0003g0001v00000E0Fp00000003
input:b0003v0E0Fp0003e0110_e0,1,2,4,k110,111,112,113,114,115,116,117,r0,1,8,B,am4,lsfw
usb:v0E0Fp0002d0100dc09dsc00dp00ic09isc00ip00in00
running this command for l in $(cat ./missing.aliases.txt); do modprobe -qaR '$l'; done gives the list of corresponding modules that booster did not load:
mac_hid
fjes
mac_hid
intel_agp
i2c_piix4
vmw_vmci
vmwgfx
mptspi
snd_ens1371
efi_pstore
mac_hid
pcspkr
vmw_balloon
mac_hid
mousedev
mousedev
Out of this list the most suspicious is mptspi that is a message passing driver used for SCSI. And SCSI is the storage subsystem we have issues with.
@emperor06 please add modules: mptspi, rebuild the image then reboot and let us know if it makes any difference. If not try adding all the modules from the list above.
@anatol That was spot on! Adding mptspi fixed it. I now get a password prompt and, once unlocked, the system boots perfectly.
I'll check if I can make it work on my laptop (it's using nvme, so maybe there's another issue). Thanks a lot for your kind help, and for booster.
I added mptspi module to the list of default modules. Now your system should work without any config modifications. Please reopen the ticket if your other system does not work.
There is no writable/detected device in the initramfs so I used booster's network ability to send the logs through tftp. That's very convenient.
Glad that it helped!
May I ask you a favor? Could you please write instructions on how to do it and put it into the mainpage https://github.com/anatol/booster/blob/master/docs/manpage.md or somewhere at internet so other folks can debug booster issues as well?
It helped immensely. Having access to the network during the boot process is just wonderful.
I've added a small paragraph to the documentation. I hope it helps.