Return LUKS1 option in Anaconda through Fedora's Live ISO

Ask Fedora
, , ,
1

In order to get the root partition encrypted while also having /boot inside it, I have to use This Patch that still works up to Fedora 39 in order to remove the restriction Anaconda puts for having /boot (whether inside root, or as it’s own partition) inside an encrypted drive.

However, in the Fedora 40 Workstation ISO, while the patch still correctly removes the restriction for /boot being in an encrypted drive, a change made to Anaconda in the Fedora 40 ISO eliminated the option to choose between LUKS1 and LUKS2 for encrypted devices inside the regular custom partitioning (unsure about advanced custom partitioning as I don’t have the knowledge to use that), making it impossible to do what I could previously achieve (encrypted root partition that also has /boot), since AFAIK, GRUB doesn’t support LUKS2 yet.

While I can understand why Fedora wants users to use LUKS2, since it has stronger encryption than LUKS1 (hence I use it for my /home partition), Fedora already defaulted to utilizing LUKS2 encryption should the user go through a custom install and chose to encrypt their drives, so I don’t understand why the option between LUKS1 and LUKS2 was removed completely. One could put /boot in a separate unencrypted partition, but that causes BTRFS snaptshots to not include /boot, and thus the kernel, which means the installation won’t launch properly, or at all on Nvidia systems after a rollback if the user has updated their system at least once.

I’m aware there are other ways to encrypt the boot partition, but they require a decent chunk of knowledge that I (and many other users) don’t have, and thus, being incapable of doing so.
Is there any chance for returning that option, and maybe even remove the restriction for /boot so that the patch is no longer needed?,

2

First, using unmaintained patches - and generally untested / foreign patches - are themselves a high risk to security and stability. So if you focus on security and stability, I suggest to not do that.

Second, I am not sure if I understand your problem / goal, but you might read the comments from Chris Murphy in this topic. It is an old one, but the elaborations for the reasons why some things are done the way they are might be helpful to you. The same for this one (again the comments of Chris Murphy but also of Gregory Bartholomew)

That might be not tailored answers to your topic, but I think they can shed light on some of your points and questions, if not to most.

1 Like
3

I don’t see this as a patch more than a proper hack, since you have to skip checks to make this work. It’s very messy. . .

Would building the container prior to install not work better for you instead? Also not using Grub and go with systemd-boot ?

4

Indeed, it’s generally not advised to use unmaintained software, and I’d much prefer to not have to use such workaround, but it’s the only non overly complicated solution that I was able to find that worked for me, and looking into the patch (which tbh, I agree with hamrheadcorvette that it’s more of a hack than a patch), I’d imagine any potential risk would be minimal, since all it does is bypass the anaconda check for /boot being in an encrypted partition and add the necessary extra stuff for everything to work properly with an encrypted /boot, although I’m no expert at this sort of stuff.

I did not understand much from those topics, but they don’t seem to be what I’m trying to achieve, which perhaps I should go into more detail.

Basically, there this software called BTRFS Assistant, which for my usecase is just an easy way to make snapshots with snapper (which is what I was trying to refer when I said BTRFS snapshots, so sorry if I made any misunderstanding), and those snapshots are very useful to me, as I use them pretty often to more easily revert any changes made to root that I didn’t like, for example, I upgraded my Fedora 39 installation to Fedora 40, but I had some issues with it, so I rolled back the snapshot and it’s as if I never upgraded to Fedora 40.

My problem that led me to do all of those workarounds is that if /boot is located in a separate partition, /boot won’t be included in the snapshot, which would completely invalidate my usecase, as trying to do the previous example I’ve said before would lead to a system that won’t boot, as the root is expecting a different kernel than what is present at /boot (at least that’s what I assume, again, I’m no expert here). My solution is to simply not have /boot as it’s own partition, but inside /root, that way, whenever I create a snapper snapshot for root, /boot will be included in it as well, and it works very well for me (Note: /home is kept in a separate partition as in my usecase, it’s not desirable to rollback it as well).

However, getting my solution to work is not possible without removing the checks to Anaconda that prohibits /boot from being in an encrypted partition, which is why I made this post, as Fedora 40 ISO removed the option to make LUKS1 partitions (AFAIK, grub doesn’t support LUKS2 yet). If I can’t find any solution to this problem that isn’t overly complicated for a user like me, I’d would need to leave root unecrypted so that anaconda lets me install fedora and have /boot included in my snapshots. While I don’t mind having /boot unencrypted, I absolutely DO NOT want root to be unencrypted.

5

I’m not familiar with those concepts, (the former being the first time I’ve even heard of), so I have no idea what they do. If they can somehow include /boot (even if /boot is in an unencrypted separate partition) inside the snapshots of root made with snapper (which is what I was trying to refer when I said BTRFS snapshots, sorry if I previously made any misunderstanding), if the snapshots work properly, that would be absolutely game changing.

6

systemd-boot expects the kernel image to be found in the ESP (/boot/efi). Therefore the kernel and initrd won’t be included in the snapshot either.

7

But you could systemd-nspawn -D or chroot into a snapshot and

  • install the kernel :thinking: bootctl install
8

Would that automatically change the kernel from the current one to the one that was present at the creation of the snapshot?

9

Does that mean it’s a combination of /boot/efi and /boot for GRUB? If that’s so, then it would be impossible to have /boot inside root without leaving it unencrypted, or no? At least for GRUB, you need /boot/efi to be unencrypted.

10

Basically it means /boot is not used and everything needed for booting is locate in the ESP. You can create a /boot file system and mark it as XBOOTLDR file system formatted as a VFAT file system. In this case the kernel and initrd will be installed there.

So it seems to me that systemd-boot will get you even further away from your goal.

11

I will stick with GRUB then, which should make things easier for me since I’m not aware of systemd-boot install being an option in Anaconda.

12

Came back to this since ia am working on some Documentation and a Project with LUKS containers prior to install, this post lines up well. . .

Here are some screenshots of the advanced installer which answers your question, Fairly easy to use.

Screenshot from 2024-06-20 11-18-48
Screenshot from 2024-06-20 11-18-48958×565 69.3 KB

Screenshot from 2024-06-20 11-03-02
Screenshot from 2024-06-20 11-03-021285×466 59.7 KB

2024-06-20_11-03-51
2024-06-20_11-03-51771×517 40.5 KB

2024-06-20_11-04-39
2024-06-20_11-04-39733×610 48.5 KB

Afterwards you can choose the partitioning schem you ant and move forward with the install.

13

From Project Discussion to Ask Fedora

14

Added encryption, f40, luks1, luks2 and removed workstation-wg