Thanks for the cloning instructions. I bet you anything the dracut method would work quickly and perfectly on bare metal. Maybe I will just try it on a cloned disk. There must be complexities involved with passthrough that aren’t allowing the Yubikey to be found. lsusb in the VM says there is an ID QEMU U2F USB key and a root hub. But the Yubico Personalization Tool and Manager say that “no Yubikey is inserted.” Cryptenroll activates the key and the lights flash for fingerprint but then nothing happens. So there must be more to do make the passthrough full functional as it appears it is only partially. Do you have some suggestions about working with Recovery partitions in case something goes wrong? I will try on a cloned disk, but it is good to know more about recovery partition and backups for restoring. I’m not sure what more I could try with the Qemu passthru options. I sent an email to the Qemu support listserv since I think that is as close as I can get to something like a forum or support contact. Again, from what I found completing the dracut luks steps, this is probably, actually, a quick solve but I just wanted to make sure I didn’t get locked out of my computer.
The Yubikey Personalization Tool has a lot of interesting options. I wonder how the challenge response mode works. Lots to learn about.
Fedora Linux doesn’t really have a “recovery partition” per se. Instead, the Live DVD image is typically used.
Cloning your OS to a secondary drive and experimenting with that is a good call. That should be safe as long as you keep your primary drive disconnected to be sure you don’t accidentally change anything on it while you are experimenting.
Yes. It’s something going on with the QEMU USB passthrough. I tested on a clone drive and the security token was enrolled successfully with keyslot and token showing up like it is supposed to. But the final step of sudo dracut --regenerate-all --force returns an error message “Can’t write to boot/efi/(longnumber)/(kernel) does not exist or is not accessible.” Do you know why?
Not really. I would guess one of the “all” initrds “does not exist or is not accessible” . Leave off the --regenerate-all and it should try to “regenerate” only the current initrd. You can then try to go back and regenerate the older initrds if the current one works.
Ok, I’ll try that. I looked up dracut and found that Red Hat was it’s original author. Do you have a good metaphor or way to conceptualize what role dracut and initramfs play in the boot process and how this connects to LUKS?
I took a look at cryptenroll again and it lists systemd-fido2. Does that mean systemd boot is required to make all this happen? I haven’t converted GRUB to systemd boot yet. How does it all connect together? GRUB–>dracut/initramfs/systemd–>LUKS
I tried removing --regenerate-all on the clone disk like you suggested and got the same error message about /boot/efi/machine-id/kernel not existing or being inaccessible. Then I tried mkdir at root because, actually, that file does not exist although creating it is not part of any directions (so the directions assume systemd boot?). But it won’t make dir. So I checked the permissions. /boot/efi is password protected with owner r/w but group is not r/w. SELinux has system_u:object_r:dosfs_t:s0. Then I checked my sudoers and ALL:ALL at root but people in group %wheel can run all commands (should I comment out %wheel?). I can go to root with sudo su but su prompts a password that is unknown and not the same as the root password.
Also, I noticed a difference in directions about /etc/crypttab. One states -fido2 after luks number and another puts /dev/sda3 before -fido2. So probably the drive should not be omitted from crypttab.
Sudo requires the user password and not root password. The su command does require one to enter the ‘root’ password which is disabled by default in fedora.
One should not alter /etc/sudoers since the entry for %wheel is what allows members of the wheel group to use sudo. This is what allows the normal user to perform admin tasks.
This entry when you do the command
$ ls -ldZ /boot/efi
drwx------. 5 root root system_u:object_r:dosfs_t:s0 4096 Dec 31 1969 /boot/efi
does not mean it is password protected (it is not)
It does mean that the user must have root or sudo privileges to read the content.
Please learn more about the linux file system structure and commands before you make changes to critical system files that might require a complete new reinstall for recovery if one makes an error.
I haven’t read the guide you are trying to follow. But yes, anything trying to update /boot/efi/$MACHINEID/{linux,initrd} is likely assuming you are using sd-boot.
Older guides might omit creating the /boot/efi/$MACHINEID directory as part of a sd-boot setup because older versions of bootctl used to create that directory automatically. Newer versions of bootctl require that --make-entry-directory=yes be specified if you want /boot/efi/$MACHINEID created. The kernel-install script will then populate that directory if it exists.
After all, it’s my OS, as the Fedora motto would have it. I have more experience with Debian where sudoers is arranged differently. Now, I know plenty. I’m at the last step of what I set out to do. And I am being careful. That’s why I’m working on clone disks and vms. But I don’t know everything. Very few people do, if any know absolutely everything. And instead of telling me to know more, you might tell me why I can’t get permissions to make the /efi/boot/. . . or why it is not there in the first place. It looks like the answer is that systemd boot is taken for granted. In regard to sudo, for starters, I don’t have multiple users, I have full disk encryption and an administrator password (that is for both sudo and sudo su which goes to “root” unlike sudo alone). su is different in Debian. Someone could explain the intricacies, but it is not like @jeffv presented it. For now, I’m going to see if moving from GRUB to Systemd Boot will allow this last step to be completed.
I have systemd boot on the clone disk (sudo bootctl checks out) but the
dracut: cannot write to efi
error message still occurs. mkdir doesn’t work to create the file path but using file manager to create files by GUI and name them as needed does. Still, even with the file path in place according to file manager, the same error message occurs with or without --regenerate-all. There is a machine-id file in /boot that is empty and a different numbered “linux,initrd” than the one that is supposed to be in /efi/machine-id there also.
I do have sudo and root permissions.
I have no idea what more permissions there could be if you don’t think this is a SELinux issue. According to what is in the guides, everything should have worked.
That error might occur if /boot is mounted read-only. Or if the SELinux permissions are wrong. Or if the machine-id isn’t resolving to the right value. Or if what is supposed to be a directory exists as a file. Or about a billion other things. Sorry, but more information is needed before anyone will be able to give a more accurate answer to what might be going wrong.
You might try giving dracut the full path to the initrd you want to generate to be sure it is doing what you think it is doing.
The guides definitely falsely portray this implementation as easy. I was able to complete the operation of writing to /efi by giving dracut the full path after I made an initrd that was not present in /efi/machine-id only by making the file with GUI since root cli would not make it. Root is “owner” of /efi with “access files” and there seems to be no way to change this. How do I change permissions on this file via cli? Nonetheless, the fido2 key was not required at the LUKS2 challenge response. The guide says to input the fido2 token passphrase into challenge response instead of original full disk encryption pw. That’s not how it works, yet anyway. Nothing happens differently after dracut --force with cryptenroll and systemd boot.
Why are there multiple initrd? I had an initrd from f37 (6.2.9-200) that was still there after upgrading to f38 and had to make the initrd (6.2.11-300) with file manager.
After editing /fstab, I believe the mount point is just /efi. /boot/efi is still present but the path is empty.
Another guide says:
“by default, dracut does not include its fido2 module when building the initramfs. Thus I created /etc/dracut.conf.d/fido2.conf with contents: add_dracutmodules+=" fido2 " And then rpm-ostree initramfs --enable to build the initramfs. Use 'lsinitrd /boot/ostree/fedora-/initramfs-.img (replacing the asterisks with whatever is current) to check the initramfs contents. It should show fido2 as a dracut module and usr/lib64/cryptsetup/libcryptsetup-token-systemd-fido2.so as one of the included files.”
I haven’t tried this yet.
If I try the dracut command with --regenerate-all then the message is that dracut cannot be called with an image file.
Is your system one of the ostree variants? If so, there may be significant differences about how the booting works. That may also be why you were not able to modify the initrd with dracut. I think most guides are written for non-ostree variants like Fedora Workstation or Fedora Server. At the most superficial level (e.g. the icons that show up on the Desktop), ostree and traditional package-based operating systems may appear similar. But at lower and deeper levels such as where you are working, they can be quite different.
That’s for immutable Silverblue, isn’t it? Interesting concept. I understand it as something like live. I’ve read about “stateless” computers and have thought about what r/w really means, because the reality is more like a continuum of mutability (exchange and duration) for information. More to know.
No, I am on Workstation. I tied setting up the dracut module. Nothing different. But I don’t know what the equivalent of initramfs --enable would be if there is one or if it is even need or what else to do after making the fido2.conf.
Unless someone can ask me some troubleshooting or diagnostic questions to find out what is missing, I can say that the 0pointer.net — stackexchange guide is not sufficent.
bpereto - adds a “build and install” I don’t understand, ykfde.conf, cpio for grub
So there are variations and parts I haven’t tried to work in yet. I’ll probably work on guyrutenberg next because I already changed to systemd boot on the clone disk and bpereto uses grub.
You seem to have done a lot of research and that is a good thing.
However, one must always evaluate the information and determine if it applies to their current OS and release version. Blindly following what is posted can quickly lead to more problems if that instruction does not properly apply to the system in use.
Humans and “AI” both do a lot of research. The difference is that humans can
come to an understanding of the material, while AI blindly follows.
I see more and more sites claiming to solve problems with linux that are clickbait
mashups of other sites. They lack explanations and links to the technical background
material, but the good documents are increasingly difficult to find (except at arch linux).
guyrutenberg does not work on first attempt. ykman confirms there is an hmac-secret. systemd-cryptenroll lists the Yubikey as /dev/hidraw1. And lsinitrd lists /efi/(machine-id)/initrd as boot (so it’s systemd boot) and dracut systemd and fido2 as dracut modules.
There maybe something that has to be modified with the /etc/crypttab. My crypttab isn’t identical to what is presented in the guide. Mine begins with luks-(machine-id) UUID /dev/sda - fido2 . . . instead of drive-(machine-id) UUID (some terms with commas) -fido2. I don’t know if this matters.
This guide is for Debian where dracut is not already present like it is in Fedora, so I assume that the “Switch to Dracut” section is not relevant.
There might be something missing in the install fido2-tools >…>…> EOF section.
I might check out bpereto next, but I’ve got to think about switching from systemd boot back to grup unless the cpio for grub section can be modified to work with systemd boot.
@system76g6
If you look at the KEY ACQUISITION section in crypttab(5), you will see the six available options for decryption. It is up to you to decide how to mix and match them to solve your issue; there is no single solution that applies for all.
Unfortunately I don’t know your use-case and I can’t help you further. I suspect you want a nice GUI that asks for a password and then you furthermore tap your YubiKey to unlock the volume, i.e. you want to use systemd-cryptenroll with the hmac-secret extension of your key. This is what KeePassXC does (a popular password manager); but you will notice in the KeePassXC FAQ it is explained that this method is not true 2FA.
In my limited experience, a lot of security enthusiasts, myself included, want things that aren’t useful. Time shouldn’t be wasted on providing solutions for problems that aren’t important, and it takes experience to be able to tell which problems are important.
. Leave off the