How do I correctly name the disk for systemd cryptsetup? crypttab does not want /dev/sda3 which is the location of my LUKS. There is something other than a partition name or UUID?
cross references on security key topics
After editing crypttab correctly, how do I regenerate the initramfs from the emergency shell (sh-5.2#)?
Thanks!
The crypttab is not used for the system’s root partition, the root device is specified via kernel parameters (e.g. rd.luks). Have a look what parameters you have set and compare to the devices.
While there are different naming methods, not all will work to boot. To get started, identifying the correct device via /dev/sdaX should definetely work. This only gets problematic, when you have multiple devices on the system.
The emergency shell cannot be regenerated from the initramfs. For that the system should be fully booted, because dracut needs to access the configuration files etc
What you perform in the emergency shell is to unlock the LUKS cryptdevice and perform the steps to mount the system root. Next, upon exiting the recovery (‘exit’) it should try again to boot.
If you have trouble performing the steps in the recovery shell, you can perhaps boot a USB-live system to unlock the LUKS device and inspect parameters. You can’t regenrate the initramfs then directly either, but must first chroot into the borked system to let it regenerate the initramfs. Still, it may be easier to look what’s wrong via a live system.
HTH
Thanks. I am trying to do two things because I am testing booting with a security key lock on Fedora before I try it on Qubes.
So first, when I boot Fedora and it enters emergency mode, how do I find out what the boot parameters are since sh- is telling me that it cannot access /boot/?
[In Qubes, /boot/efi/EFI/qubes/grub.cfg lists the machine ID as a parameter but not rd.luks
In Qubes, ls /boot/efi/EFI/ lists BOOT fedora qubes]
So if I found out how to find the boot parameters in F38, then I would edit cryttab with vi in emergency mode and replace /dev/sda3 with some variety of rd.luks?
Can you tell me more about how to chroot bork with a live boot?
Also, I think I should clarify that my Fedora system is booting with systemd boot while Qubes is using GRUB.
crypttab will accept LUKS naming from the parameters of either systemd boot or grub.cfg? That is what’s missing?
But if I were to edit crypttab on Qubes with GRUB boot (is it true systemd boot is not a prerequisite for systemd cryptenroll since GRUB also initiates systemd?) then I would uses that machine id found in the parameters of grub.cfg since there is no rd.luks?
Hi, to clarify:
I mixed it and this sentence should have read “The initramfs cannot be regenerated from the emergency shell.”
For the rest, to me the info your original post and follow-up is contradicting itself. Please skip your hypothetical questions and state what your current problem is.
I’m not using fedora and systemd-boot. Start by booting a fedora live-system USB and see if you can access your LUKS root filesystem manually from the shell e.g. with "cryptsetup open /dev/sda3 root. If that works, try to mount it to /mnt. If the mount does not work, run vgchange -ay followed by lsblk -f and post the output here.
lsblk says that sda3 LUKS is crypto2 and then there is a long UUID. Is the UUID the right name to put in crypttab?
cryptsetup open does unlock with password. What after mounting? Nothing happens with vgchange.
Hey,
Qubes 4.1.2 uses Fedora 32 as dom0, there systemd is not new enough to support this crypt-enroll feature with fido2. The Upcoming Qubes 4.2 uses fedora 37 as dom0 there this would work. We testing this at the moment and there are some barriers (for example dom0 has no usb what makes initial enrolling of the keys quit a challange)
Thanks. I am working on Fedora 38 and Qubes 4.2 so cryptenroll should be possible in either case.
Thanks for thinking about Qubes 4.2.
Dom0 has a secure update mechanism so its not as though it is always untouched so I dont see why in principle there could not be a secure usb attach mechanism developed.
FYI. If you look up Yubikey in the Qubes forum you can find that a script can be made for GRUB that takes security key enrollment out of a qube (which can usb attach) with ykpersonalization and this method doesnt require interaction with Dom0.
Can you help out with my question about F38 crypttab? The part I think I need to know is what to name LUKS in crypttab since naming it /dev/sda3 made it drop to emergency shell. Is it the UUID for crypto2 sda3 in lsblk?
Yes, that should be it. Read up on the kernel parameters systemd-cryptsetup honors. For example, you can specify luks.uuid= which takes precedence over entries in crypttab. edit: I forgot you probably(?) used dracut and may need to use rd.luks.uuid=. The parameters dracut honors are a little different. Check also the recovery examples in its man page.
