How to Install Fedora 37 with LUKS Full Disk Encryption, Snapper, and Grub-Btrfs for Full System Rollback

How to Install Fedora 37 with LUKS Full Disk Encryption + Snapper + Grub-Btrfs Feature Image

In this blog, I will show you how to install Fedora 37 with LUKS Full Disk Encryption, snapper, and grub-btrfs packages, allowing you to take snapshots of the / and /home subvolumes as well as perform a full system rollback on the / volume if something goes wrong.

LUKS encryption protects the data in a block device while it is offline. This is especially important for mobile devices such as laptops because your hard drive can be easily accessed if left in the wrong places or, worse, stolen. To access the decrypted content on the device, you need to provide a passphrase or key file. The LUKS Full Disk Encryption will take care of this.

Regarding the snapshot rollback, I hoped that in Fedora 37, the DNF database would be relocated to /usr, as the RPM database was in Fedora 36. Sadly, It did not happen. It is still held back in /var/lib/dnf.

So, to avoid package mismatches between the two databases, I need to keep the /var directory in the rollback regime. I will, however, exclude the /var/log directory so that log data are not lost during rollbacks. You may add more directories if you wish.

Here is a brief overview of what needs to be done.

  1. Design the disk layout to install Fedora 37.
  2. Install Fedora 37 with a LUKS encrypted btrfs / filesystem and an unencrypted separate ext4 /boot partition, as the Anaconda installer does not support encryption of the /boot partition.
  3. After the installation is complete, copy the contents of the /boot partition to encrypted /, and configure GRUB to boot from it.
  4. Remove the ext4 /boot partition and merge its space with the btrfs volume.
  5. Configure the system to request the LUKS passphrase only once by supplying the key file.
  6. Install and configure snapper to take snapshots of the / and /home subvolume.
  7. Install and configure grub-btrfs to add snapshots menu to GRUB, allowing you to perform a full system rollback on the / volume.
  8. Finally, do some tests on the snapper ‘undo change’ and rollback features to ensure that everything is working properly.

If you prefer to install Fedora 37 without LUKS Full Disk Encryption but still have Full System Rollback feature, please visit my other article ‘How to Install Fedora 37 with Snapper and Grub-Btrfs for Full System Rollback

If you prefer to install Fedora 37 with LUKS Full Disk Encryption (FDE) using Fedora’s default partition layout, please visit my other article ‘How to Install Fedora 37 with LUKS Full Disk Encryption (FDE)‘.

So let’s begin.

Table of Contents

1. Disk Layout for Installing Fedora 37

Since the Anaconda installer does not allow encryption of the /boot partition, either separately or in the / filesystem, you first need to create an unencrypted /boot partition separately. This is how the disk partition appears at first. I will use a 100 GiB hard disk for the demonstration.

NAME          SIZE   FSTYPE         LABEL    MOUNTPOINT
/dev/vda      100G                   
├─/dev/vda1   512M   vfat           EFI      /boot/efi
├─/dev/vda2    98G   btrfs (LUKS)   FEDORA   /       
└─/dev/vda3   1.5G   ext4           BOOT     /boot

When the installation is complete, I will copy the contents of the /boot partition to the / file system. The final disk partition looks like this.

NAME           SIZE   FSTYPE         LABEL    MOUNTPOINT
/dev/vda       100G                   
├─/dev/vda1    512M   vfat           EFI      /boot/efi
└─/dev/vda2   99.5G   btrfs (LUKS)   FEDORA   /

And, these are the subvolumes that will be created from the encrypted btrfs volume (/dev/vda2).

NAME               MOUNTPOINT          TYPE
[main]             /                   mainvolume
home               /home               subvolume 
var/log            /var/log            subvolume
.snapshots         /.snapshots         subvolume
home/.snapshots    /home/.snapshots    subvolume

Below are the directories for which subvolumes are created and the reasons for doing so.

/home

Contains user data. It is created to keep user data separate and also to avoid loss of user data on / volume rollbacks.

/var/log

Contains log files. It is created to avoid the loss of log data during rollbacks.

/.snapshots

Contains snapshots of / volume. Allows you to undo any changes or completely roll back a snapshot from the GRUB menu.

/home/.snapshots

Contains snapshots of /home subvolume. Allows you to undo any changes in the /home directory. No rollbacks from the GRUB menu on the /home directory.

Depending on your needs, you may also want to create some additional subvolumes. For example, /opt, /var/www, /var/lib/libvirt/images, and so on.

2. Install Fedora 37 Workstation

Boot your system using the Fedora 37 Workstation installer in UEFI mode. On the welcome screen, select the Install to Hard Drive option. Next, select your LanguageKeyboard, and configure Time & Date. Following that, from the INSTALLATION SUMMARY screen, select Installation Destination.

You should now be on the INSTALLATION DESTINATION screen. To proceed, pick the Advanced Custom (Blivet-GUI) radio button and then hit the Done button.

How to Install Fedora 37 with LUKS Full Disk Encryption + Snapper + Grub-Btrfs Blivet

On the BLIVET GUI PARTITIONING screen, create the partitions, file systems, and btrfs subvolumes necessary to install Fedora 37 Workstation.

First, you need to create and mount the EFI partition. Select the free space and click the + sign to create a partition.

How to Install Fedora 37 with LUKS Full Disk Encryption + Snapper + Grub-Btrfs Blivet Overview

Set the partition size to 512 MiB, the filesystem to EFI System Partition, and the mountpoint to /boot/efi.

How to Install Fedora 37 with LUKS Full Disk Encryption + Snapper + Grub-Btrfs EFI

Then, you need to create a btrfs volume where you can create all the subvolumes needed to install Fedora 37 Workstation.

Select the free space again and click on the + sign to create a btrfs filesystem. Set the size of the btrfs filesystem. I allocated 98 GiB for the btrfs filesystem and left roughly 1.5 GiB unallocated for the /boot partition. Set btrfs as the filesystem and / as the mountpoint. Enable encryption, set encryption to luks2, and provide a strong passphrase with entropy greater than 60 bits. Finally, click on the OK button.

How to Install Fedora 37 with LUKS Full Disk Encryption + Snapper + Grub-Btrfs Root

