Talk:Rootfs encryption

From Gentoo Wiki
Jump to:navigation Jump to:search
Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 00:09, 5 September 2026 (UTC)
:: Your reply ~~~~

Various improvement

Hi,

I have started a fresh install and want full disk encryption. I met some pitfall and want to propose some improvements:

This page should have links to this page. Currently, it is not state how to encrypt disks from handbook. Even, it is an advanced topic, Gentoo is about choice :).

I follow the first partition schema (and the one of handbook too):

CODE Partition layout with a single EFI system partition
/dev/nvme0n1
 ├── /dev/nvme0n1p1 [EFI] /efi 1 GB fat32 Bootloader + support files, kernel, initramfs
 └── /dev/nvme0n1p2 [ROOT] (root) ->END luks encrypted root partition
 └── rootfs / ->END btrfs root filesystem

In the full page, this layout is not used. There is always /boot added.

It leads me to a big pitfall. After reading closely Installkernel, I noticed that I need that I need experimental efistub USE.

"UEFI implementations differ between vendors, as such EFI Stub booting is not guaranteed to work for all UEFI systems. Ensure a back-up booting method is available before attempting (automated) EFI Stub booting." <= I am not even sure it will work!

This layout should not be the first on this page. Or at least, it should be introduced with a big warn and a link to EFI Stub page. I understood too late that it would be easier with /boot!

It should be added also on Rootfs_encryption#Gentoo_installation (this is summary of full guide, mandatory steps should be included).

  • final step of installkernel (/usr/lib/kernel/postinst.d/95-efistub-uefi-mkconfig.install) was not working at all untill I created manually /efi/EFI/Gentoo

I will add that to EFI Strub page in "Troubleshooting" part.

What do you think about the other changes on this page and handbook?

Sébastien P. (talk) 17:25, 10 August 2025 (UTC)

The disk layout stuff is a bit complex, but these pages are designed to be used instead of the handbook disk sections. The layouts in the handbook have no consideration for encryption, and can be confusing to try to use in addition to the ones on these wiki pages. There are ideas but no real plans for the handbook mentioning encryption, so at this time, you should treat these pages as if they replace the disk setup sections of the handbook.
Depending on the installkernel layout, files may be installed to /efi instead of /boot, that's the main reason why these paths may differ. On a non-encrypted install, grub could be installed to /efi and can read boot files from /boot easily, so this is valid too. When grub is used, and the disk is encrypted, but with encryption grub can't handle (like luks2 with argon), then grub and boot files should be installed to a /boot mountpoint.
what about efi stubs are you unsure about? that recommendation was to help you know that you should install some other "normal" bootloader if you're experimenting with efi stubs, that way you can still boot if the efi stub entry failed to work for some reason.
On the rootfs encryption page, there is an "important" box warning about mountpoints when using grub, this is to address issues with boot files being installed to the encrypted root instead of an ESP which can be read while booting.
the "efistub" use flag stuff (uefi-mkconfig) is experimental. You should be able to do a lot of this manually. You'll just need to pay mind to what settings are being used by installkernel because that affects where the files are installed, and you need to be sure kernels are installed to your fat32 ESP (wherever that may be mounted) if you're efi stub booting. Zen desu (talk) 17:38, 10 August 2025 (UTC)
Hi, I used to compile gentoo-sources for 18 years in Gentoo without installkernel, so I hope I will be able to do the manual things of efistub :). Even there is a lot of new stuff like UEFI/initramfs (my current PC is 18 years old, a good old BIOS/MBR and only /home is encrypted). In the future, I will probably get rid of installkernel and compile/install it manually like today. I try to use installkernel to simplify a bit during installation.
Fine about the handbook.
Quote: When grub is used, and the disk is encrypted, but with encryption grub can't handle (like luks2 with argon), then grub and boot files should be installed to a /boot mountpoint.
Found that information (I had to dig a bit): Security Handbook/Boot Path Security.
I am not sure about that: "EFI Stub booting is not guaranteed to work for all UEFI systems". It sounds like it may not work for me (I did not try to boot yet) :/.
Something was not clear for me: if I respect the first layout "├── /dev/nvme0n1p1 [EFI] /efi 1 GB fat32 Bootloader + support files, kernel, initramfs", Grub is installed on /efi. But by default, installkernel is installing kernel on /boot (layout=compat, that was my case before I tried EDI Stub). Only "efistub" and "bls" seem compatible with this layout, is not it? And I need to install bootloader grub into /efi/grub (does not look possible for me)? If it is the case, it was not clear for me (at least).
The important note: "If Installkernel's layout is set to compat (when using GRUB), files will be installed to /boot, so the ESP should be mounted there." Maybe I misread it. Should I mount /dev/nvme0n1p1 to /boot for installkernel? In that case, it may mess up between grub/efi things.
Sébastien P. (talk) 20:48, 10 August 2025 (UTC)
The bit about efi stub booting not working has to do with your system firmware (motherboard). Some just don't play nice with custom boot entries of any sort. You can see if it doesn't if you know the entry you added is valid but it removes it every time you try to boot. It's just a but less "generally compatible" than something like grub, especially if installed with "--removable"
I would strongly suggest trying to work with installkernel if you want to help simplify things. You've just got to be particular with the USE flags, but it handles a lot for you.
The handbook uses /efi as a general suggestion for the ESP mountpoint, which makes sense, because for non-encrypted setups, bootloaders can likely read from a /boot dir on the rootfs. In these guides, the "extended boot" schemes are meant to be a bit of a hybrid where you still keep your ESP at /efi, but boot files are kept on some other partition grub can read at /boot. I wouldn't generally recommend this, as it's simpler to just mount your ESP at /boot and keep it simple, but it's an option if you're interested in that sort of thing.
So yes, if using grub, the simplest setup is to mount your fat32 ESP at /boot and let installkernel work from there. If you're doing things manually, you can put files wherever you want for EFI stub booting, because the key is that you add an EFI boot entry with info about the underlying storage and path from the root of that. You could use /foo/bar/kernel.img, with your esp mounted at /foo and set your efi entry to look for the kernel at "\bar\kernel.img" as an example Zen desu (talk) 21:03, 10 August 2025 (UTC)
Seem clear. I will that. Thank for this quick answer.
Do you mind if I change "Important: If Installkernel's layout is set to compat (when using GRUB), files will be installed to /boot, so the ESP should be mounted there." to "Important: Most Installkernel's layouts are installing files to /boot, so the ESP (/dev/nvme0n1p1) should be mounted on /boot in that case. Check Installkernel#layout for more information."? Or something similar. Sébastien P. (talk) 21:37, 10 August 2025 (UTC)
I'm not sure that is accurate because for most setups except for plain GRUB, the files may be written elsewhere. This includes other bootloaders as well as setups using the UKI use flag. From the installkernel page: "When the grub, systemd-boot, efistub, and uki USE flags are all disabled, the kernels will be installed in a layout that is mostly backwards compatible with Debian's installkernel (layout=compat). ". Using /boot is mostly a grub or "manual" thing, but if your ESP is mounted to /boot or /efi, it should be detected by efistub, uki, and bls setups as well.
I'm not sure how to describe this in a way that is less confusing but and still concise, but linking to the installkernel page would probably help with this confusion Zen desu (talk) 21:43, 10 August 2025 (UTC)
"Important: Some Installkernel's layouts are installing files to /boot, so the ESP (/dev/nvme0n1p1 on that example) should be mounted on /boot in that case. Check possible layouts for more information."? It is a bit more neutral and invite to check before continue. Sébastien P. (talk) 22:00, 10 August 2025 (UTC)
That looks better to me, a small note is to be sure to use the `{{Link` template for stuff within the wiki, not external resources (This works better with translations). The only real thing I'd change is mentioning that "some" often includes setups using grub. The main reason that warning was added is because people were using the handbook and mounting their ESP at /efi, and then files would be installed to /boot, and grub would fail to run.
This is getting a bit in the weeds, but technically you can use grub _and_ efistub options, in which case I think the ESP (not /boot) will be used. This is more of a new feature, and wasn't possible at the time that note was added. Zen desu (talk) 23:08, 10 August 2025 (UTC)
Done [[1]]. In my memory, I tried USE +grub/+efistub together and it used /boot. I will note it and try again later. Thank for the advice. Sébastien P. (talk) 21:48, 11 August 2025 (UTC)
USE +grub/+efistub together give me all in /efi except grub.cfg. grub.cfg was on /boot. Sébastien P. (talk) 21:37, 14 August 2025 (UTC)
Thank you very much for the help! Zen desu (talk) 22:04, 15 August 2025 (UTC)
Talk status
This discussion is done as of 2025年08月14日.

.