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.
Fedora forum tells me that luks-UUID is all that is needed in crypttab but no one has told me how to get out of emergency shell so I can regenerate the initramfs so that the new crypttab edit will be used on boot. Might as well not use vi in dracut to edit crypttab since the edit wont persist. How do I get out of dracut now that the security key is enrolled but system does not boot? It defeats the purpose of a security key if there is not more to dis-enrollment. crypttab has to be perfect the first time or else there is a lot of steps to return to the beginning and I am not even convinced luks-uuid is the answer. No /dev/sda at beginning? I did not put “/dev/disk/by” in crypttab. That is something that happened automatically at some point.
Don’t care about the crypttab until the system is booted.
You have two ways:
Please check the links in my last reply again. The dracut manual has a complete help example under “Accessing the root volume from the dracut shell”.
Thanks. I tried your first option. The last question is asking about the finer points of “bypasses” if an adversary has physical access (cold boot type concerns and what we are doing here ignoring crypttab).
grubby or editing for GRUB_CMDLINE?/etc/dracut.conf.d/cmdline.conf where I could specify something different in kernel_cmdline= since dracut initqueue is looking at -e "/dev/disk/by-uuid. Instead of dev disk by I would put luks-<uuid> if Fedora were like Arch I presume.Wondering what you think of this thread and dm-crypt. I have noticed instability recently upon login with password on Qubes OS. I think it is spectrum related but since that is impossible why would passwords correctly typed sometimes be rejected and only after several attempts accepted? Instability in a graphical (xcfe-4) login environment?
Hi @SecureBoot,
To 1: you simply hit “e” in the grub menu to edit the kernel commandline before you boot it. The screenshot you paste is from the emergency shell. Nothing you edit in there will be carried over to the real root. You don’t need any /dev/…/uuid, just give the correct dracut rd.luks* parameter and device (e.g. /dev/sda3) to open on the kernel line. Once your system boots again, you can fix crypttab with uuid or whatever is usuable and your preference.
To 2: I already asked you in August if your root opens with passphrase, and you replied it does. It’s your configuration.
I understand you are experimenting how to use a luks enrolled NK and it’s good to think about your questions. However, my answers were to give you pointers how to get your apparently borked boot running again, so you can fix it and work on your setup. Nonetheless: Wrong passwords can happen, particularly typing known phrases too fast (e.g. using shift for special chars). If you’re using an usb-keyboard, perhaps some interrupt issues. Interrupt problems are far less common nowadays, but I’ve had such myself on a system where an early USB3 controller was flaky. Simply switching the keyboard to a USB2 port solved it.
Can you tell me more about IRQ? Yes, that might be something to do with it.
Thanks. Unfortunately they just used their EMI capability on me again so it will be a while until I get another computer to try what you suggest. I dont want to keep buying thousand dollar computers just for space to crash them. Need a Roda. I did try ‘e’ before and my computer did not respond to that.
Boot is GRUB Dracut kernel cmdline options and boot bypassing crypttab - #2 by system76g6 - Fedora Discussion
Dracut cant regenerate itself so any edits fallback. There would be no point of the security key for LUKS if it can simply be bypassed. There must be a way to disenroll the key and reverse crypttab but I am not finding any information about that.
The fedora discussoin shows the grub editor, that’s where you can override the default initramfs options (I’m not sure which parameter you need), yes.
You can simply use the cryptsetup lukserase action to remove the luks slot holding the key cryptenroll added, if you decide against using it.
Good. I am in the right place. Just my password manager locked up in there.
But I think we have arrived at a more important observation in the process or recovering from a crypttab failure. If LUKS crypttab can be bypassed, then there is really no point of this additional nonbinding nonessential key. I was looking for an “IFF” lock. If and ONLY if the USB key / 2FA is accepted. Biometrics on phones, are another example of for simplicity non-IFF keys. The password alone ultimately provides access. There is not even an ease advantage with locking LUKS with a key like with fingerprint on a phone. TPM might be an IFF 2FA. But boot parameters could also bypass a TPM bind, true?
Every dm-crypt LUKS device has 8 keyslots and any keyslot you configure can unlock it. Given there is no luks header backup: If you decide to erase the slot with the passphrase and only the one with the pkcs/hmac-secret on the NK is left (preferably with PIN protection), you have achieved your IFF goal. For your question have a look at the manual of systemd-cryptenroll, it explains the options very well and the table lists your options to lock/bind the bootloader. I think there is also a grub option to forbid "e"diting the kernel line, but this is a pre-secureboot/tpm method and can be circumvented.