You then need to create and mount the /boot partition. Set the boot partition to use all of the remaining unallocated space (1534 MiB), the filesystem to ext4, and the mountpoint to /boot. After the installation is finished, I’ll move the contents of the /boot partition to the main root file system and merge this 1.5 GiB space with the main BTRFS volume.

How to Install Fedora 37 with LUKS Full Disk Encryption + Snapper + Grub-Btrfs Boot

Next, you must create a home subvolume. (1) Select the Btrfs Volume from the left panel, and (2) click on the + sign on the right panel.

How to Install Fedora 37 with LUKS Full Disk Encryption + Snapper + Grub-Btrfs Create Subvolume

Create a home subvolume. Enter the name as home and mountpoint as /home. Click OK to finish.

How to Install Fedora 37 with LUKS Full Disk Encryption + Snapper + Grub-Btrfs Home

I will create the remaining subvolumes when the installation is finished. This is because the Anaconda installer does not allow you to create subvolumes with slashes (/) in their names, such as var/log.

For now, click Done to finish creating subvolumes.

On the SUMMARY OF CHANGES screen, double-check that everything is properly defined. To finalize the changes, click the Accept Changes button.

How to Install Fedora 37 with LUKS Full Disk Encryption + Snapper + Grub-Btrfs Summary

You will be returned to the INSTALLATION SUMMARY screen. Press the Begin Installation button to start the installation process. The installation process will start. Just sit back and relax.

How to Install Fedora 37 with LUKS Full Disk Encryption + Snapper + Grub-Btrfs Installation

When the installation is finished, click the Finish installation button and restart the system. After the computer restarts, you will be prompted for the LUKS passphrase.

How to Install Fedora 37 with LUKS Full Disk Encryption + Snapper + Grub-Btrfs LUKS Passphrase

Enter the LUKS passphrase that you provided. The last phase of the installation procedure will start. Click the Start Setup button to complete the remaining customization steps, such as setting a new login, password, and so on.

You will then be logged into the Fedora 37 Workstation with the all-new Gnome 43 desktop interface.

How to Install Fedora 37 with LUKS Full Disk Encryption + Snapper + Grub-Btrfs GNOME 43

Now, open the Gnome terminal.

Set the btrfs volume label. I named the btrfs volume FEDORA, but you may name it whatever you want.

$ sudo btrfs filesystem label / FEDORA
$ sudo btrfs filesystem show /
Label: 'FEDORA'  uuid: 551495dd-6ade-4c3a-b3e2-8499fd328d84
	Total devices 1 FS bytes used 6.08GiB
	devid    1 size 97.98GiB used 8.02GiB path /dev/mapper/luks-cba88ec4-737a-4fd4-982b-f358df4e07de

Create the /var/log subvolume.

$ sudo mv -v /var/log /var/log-old
$ sudo btrfs subvolume create /var/log
$ sudo cp -arv /var/log-old/. /var/log/
$ sudo restorecon -RFv /var/log
$ sudo rm -rvf /var/log-old

If you wish to create more subvolumes, use the same methods as above.

In the /etc/fstab file, add the newly created /var/log subvolume. The updated line is displayed in amber. Replace UUID with your setup’s UUID.

$ sudo vi /etc/fstab
UUID=551495dd-6ade-4c3a-b3e2-8499fd328d84 /         btrfs defaults,x-systemd.device-timeout=0 0 0
UUID=3b799f31-f992-4f32-b916-f7d048f47a80 /boot     ext4  defaults 1 2
UUID=7056-1E69                            /boot/efi vfat  umask=0077,shortname=winnt 0 2
UUID=551495dd-6ade-4c3a-b3e2-8499fd328d84 /home     btrfs subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0
UUID=551495dd-6ade-4c3a-b3e2-8499fd328d84 /var/log  btrfs subvol=var/log,compress=zstd:1,x-systemd.device-timeout=0 0 0

Reload the /etc/fstab file to mount all filesystems.

$ sudo systemctl daemon-reload
$ sudo mount -va

Your setup should now look somewhat like this.

$ lsblk -p
NAME                                                      MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
/dev/zram0                                                251:0    0  3.8G  0 disk  [SWAP]
/dev/vda                                                  252:0    0  100G  0 disk  
├─/dev/vda1                                               252:1    0  512M  0 part  /boot/efi
├─/dev/vda2                                               252:2    0   98G  0 part  
│ └─/dev/mapper/luks-cba88ec4-737a-4fd4-982b-f358df4e07de 253:0    0   98G  0 crypt /var/log
│                                                                                   /home
│                                                                                   /
└─/dev/vda3                                               252:3    0  1.5G  0 part  /boot

Finally, list all subvolumes.

$ sudo btrfs subvolume list /
ID 256 gen 65 top level 5 path home
ID 257 gen 51 top level 5 path var/lib/machines
ID 258 gen 70 top level 5 path var/log

The var/lib/machines subvolume is created by systemd implicitly in Fedora 37 Workstation for systemd-nspawn containers.

The Fedora 37 Workstation installation is now complete.

3. Move /boot to the / Filesystem

You must now copy the contents of the ext4 /boot partition to the /boot directory in the root file system and configure GRUB to boot from it.

First, unmount the /dev/vda3 (boot) and /dev/vda1 (EFI) partitions from the /boot directory.

$ sudo umount -vR /boot

Then, mount the /dev/vda3 partition in the /mnt directory temporarily.

$ sudo mount -v /dev/vda3 /mnt

Now, copy all boot files from /mnt to the /boot directory.

$ sudo cp -arv /mnt/. /boot

Unmount the /dev/vda3 partition from /mnt and delete its entry from the /etc/fstab file. You no longer need the /dev/vda3 partition.

$ sudo umount -v /mnt
$ sudo sed -i.original '/\/boot.*ext4/d' /etc/fstab
$ sudo systemctl daemon-reload
$ sudo mount -va

Restore the SELinux labels to the /boot directory.

$ sudo restorecon -RFv /boot

Enable the CRYPTODISK option in GRUB. When enabled, it will check the encrypted disks and generate the additional commands needed to access them during boot.

$ echo 'GRUB_ENABLE_CRYPTODISK=y' | sudo tee -a /etc/default/grub
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

The kernel and initrd paths are configured to look in the /boot partition (/dev/vda3).

$ sudo grubby --info=DEFAULT
index=0
kernel="/vmlinuz-6.0.7-301.fc37.x86_64"
args="ro rd.luks.uuid=luks-cba88ec4-737a-4fd4-982b-f358df4e07de rhgb quiet"
root="UUID=551495dd-6ade-4c3a-b3e2-8499fd328d84"
initrd="/initramfs-6.0.7-301.fc37.x86_64.img"
title="Fedora Linux (6.0.7-301.fc37.x86_64) 37 (Workstation Edition)"
id="a8e42b5bf3ef4631a3af52c673d68d12-6.0.7-301.fc37.x86_64"

This must be changed to the /boot directory in the / filesystem (/dev/vda2). To do this, first, remove the old Boot Loader Specification (BLS) configuration files.

$ sudo sh -c 'rm -i /boot/loader/entries/*.conf'

Then recreate the BLS config file by adding the kernel image.

$ sudo kernel-install -v add $(uname -r) /lib/modules/$(uname -r)/vmlinuz

Take a look at the newly created BLS configuration files. The ‘/boot‘ directory should be added to the kernel and initrd lines.

$ sudo grubby --info=DEFAULT
index=0
kernel="/boot/vmlinuz-6.0.7-301.fc37.x86_64"
args="ro rd.luks.uuid=luks-cba88ec4-737a-4fd4-982b-f358df4e07de rhgb quiet"
root="UUID=551495dd-6ade-4c3a-b3e2-8499fd328d84"
initrd="/boot/initramfs-6.0.7-301.fc37.x86_64.img"
title="Fedora Linux (6.0.7-301.fc37.x86_64) 37 (Workstation Edition)"
id="a8e42b5bf3ef4631a3af52c673d68d12-6.0.7-301.fc37.x86_64"

As CRYPTODISK is now enabled, you must make changes to /boot/efi/EFI/fedora/grub.cfg file as well.

List your device’s UUIDs first.

$ lsblk -po name,uuid,mountpoints /dev/vda
NAME                                                      UUID                                 MOUNTPOINTS
/dev/vda                                                                                       
├─/dev/vda1                                               7056-1E69                            /boot/efi
├─/dev/vda2                                               cba88ec4-737a-4fd4-982b-f358df4e07de 
│ └─/dev/mapper/luks-cba88ec4-737a-4fd4-982b-f358df4e07de 551495dd-6ade-4c3a-b3e2-8499fd328d84 /var/log
│                                                                                              /home
│                                                                                              /
└─/dev/vda3                                               3b799f31-f992-4f32-b916-f7d048f47a80

Set up access to the encrypted boot device by adding the cryptomount command.

$ CRYPTOUUID="$(sudo cryptsetup luksUUID /dev/vda2 | tr -d -)"
$ sudo sed -i.backup1 "1i cryptomount -u ${CRYPTOUUID}" /boot/efi/EFI/fedora/grub.cfg

Replace the /dev/vda3 device UUID with the UUID of a LUKS encrypted device where the / file system is mounted.

$ OLDUUID="$(lsblk -dno uuid /dev/vda3)"
$ NEWUUID="$(lsblk -dno uuid /dev/mapper/luks-$(sudo cryptsetup luksUUID /dev/vda2))"
$ sudo sed -i.backup2 "s/${OLDUUID}/${NEWUUID}/" /boot/efi/EFI/fedora/grub.cfg

And add /boot to the grub2 path.

$ sudo sed -i.backup3 's#($dev)/grub2#($dev)/boot/grub2#' /boot/efi/EFI/fedora/grub.cfg

In the end,  the modifications to the /boot/efi/EFI/fedora/grub.cfg file should be from this …

search --no-floppy --fs-uuid --set=dev 3b799f31-f992-4f32-b916-f7d048f47a80
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg

… to this.

cryptomount -u cba88ec4737a4fd4982bf358df4e07de
search --no-floppy --fs-uuid --set=dev 551495dd-6ade-4c3a-b3e2-8499fd328d84
set prefix=($dev)/boot/grub2
export $prefix
configfile $prefix/grub.cfg

The changes are as follows.

  • Line 1: Amber color. Set up access to the encrypted boot device. The UUID here is of the /dev/vda2 partition without dashes (-).
  • Line 2: Cyan color. Replace the UUID of /boot partition. The new UUID is of the LUKS encrypted / filesystem.
  • Line 3: Orange color: Insert the ‘/boot‘ directory into the ‘set prefix‘ line.

Finally, you need to change the Password-Based Key Derivation Function (PBKDF) algorithm for LUKS keyslot. By default PBKDF for LUKS2 is argon2id.

$ sudo cryptsetup luksDump /dev/vda2 | grep 'PBKDF:'
	PBKDF:      argon2id

However, GRUB currently only supports pbkdf2. As a result, you must change the PBKDF algorithm. You should also change the iteration count. The more powerful your CPU, the higher the iteration count. And, the higher the iteration count, the longer it takes to unlock the LUKS in the GRUB.

For pbkdf2, the minimum iteration count is 1000 and the maximum is 4294967295. I will set the iteration count to 500000. Lowering the iterations reduces security. To get around it, use a stronger passphrase with higher entropy.

$ sudo cryptsetup luksChangeKey \
    --key-slot 0 \
    --pbkdf pbkdf2 \
    --pbkdf-force-iterations 500000 \
    --force-password \
    /dev/vda2

Set the new password to the same one you used before.

Review the device LUKS encryption details.

$ sudo cryptsetup luksDump /dev/vda2
LUKS header information
Version:       	2
Epoch:         	4
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	cba88ec4-737a-4fd4-982b-f358df4e07de
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)
Data segments:
  0: crypt
	offset: 16777216 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 512 [bytes]
Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      pbkdf2
	Hash:       sha256
	Iterations: 500000
	Salt:       b4 02 c7 a4 75 18 30 8c 01 bf 38 c4 42 c9 73 a7 
	            a6 da 5b d4 f6 a2 df f5 0e 1e 70 04 85 eb e5 85 
	AF stripes: 4000
	AF hash:    sha256
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 93356
	Salt:       d6 2f cc 33 ee 65 86 42 7c 83 9c 86 00 c3 fe 01 
	            c7 80 74 6f 61 02 a0 e4 39 08 8a 30 e6 36 46 af 
	Digest:     7f 06 0a 46 6e 03 3c a1 3b 89 58 18 df c7 2e 5f 
	            f8 5b be 8f 7b 8f 9e be 27 fb 95 00 2c 04 41 10

Reboot the computer now to ensure that everything is working correctly. You will be prompted for the passphrase twice. The first time is before loading GRUB, and the second time is before mounting the root file system.

Depending on your computer’s CPU, it may take up to 15 seconds for the GRUB to display the second passphrase prompt. So please be patient.

When you input your passphrase in the first LUKS prompt, no “*” cursor indication appears. So you should assume you have entered your passphrase correctly. Simply enter your LUKS passphrase blindly and hit the [ENTER] key.

4. Remove the /boot Partition and Reclaim the Space

You no longer need the /dev/vda3 partition since you moved the boot files to the /boot directory in the / file system. So, you can safely remove the /dev/vda3 partition from the partition table and reclaim the 1.5 GiB it occupies.

Run the gdisk utility.

$ sudo gdisk /dev/vda

On the command input prompt, enter the key p to print the partition table.

Command (? for help): p
Disk /dev/vda: 209715200 sectors, 100.0 GiB
...
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System Partition
   2         1050624       206571519   98.0 GiB    8300  
   3       206571520       209713151   1.5 GiB     8300

Delete partition #3 (/dev/vda3) by pressing the key d and then the number 3.

Command (? for help): d
Partition number (1-3): 3

Command (? for help): p
...
Total free space is 3145661 sectors (1.5 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System Partition
   2         1050624       206571519   98.0 GiB    8300

Then, delete partition #2 (/dev/vda2) as well by pressing the key d and then the number 2. Don’t worry, until you permanently write the modifications, the data will not be lost.

Command (? for help): d
Partition number (1-2): 2

Command (? for help): p
...
Total free space is 208666557 sectors (99.5 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System Partition

Now, create a new partition by pressing the key n. Choose the entire disc space by pressing the [Enter] key four times. Don’t input any values; instead, let it use the defaults. Your data will remain intact with the new expanded size.

Command (? for help): n
Partition number (2-128, default 2): 
First sector (34-209715166, default = 1050624) or {+-}size{KMGTP}: 
Last sector (1050624-209715166, default = 209713151) or {+-}size{KMGTP}: 
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): p
...
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System Partition
   2         1050624       209713151   99.5 GiB    8300  Linux filesystem

As an option, you can modify the partition name.

Command (? for help): c
Partition number (1-2): 2
Enter name: Fedora 37 Workstation

Command (? for help): p
...

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System Partition
   2         1050624       209713151   99.5 GiB    8300  Fedora 37 Workstation

Finally, hit the w key to permanently save the table to disk and quit.

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/vda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

For the changes to take effect, restart the system. After restarting the system, use the following command to reclaim all available space on the BTRFS volume.

$ sudo btrfs filesystem resize max /

Now check the space used up by the BTRFS volume.

$ sudo btrfs filesystem show /
Label: 'FEDORA'  uuid: 551495dd-6ade-4c3a-b3e2-8499fd328d84
	Total devices 1 FS bytes used 6.25GiB
	devid    1 size 99.48GiB used 9.02GiB path /dev/mapper/luks-cba88ec4-737a-4fd4-982b-f358df4e07de

List to verify whether the /dev/vda3 partition has actually been removed.

$ lsblk -p /dev/vda
NAME                                                      MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
/dev/vda                                                  252:0    0  100G  0 disk  
├─/dev/vda1                                               252:1    0  512M  0 part  /boot/efi
└─/dev/vda2                                               252:2    0 99.5G  0 part  
  └─/dev/mapper/luks-cba88ec4-737a-4fd4-982b-f358df4e07de 253:0    0 99.5G  0 crypt /var/log
                                                                                    /home
                                                                                    /

5. Bypass the Additional Passphrase Prompt

While GRUB asks for a passphrase to unlock the encrypted /boot files, this information is not passed on to initramfs. As a result, during the initramfs stage, the root (/) must be unlocked once again. This means that either the user must input his passphrase twice, or the initramfs image itself must include a file with the root partition’s passphrase.

Because the initramfs image will be in the /boot directory of the encrypted root partition (/), the passphrase will be secure when the data is at rest. However, once the data is online, it must be safeguarded by making it read-only for the root user.

So let’s create a key file so that the passphrase is only asked once.

Create /etc/cryptsetup-keys.d directory if it is not already there.

$ sudo mkdir /etc/cryptsetup-keys.d

Create a key file with 4KiB of random data. The key file has to be in volume.key format.

$ sudo dd if=/dev/random \
    of=/etc/cryptsetup-keys.d/luks-$(sudo cryptsetup luksUUID /dev/vda2).key \
    bs=512 count=8

Ensure that only the root user has read access to the key file.

$ sudo chmod 0400 /etc/cryptsetup-keys.d/*.key

Attach the created key to the encrypted device’s available key slot. When prompted for a passphrase, enter the same LUKS passphrase.

$ sudo cryptsetup luksAddKey \
    --pbkdf pbkdf2 \
    --pbkdf-force-iterations 500000 \
    /dev/vda2 \
    /etc/cryptsetup-keys.d/luks-$(sudo cryptsetup luksUUID /dev/vda2).key

Open (or create) the /etc/dracut.conf.d/cryptodisk.conf file.

$ sudo vi /etc/dracut.conf.d/cryptodisk.conf

And add the following line to include the key in the initramfs image.

install_items+=" /etc/cryptsetup-keys.d/* "

Finally, rebuild the initramfs image.

$ sudo dracut -vf

Reboot the computer and verify that everything is operating correctly. The LUKS passphrase should only be asked once.

6. Install and Configure Snapper

Install snapper and the optional package python3-dnf-plugin-snapper. The python3-dnf-plugin-snapper package allows you to create pre and post snapshots every time you install a package on the system with the dnf package manager.

$ sudo dnf install snapper python3-dnf-plugin-snapper

Create new snapper configurations named root and home for the Btrfs volume at / and /home, respectively.

$ sudo snapper -c root create-config /
$ sudo snapper -c home create-config /home

Verify the snapper configuration files have been created.

$ sudo snapper list-configs
Config | Subvolume
-------+----------
home   | /home    
root   | /

Allow the regular user to list snapshots. Add your user name in the snapper’s root and home configurations.

$ sudo snapper -c root set-config ALLOW_USERS=$USER SYNC_ACL=yes
$ sudo snapper -c home set-config ALLOW_USERS=$USER SYNC_ACL=yes

Change the group permissions of the /.snapshots and /home/.snapshots directories to your user name.

$ sudo chown -R :$USER /.snapshots
$ sudo chown -R :$USER /home/.snapshots

Finally, in the /etc/fstab file, add the newly created snapshots subvolumes. The updated lines are displayed in amber.

$ sudo vi /etc/fstab
UUID=551495dd-6ade-4c3a-b3e2-8499fd328d84 /                btrfs defaults,x-systemd.device-timeout=0 0 0
UUID=7056-1E69                            /boot/efi        vfat  umask=0077,shortname=winnt 0 2
UUID=551495dd-6ade-4c3a-b3e2-8499fd328d84 /home            btrfs subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0
UUID=551495dd-6ade-4c3a-b3e2-8499fd328d84 /var/log         btrfs subvol=var/log,compress=zstd:1,x-systemd.device-timeout=0 0 0
UUID=551495dd-6ade-4c3a-b3e2-8499fd328d84 /.snapshots      btrfs subvol=.snapshots,compress=zstd:1,x-systemd.device-timeout=0 0 0
UUID=551495dd-6ade-4c3a-b3e2-8499fd328d84 /home/.snapshots btrfs subvol=home/.snapshots,compress=zstd:1,x-systemd.device-timeout=0 0 0

Reload the /etc/fstab file.

$ sudo systemctl daemon-reload
$ sudo mount -va

Your setup should look something like this.

$ lsblk -p /dev/vda
NAME                                                      MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
/dev/vda                                                  252:0    0  100G  0 disk  
├─/dev/vda1                                               252:1    0  512M  0 part  /boot/efi
└─/dev/vda2                                               252:2    0 99.5G  0 part  
  └─/dev/mapper/luks-cba88ec4-737a-4fd4-982b-f358df4e07de 253:0    0 99.5G  0 crypt /home/.snapshots
                                                                                    /.snapshots
                                                                                    /var/log
                                                                                    /home
                                                                                    /

And your subvolumes will look like this.

$ sudo btrfs subvolume list /
ID 256 gen 141 top level 5 path home
ID 257 gen 134 top level 5 path var/lib/machines
ID 258 gen 146 top level 5 path var/log
ID 259 gen 141 top level 5 path .snapshots
ID 260 gen 141 top level 256 path home/.snapshots

Enable snapshot booting by appending the SUSE_BTRFS_SNAPSHOT_BOOTING="true" option to the /etc/default/grub file.

$ echo 'SUSE_BTRFS_SNAPSHOT_BOOTING="true"' | sudo tee -a /etc/default/grub

Because snapshot booting is now enabled, you must make changes to the /boot/efi/EFI/fedora/grub.cfg file as well.

$ sudo sed -i '1i set btrfs_relative_path="yes"' /boot/efi/EFI/fedora/grub.cfg

Update the grub.cfg file.

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Finally, disable the GRUB menu auto-hide feature.

$ sudo grub2-editenv - unset menu_auto_hide

The snapper configuration is now complete.

List the snapshots for / volume. For the root, you may use snapper -c root ls or simply snapper ls. Both provide the same output.

$ snapper ls
 # | Type   | Pre # | Date | User | Cleanup | Description | Userdata
---+--------+-------+------+------+---------+-------------+---------
0  | single |       |      | root |         | current     |

List the snapshots for /home subvolume.

$ snapper -c home ls
 # | Type   | Pre # | Date | User | Cleanup | Description | Userdata
---+--------+-------+------+------+---------+-------------+---------
0  | single |       |      | root |         | current     |

At this stage, you do not have any snapshots, we will create some later.

7. Install and Configure Grub-Btrfs

Consider the following scenario: you make a mistake, and the system fails to start properly the next time. You may want to revert to a previously working snapshot and reboot again.

The grub-btrfs package provides this functionality. The package adds “Fedora Linux snapshots” to the GRUB menu and allows you to boot to a snapshot in read-only mode to test it before rolling back to it in read-write mode.

So, clone the grub-btrfs repository.

$ git clone https://github.com/Antynea/grub-btrfs
$ cd grub-btrfs
$ git switch Add-systemd-volatile

The setup is initially configured to work with Arch and Gentoo out of the box. To make it work with Fedora, you must make a few changes to the grub-btrfs config file.

$ sed -i 's/#GRUB_BTRFS_SYSTEMD_VOLATILE=/GRUB_BTRFS_SYSTEMD_VOLATILE=/' config
$ sed -i 's/#GRUB_BTRFS_GRUB_DIRNAME=/GRUB_BTRFS_GRUB_DIRNAME=/' config
$ sed -i '/#GRUB_BTRFS_MKCONFIG=/c\GRUB_BTRFS_MKCONFIG=/sbin/grub2-mkconfig' config
$ sed -i 's/#GRUB_BTRFS_SCRIPT_CHECK=/GRUB_BTRFS_SCRIPT_CHECK=/' config

Then install it.

$ sudo make INITCPIO=true install

Update the grub.cfg file. You will receive the ‘No snapshots found’ error since you have not yet created any snapshots, but don’t worry, it will function properly after you do.

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Finally, enable the grub-btrfs.path

$ sudo systemctl enable --now grub-btrfs.path

Your grub-btrfs installation is now complete. You may now delete the cloned grub-btrfs repository.

$ cd ..
$ rm -rvf grub-btrfs

8. Test the Snapper’s Undochange and Rollback Features

I ran several tests to confirm that everything is operating well and that there are no problems. Please see the Tests section of the article “How to Install Fedora 37 with Snapper and Grub-Btrfs for Full System Rollback” for more information.

9. Conclusion

Now that you have installed Fedora 37 with LUKS Full Disk Encryption, snapper, and grub-btrfs, you can now be certain that your data at rest is safe, and if you make a mistake, you can easily roll back to a previous functioning snapshot.

You can also better secure your machine from Evil Maid attacks by using UEFI Secure Boot custom key enrollment and a self-signed kernel and bootloader. Check out my other blog ‘Enable Fedora UEFI Secure Boot with Custom Keys and Self-Signed Bootloader, Kernel, and Modules‘ on how to do this.

If you want to configure the snapper to take snapshots at predetermined intervals. Visit the Arch Wiki’s Snapper page for more information.

Watch on YouTube

Comments

51 responses to “How to Install Fedora 37 with LUKS Full Disk Encryption, Snapper, and Grub-Btrfs for Full System Rollback”

  1. Ciril Avatar
    Ciril

    Hello,

    Getting error by command “ sudo sed -i.backup1 “1i cryptomount -u ${CRYPTOUUID}” /boot/efi/EFI/fedora/grub.cfg

    sed: can’t read /boot/efi/EFI/fedora/grub.cfg: No such file or directory

    Tryed same tutorila on 2 devices on both same error at same point.

    Best regards,
    Ciril

    1. Madhu Desai Avatar

      Is your computer UEFI? Is there any output from the following command?
      ls /sys/firmware/efi

      1. Ciril Avatar
        Ciril

        No such file or directory

        1. Madhu Desai Avatar

          That means your system uses BIOS rather than UEFI. Just ignore the section where it says ‘/boot/efi/EFI/fedora/grub.cfg’. You’ll be fine.

          1. Ciril Avatar
            Ciril

            Sadly i have to inform you that i ignored section where it says ‘/boot/efi/EFI/fedora/grub.cfg’
            At the end of step 3 didnt ask me for LUKS password twice but only once.
            When i went to part 4 and delete boot partition and resize Fedora Workstation partition, after reboot i get only grub-rescue :/

          2. Madhu Desai Avatar

            Hello, Ciril. There appears to be some misunderstanding. The tutorial is for UEFI systems. For UEFI systems, a separate 512 MiB EFI (vfat) partition must be created (check step 2). The rest of the tutorial assumes you’ve done so.

            Because you mentioned that the command’s output was “No such file or directory,” I assumed the system was for BIOS. So I advised you to disregard the ‘/boot/efi/EFI/fedora/grub.cfg’ section.

            However, if your system is for BIOS, you should have created a BootBIOS partition (2MiB) instead of an EFI partition (512 MiB) in part 2 of the tutorial. What the output for the command “lsblk -pf /dev/vda1” say?

          3. Ciril Avatar
            Ciril

            Ok, I understand now. Thanks for help.

  2. Nate Avatar
    Nate

    Make sure to remove any unneeded “boot=” option from your GRUB command line once you migrate /boot to your btrfs, especially if you have FIPS mode enabled, as one of the dracut FIPS scripts seems to kill the boot if it can’t see a block device matching the UUID specified in “boot=”.

  3. kajman Avatar
    kajman

    Hi, thanks for great tutorial! I followed it and everything works apart from booting into snapshots. After I do it, I shortly see the loading page with Fedora icon below (same as after entering password normally) and then I see the entries from boot:

    https://imgur.com/a/q85ks6q

    The screen flickers few times, I then see the same on my attached monitor and then nothing else happens. I’m left with this screen until I restart (ctrl+alt+del works normally).

    Any ideas on how to debug this?

    1. Madhu Desai Avatar

      First, boot normally. Remove the word ‘rhgb’ from the GRUB_CMDLINE_LINUX= line in the /etc/default/grub file. Update the grub file with the command ‘sudo grub2-mkconfig -o /boot/grub2/grub.cfg’. Then, reboot the system and attempt to boot from the snapshot to see if the error message appears on the screen.

      Next, if no error messages are displayed, enable the kernel message as well. Repeat the previous steps, but this time remove the word ‘quiet’ as well from GRUB_CMDLINE_LINUX= line and update the grub file. Reboot the computer and check for any error messages related to the problem.

      If neither of the previous steps solves the problem, disable the Intel graphics features by setting the “nomodeset” option. Add ‘nomodeset’ option in the GRUB_CMDLINE_LINUX= line and update the grub file.

      These are the only solutions I can think of right now.

      1. kajman Avatar
        kajman

        Thanks a lot for your quick answer. Removing quiet made me realise that the system boots, but the DE does not. I’ve installed Fedora i3 spin. I’ve noticed that lightdm does not start correctly because of file permission issues in /var/cache/lightdm and /var/lib/lightdm-data.

        Here is a pastebin of a failing snapshot boot (cut to lightdm.service only) and a normal boot that works:

        https://pastebin.com/QtjuRDwD

        The same issue occurs no matter what I set in GRUB_CMDLINE_LINUX (I’ve reverted it in the end).

        Did I mess something up during the partitioning?

        1. Madhu Desai Avatar

          Check that the kernel parameter ‘systemd.volatile=state‘ is added to the /etc/grub.d/41_snapshots-btrfs file.

          # grep 'systemd.volatile=state' /etc/grub.d/41_snapshots-btrfs

          If it exists, it should solve this problem. I’m not sure how lightdm works, but I’ll let you know once I’ve tried it on VM.

          1. kajman Avatar
            kajman

            The output of the command is:

                           [[ $(btrfs property get “$grub_btrfs_mount_point/$snap_dir_name_trim” ro) != “ro=false” ]] && kernel_parameters=”${kernel_parameters} systemd.volatile=state”;

          2. Madhu Desai Avatar

            Hello, Kajman. I just finished testing this issue in Fedora i3 with KVM virtualization. As you mentioned, it hangs just before the lightdm display manager is launched. The kernel parameter ‘systemd.volatile=state’ is specifically used to avoid this issue. It works very well for GDM and many other DMs. I’m not sure what the deal is with lightdm in i3.

            Anyway, here’s a solution you can try. Create separate subvolumes for the /var/lib/lightdm and /var/lib/AccountsService directories. These two directories should always be read-write, and by creating subvolumes for them, they will be out of the rollback regime.

            # mv /var/lib/lightdm /var/lib/lightdm-old
            # mv /var/lib/AccountsService /var/lib/AccountsService-old
            # btrfs subvolume create /var/lib/lightdm
            # btrfs subvolume create /var/lib/AccountsService
            # cp -arv /var/lib/lightdm-old/. /var/lib/lightdm/
            # cp -arv /var/lib/AccountsService-old/. /var/lib/AccountsService/
            # rm -rfv /var/lib/{lightdm-old,AccountsService-old}

            Add to /etc/fstab
            UUID=xxxx-xxx /var/lib/lightdm btrfs subvol=var/lib/lightdm,compress=zstd:1,x-systemd.device-timeout=0 0 0
            UUID=xxxx-xxx /var/lib/AccountsService btrfs subvol=var/lib/AccountsService,compress=zstd:1,x-systemd.device-timeout=0 0 0

            # systemctl daemon-reload
            # mount -va

            Relabel SELinux context for all files at the next boot.
            # fixfiles onboot
            # reboot

            The SELinux context are relabelled on the next boot. The system will then reboot again.

            Now, try rolling back to any snapshot and see if it works this time.

          3. Nate Avatar
            Nate

            If all we need to do is rollback, we don’t need really need lightdm to work properly anyway. It’s easier just to switch to another TTY and login, or add “systemd.unit=multi-user.target” to the GRUB command line for the snapshot. Either one of those should be sufficient for logging in on a TTY, doing a quick check, and rolling back. I suppose you could also switch from lightdm to another lightweight DM, like lxdm, but even that seems unnecessary.

  4. guy Avatar
    guy

    Please remake the same exact tutorial, but for Arch or Debian. Thanks.

  5. Antonio Avatar
    Antonio

    Hello, first of all this project is great, congratulations and thanks for teaching us.

    I would like to try this setup, I just have some questions, I would like to know what your recommendation is. I have a laptop with 2 built-in storage drives:
    1. 250GB SSD
    2.1TB HDD

    Currently I store everything in the /home directory such as: Documents, Photos, Videos etc using soft links on my HDD, this way when I want to do a fresh install of Fedora I don’t have to worry about backing up my Documents, photos etc.

    What is your recommendation?

    1. Madhu Desai Avatar

      Hi Antonio,

      Since you are setting up LUKS Full Disk Encryption, you must also include the HDD in the configuration, otherwise, the FDS will be useless.

      So you must first (1) encrypt the HDD using LUKS, (2) add to the /etc/crypttab file, (3) create a keyfile for the HDD as well because /home is required at boot, and only then consider linking the directory to the SSD.

      However, I’m not sure how the linked status of files would be affected if you undo the changes to the /home directory. I have to check.

      1. Antonio Avatar
        Antonio

        Thanks for your time.

        I would like to specify that the symbolic links are not direct with /home, in fact I don’t touch /home at all, I make symbolic links to each of the subdirectories INSIDE /home, that is: Documents/ Pictures/ Videos/ Etc. .

        That is the setup that I currently have, if you have any better suggestions to improve it I would also like to know because that is how I did it in Windows, I had my data in one partition and the OS in another one so that when I had to install Windows again I did not have to worry about making backups.

        And then what it did was point the Documents Pictures Videos etc folder locations to my other partition.

        And that is the same setup that I am applying here in Fedora using symbolic links.

      2. Antonio Avatar
        Antonio

        Hello, any advice of my last question?
        Thanks.

        1. Madhu Desai Avatar

          Hello, Antonio. I apologize for the delay in responding. I’m not sure how Windows works because I’m not experienced with it, but with Linux, the preferred way for keeping your data intact between distro hops/updates is to keep the /home in a separate partition or drive. When switching distros, just point to the partition/drive where your home files are located.

          1. Antonio Avatar
            Antonio

            Nothing to forgive, rather excuse me.

            Sorry for my delay too, I only have one question, in this tutorial I am seeing that the /home directory is a BTRFS subvolume, this is not what I want, is it?

            I want to have /home on another partition so that when I want to install Fedora from scratch I can do it without having to make backups.

          2. Madhu Desai Avatar

            Yes, precisely. Make a separate partition on the other disk for /home. In the Anaconda installer, choose both disks. Create an EFI, /, and /boot partition in the SSD disk, as demonstrated in this post. For /home, select the other HDD, select the partition created for home, set the file system as btrfs, and the mount point to /home. /home will no longer be a subvolume, but rather a main volume. Use the same passphrase for / and /home LUKS encryption.

          3. Antonio Avatar
            Antonio

            Thanks for your quick response and your time again.

            You know I already did that once and it wasn’t a good idea because my other disk is an HDD and something was happening (I suppose reading configuration files in /home) that suffered the consequences of slowness and for example in firefox when I opened many windows some Sometimes it seemed like thinking, so I chose to leave /home original and make symbolic links only to the Documents, Pictures etc… directories.

  6. Cutu Chiqueno Avatar
    Cutu Chiqueno

    Hi and thanks for the walkthrough. I wonder, if I might run into problems in future Fedora system upgrades if I differ from the standard installation configuration that Fedora carries out (moving and encrypting boot partition and so on; sorry for the unexperienced question)

    1. Madhu Desai Avatar

      Hello Cutu Chiqueno, you will not face any problems, so go ahead and install it without worries.

      If you look at the tutorial, you will notice that I’ve changed the standard install configuration in Fedora’s Anaconda installer itself. So Fedora very much knows where to look for files. The /var/log path remains unchanged, but is now within a subvolume, so, there is no problem. As for the /boot, after the initial install, changes will be made to the Boot Loader Specification (BLS) configuration files, so there will be no issues too.

      I recommend that you install it exactly as described in this article before doing any updates. When you are done, update the distribution with ‘dnf update’.

  7. Sophie Avatar
    Sophie

    Hi – have you tried using to enroll your device with your TPM chip? I followed this guide and managed to get the TPM chip to decrypt the main / partition without entering a password but still had to enter one for grub for /boot. Is it possible to get TPM to decrypt the /boot so you don’t have to enter any passwords (except at user login)?

  8. curie Avatar
    curie

    Wish one day argon2id and Plymouth can adapt to this method

      1. curie Avatar
        curie

        That’s awesome, cannot wait to see your tutor

      2. zpangwin Avatar
        zpangwin

        I hate to be the bearer of bad news, but it sounds unlikely that argon2 support will make it in the next grub version (2.12 – as 2.11 was a dev release only).

        https://lists.gnu.org/archive/html/grub-devel/2022-11/msg00094.html

        Shame. I too was really looking forward to argon2 support but I guess if there are still bugs being worked out, it makes sense not to rush something so fundamental to the startup process.

        1. Madhu Desai Avatar

          Yes, it’s really sad. Unlike other applications, the GRUB update cycle is very slow. The current version is over a year and a half old. If they don’t make it to the next version, who knows when they will?

          But from the link you posted, in the last paragraph, Patrick said he intended to have another look at it, so we have to wait and see what happens finally. Fingers crossed.

  9. curie Avatar
    curie

    Can I combines grub-btrfs with Refind / systemd-boot?
    last time I tried to put grubx64.efi (which is from default fedora grub) in the refind boot list.

    It gave me error related to Secure boot. But I was able to boot vmlinux without a problem. I have set up secureboot already

    1. Madhu Desai Avatar

      I haven’t tried rEFInd, so I can’t advise you on that.

      1. curie Avatar
        curie

        That’s fine. I’ll inform you once I’ve found the wokring method

  10. curie Avatar
    curie

    Is this time luks2 boot encryption can decrypt faster at boot ?

    1. Madhu Desai Avatar

      The PBKDF is still pbkdf2. I have reduced iterations to 500000, so it is faster at boot.

      1. curie Avatar
        curie

        how much did it take to boot, compare to Luks1 tutorial you posted for Fedora 35/36

        1. Madhu Desai Avatar

          Since the algorithm for both is pbkdf2 (for LUKS1 it is the default), the time will be the same. Depends on iteration counts and the processor. The faster the processor, the larger the iteration count, and the slower it boots. So I have fixed it to 500000. The advantage of LUKS2 is that it has a larger header size, so you can easily convert it to argon2id.

  11. curie Avatar
    curie

    i don’t know why, i just feel like Timeshift is a more stable and easier to use.

    I tried to configure snapper daily snapshots and automatically delete settings.But it never works out for me.

    for example, I set keeping 3hourly, 2daily, 1weekly, 1monthly. and no more than 10G

    But the .snapshots always chunk out more than 10GB, I have to delete them manually.

    Also, the snapper-gui kinda difficult to use, i wanted it to show snapshots files different SOMEWHAT not work the way I wanted it to be.

    I could always, successfully restore the system to a timestamp through Timeshift. However, snapper sometimes work sometimes the system is busted.

    However, there’s one major feature Snapper very well, like it does live restore while timeshift have to restart everytime

  12. Andrea Avatar
    Andrea

    Hello, i have Fedora 36 installed on my laptop whit full encryption and snapper and works very well.
    Thanks for your previous guide and for works you do.
    I would like to upgrade to Fedora 37 and would like to know if there are any issues about it with the configuration in full-disk encryption + snapper.
    Thank you very much

    1. Madhu Desai Avatar

      Hello, Andrea. There will be no problems when you upgrade to v37. As you already have snapper installed, create a manual ‘pre’ snapshot before upgrading to Fedora 37. When you are finished with the upgrade, whether it was successful or not, create a manual ‘post’ snapshot for the previously created ‘pre’ snapshot.

      If you are happy with the upgrade, just delete all of the pre-post snapshots and move on. If you are unhappy with the upgrade, just undo the changes and start over.

  13. jay Avatar
    jay

    Thank you for the guides on every version. Do you know if it’s possible to achieve any of the above using Fedora Kickstart?

    1. Madhu Desai Avatar

      Might be. I’ve never tried. The results will be interesting to see. I’ll give it a shot soon.

      1. jay Avatar
        jay

        Nice. Let me know if I can help. Was evaluating doing this myself but haven’t played with Kickstart yet.

        1. Madhu Desai Avatar

          Thanks. This weekend, I’ll give it a shot. I’ll let you know what I come up with.

  14. Eli Avatar
    Eli

    Will there be a video to go along with this?

    1. Madhu Desai Avatar

      Hello, Eli. I’ve already begun to screen-record. By tomorrow, I’ll upload the video.

  15. smithy Avatar
    smithy

    We last had correspondence in relation to your previous article on the above subject matter. The implementation of your previous article with the Raid has work well, thanks. I am now considering updating to Fedora 37 using the same setup. In reading through your current Fedora 37 article I notice that you now use LUKS2 for the brtfs partition. I take it that the issue which prevented LUKS2 being used in the Fedora 36 Version has been fixed.
    This being the case is it possible to change the Fedora 36 version btrfs partition to LUKS2 without having to start from scratch and then upgrade to Fedora 37, or should I upgeade to Fedora 37 and then change the btrfs partition to LUKS2. Is it very involved?

    1. Madhu Desai Avatar

      Hello, Gorden. LUKS2 is also compatible with Fedora 36. It’s only that I studied how openSUSE and Manjaro Linux encrypt their drives, and I spent a lot of time figuring out how to implement it in Fedora. Because these distributions used LUKS1, I also used LUKS1. Now that I’ve learned more about cryptsetup, I’m using LUKS2.

      To convert LUKS1 to LUKS2, boot your system with any Fedora Live CD. It doesn’t matter if you’re using 36 or 37.

      Run the following commands. I’m assuming the btrfs partition is /dev/sda2.
      cryptsetup convert --type luks2 /dev/sda2

      Confirm that the encryption is now LUKS2.
      cryptsetup luksDump /dev/sda2

      Reboot back to your system. That’s all.

      If you want to change the number of iterations to speed up the boot, do the following.

      First, remove the keyfile.
      cryptsetup luksRemoveKey /dev/sda2 /etc/cryptsetup-keys.d/luks-xxxx-xxx.key

      Then change the iteration count of pbkdf2 in key slot 0. When asked for a new passphrase, provide the same earlier passphrase.
      cryptsetup luksChangeKey --key-slot 0 --pbkdf pbkdf2 --pbkdf-force-iterations 500000 /dev/sda2

      Add the keyfile back.
      cryptsetup luksAddKey --pbkdf pbkdf2 --pbkdf-force-iterations 500000 /dev/sda2 /etc/cryptsetup-keys.d/luks-xxxx-xxx.key

      Check again to confirm that the iterations have been changed.
      cryptsetup luksDump /dev/sda2

      Now you can upgrade to Fedora 37.

Leave a Reply

Your email address will not be published. Required fields are marked *