-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fedora Silverblue + other immutable Fedora OSes support #6
Comments
Depends on #5 |
can you explain a bit more? crypttab is in /etc, which is in the encrypted root BTRFS partition with all the rest of the OS.
the /boot partition is needed for GRUB, OpenSUSE supports GRUB with the /boot/efi partition, something like that. I am not totally sure about that. You are talking about crypttab being on /boot ? This could be done on the system, /boot is writable by root. crypttab doesnt change normally, so just copying that would be fine. There is also bootupd, which will soon be used to update the /boot partition with the contents distributed in the OS image, lying in So if having crypttab in the initramfs is kinda standard, and if this is in the /boot partition, then this would need to be integrated into bootupd, to not overwrite it on every rpm-ostree/bootc update, triggering a bootupd update, overwriting the /boot partition with the updated stuff in the OS image. |
I explained the issue more in the issue description, I hope it is more clear now. |
Initramfs in Fedora Silverblue misses
crypttab
file (other Fedora variants need to be examined). A different mechanism is used, therefore custom approach has to be implemented by cryptreboot.Cryptreboot operates in two stages:
When the OS is fully loaded and the disk is unlocked: cryptreboot parses the
crypttab
file found inside the initramfs to identify encrypted disks and prompt the user for passphrases for those disks. While it could use/etc/crypttab
for this, using the copy within the initramfs is more self-sufficient and better aligned with the standard reboot process.When the patched initramfs code is executed (early userspace): Previously, cryptreboot injected a modified
crypttab
file into the initramfs. This modified file contains the disk encryption keys, which allow the disk-unlocking code in the initramfs to run without requiring a passphrase from the user.In the absence of the
crypttab
file within the initramfs, it is evident that an alternative disk-unlocking mechanism is in use by the initramfs. There is a need to understand how this mechanism functions to allow cryptreboot to provide it with the disk encryption key, thereby eliminating the need for a passphrase prompt.The text was updated successfully, but these errors were encountered: