EFI stub+disk encryption: is initramfs really needed?

[NP_complete]

I am following this guide to set up disk encryption, and I would like to boot from an EFI stub.

1. My main question is whether initramfs is really necessary here? As I am thinking this through, I could, simply, put the kernel (with a name ending in .efi) into the ESP partition which will be mounted by the BIOS. The kernel would have all the requisites built in and can therefore decrypt the LUKS volume and mount the btrs root file system. After this, we are basically done. Is there a gap in my logic?

2. As a closely related question, do I need a separate /boot partition containing initramfs, as described in the linked article? Assuming that I do need such a partition, how would the boot sequence proceed? First, the kernel stub is read by the BIOS, then /boot is mounted and initramfs loaded into memory to give the kernel the ability to decrypt and mount the root file system. Do we need to go back and forth between the kernel and initramfs like that?

Many thanks.

[pietinger]

Before answering your questions I would like to tell you a few things ... you maybe already know:

1. You can have an external initramfs (as a CPIO archive) or you can embedd it "into" the kernel image.
2. As soon as the kernel knows it has an initramfs, the kernel will no longer do the job of mounting the root partition, because now it is the job of the initramfs.
3. If the kernel has an initramfs the kernel will only start all statically configured modules itself and THEN switch to the intiramfs, BUT there is NO RETURN from the initramfs back to the kernel. This means: the initramfs has to do everything else what is necessary for a correct systemstart (at least: mounting the root partition and loading some kernel modules which has been configured as <M>odule and not statically).
4. The kernel would NOT be able to mount an encrypted root device ... for this you will need always (-> *) an initramfs.
5. UEFI (BIOS) is not able to start a program from an encrypted partition (because UEFI can only do SecureBoot=booting a signed image; but no decryption of an image). This means if you want start your kernel directly via UEFI (a good choice) this kernel must not be encrypted; it must reside inside the ESP and the name must have the suffix *.efi

Now to your questions:

1. Usually you will always need an initramfs when using an encrypted root partition ... (* ->) but it is not entirely true: There is a very rare solution where you need no intramfs for an encrypted root partition ... a complicated one:
https://forums.gentoo.org/viewtopic-t-1110764-highlight-.html
(I would never recommend this to a new user)

Keep in mind you have two choices to build an initramfs: You use an automated routine like dracut (or ugrd), or you create it by yourself. Maybe you want read: https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Initramfs_Overview

2. No, you dont need a seperate /boot partition; you need an ESP (EfiSystemPartition) ... and you must mount this parition into your root directory to access it. Last year was a change of the mountpoint of this ESP: See more here:
https://forums.gentoo.org/viewtopic-t-1165115-highlight-.html

Maybe you want read this to get an idea of booting a (stub) kernel directly via UEFI:
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Boot_kernel_via_UEFI

Now your boot process for an encrypted root partition would look like this:
1. UEFI gets the information from its own UEFI boot entries list which image.efi it must start. If this is a (stub) kernel THEN ->
2. Kernel starts and knows it has an initramfs. So after a little bit of initializing kernel handover to this initramfs.
3. The init script inside the initramfs does more work and starts at last /sbin/init from your root directory (this would do a kernel without an initramfs at last). Yes, this init will NOT return to the kernel.
4. /sbin/init is your initsystem (either OpenRC or systemd)

Keep in mind: IF you use a kernel with an external CPIO initramfs, THEN this initramfs MUST be ALSO in the ESP (best in the same directory as the kernel) AND you must have an UEFI boot entry of this kernel whith the parameter "initrd=..." (See more:https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Kernel_Commandline_Parameter#Parameter:_initrd.3D )
_________________
https://wiki.gentoo.org/wiki/User:Pietinger

[pietinger]

NP_complete,

do you need more informations?
_________________
https://wiki.gentoo.org/wiki/User:Pietinger

[NP_complete]

@pietinger, thank you for the great explanation! I can't apologize ENOUGH for slow response. I did get the encrypted root partition working. The article I linked to in my original post is very confusing. It must have been tailored specifically to grub. I would not recommend following it outside that scenario.

With the encrypted root partition working, there is one remaining problem. I'd like to also have a separate /home and, possibly, swap partition present. btrfs seems to support quotas, but only at the expense of performance loss. Ideally, I would like to have everything inside a single LUKS container. Except this one thread, there isn't any relevant information available. Sadly, even this thread admits that the proposed solution does not work. And I wouldn't want to use LVM because I don't need all the power.

Does this leave me with the only option of having several LUKS containers, one for each partition? Not a perfect setup since my partition scheme will be exposed.

Many thanks.

[pietinger]

[Hu]

I am not a btrfs user, but my understanding is that it allows "subvolumes" so that one btrfs filesystem is logically subdivided and parts appear at different mount points. Personally, I would just take the hit of using LVM, but if you really want to avoid it, what about having 1 LUKS container that has within it 1 btrfs filesystem, and then have N btrfs subvolumes in that 1 filesystem, one subvolume for /, one for home, etc.?

I don't see hibernation (suspend-to-disk) discussed here, but it warrants at least a minor mention. If you want to use hibernation, you need a way for your swap device's encryption key to survive reboots (LUKS can do this). pietinger's suggestion of letting dmcrypt discard the key every time is great if you want to discard swap contents with every shutdown. If you need to keep the contents around, then you cannot let the key be discarded. On the positive side, this is something you can fix later. You could choose to use ephemeral swap and no hibernation today, then later decide you want to replace your ephemeral swap with a LUKS-encrypted persistent swap, so that you can begin using hibernation. Your change at that time is only to disable swap, create the LUKS container, and prepare its contents. No reinstall would be required, and your filesystems would be untouched.

[NP_complete]

Thanks to both of you. @pietinger, I did follow the section of the guide you linked to: