[feat-req] Offer disk encryption (LUKS)

[1ace]

It would be good to offer disk encryption (as an option, obviously).

[christianhorn]

Workaround for now is to create a rescue-installation on a USB-connected device, boot from that and then encrypt: https://davidalger.com/posts/fedora-asahi-remix-on-apple-silicon-with-luks-encryption/ .

[stapelberg]

Thanks for sharing your guide!

I didn’t see that in time and went a slightly different route, re-creating the root file system from a tar archive.

That worked as well, but I had to fix SELinux before the system would boot.

Here’s my raw transcript in case it helps anyone else:

asahi linux encryption transcript

Create a tar archive of all mounted file systems:

sudo tar cpf /tmp/root.tar / --one-file-system
sudo tar cpf /tmp/home.tar /home --one-file-system
sudo tar cpf /tmp/boot.tar /boot /boot/efi --one-file-system

(While /home and /boot are subvolumes of the same file system,
tar’s --one-file-system option is not smart enough to realize that.)

create live USB stick: https://github.com/leifliddy/asahi-fedora-usb
boot live USB stick

overwrite root file system with encrypted version:

cryptsetup luksFormat /dev/nvme0n1p6
lsblk -p -o name,fstype,fsver,label,uuid
cryptsetup luksOpen /dev/nvme0n1p6 luks-92df6f89-0e47-42a4-95f5-0e542ecb1ba8
mkfs.btrfs -L fedora /dev/mapper/luks-92df6f89-0e47-42a4-95f5-0e542ecb1ba8

mkdir /mnt/sysimage

mount /dev/mapper/luks-92df6f89-0e47-42a4-95f5-0e542ecb1ba8 /mnt/sysimage/
btrfs subvolume create /mnt/sysimage/root
btrfs subvolume create /mnt/sysimage/home

mount -o subvol=root /dev/mapper/luks-92df6f89-0e47-42a4-95f5-0e542ecb1ba8 /mnt/sysimage
mkdir /mnt/sysimage/{boot,home,dev,proc,sys}
mount /dev/nvme0n1p5 /mnt/sysimage/boot
mount /dev/nvme0n1p4 /mnt/sysimage/boot/efi
mount -o subvol=home /dev/mapper/luks-92df6f89-0e47-42a4-95f5-0e542ecb1ba8 /mnt/sysimage/home
mount -B /dev /mnt/sysimage/dev
mount -B /proc /mnt/sysimage/proc
mount -B /sys /mnt/sysimage/sys

restore the backups from earlier:

cat root.tar | ssh root@10.73 'cd /mnt/sysimage && tar xvf -'
cat boot.tar | ssh root@10.73 'cd /mnt/sysimage && tar xvf -'
cat home.tar | ssh root@10.73 'cd /mnt/sysimage && tar xvf -'

edit /etc/default/grub to include rd.luks.uuid and make the menu appear for easier troubleshooting:

GRUB_CMDLINE_LINUX_DEFAULT="rhgb quiet rd.luks.uuid=luks-92df6f89-0e47-42a4-95f5-0e542ecb1ba8 rootflags=subvol=root"
GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=menu

Then, update the GRUB config:

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

edit /etc/fstab to update the root file system UUID:

UUID=e38aaeb0-2c21-493b-97b0-d017b1768aa3 / btrfs x-systemd.growfs,compress=zstd:1,defaults,subvol=root 0 1
UUID=f1e28fc7-cad5-498e-b9bc-ed4addde9a9b /boot ext4 defaults 0 0
UUID=e38aaeb0-2c21-493b-97b0-d017b1768aa3 /home btrfs x-systemd.growfs,compress=zstd:1,subvol=home 0 0
UUID=E2BA-FACA /boot/efi vfat defaults,umask=0077,shortname=winnt 0 0

re-generate initramfs:

dracut --regenerate-all -f

arrange for SELinux to be re-labeled next boot:

sudo touch /.autorelabel

see also https://docs.fedoraproject.org/en-US/quick-docs/selinux-changing-states-and-modes/

umount /mnt/sysimage/proc
umount /mnt/sysimage/sys
umount /mnt/sysimage/dev
umount /mnt/sysimage/boot/efi
umount /mnt/sysimage/boot/
umount /mnt/sysimage/home
umount /mnt/sysimage/
reboot

in GRUB, boot with enforcing=0 to make the SELinux relabel work

https://fedoraproject.org/wiki/How_to_debug_Dracut_problems

I would definitely welcome an option to enable full disk encryption in the Asahi installer over this complicated process :)

[christianhorn]

FWIW, I think there would already be benefit from having the reencode or the backup/encrypt/restore scripts here on github, so we as community can send pull requests. For example, the reencode-script can be misunderstood in saying "This will destroy everything on the partition, please be careful!", while in reality (minus potential bugs in the tools) the operation is really reencoding, and nothing is lost.

[iMonZ]

That would be awesome! LUKS2 by default

[buchpat]

that's the only thing that stops me from using Asahi as a daily driver :)
is this feature already being planned?
♥

[christianhorn]

@buchpat If there is something really preventing you from doing it manually as per above linked docs, please bring it up here. By all known so far: while it would be more convenient to have directly in the installer, it's possible to be done manually and only costs additional time (and a free usb attachable storage device).

[trickpattyFH20]

@christianhorn I am unable to get a usb boot in order to do the workaround.
https://github.com/leifliddy/asahi-fedora-usb

The asahi-fedora-usb script looks like it worked, there were no errors output.

I was able to build it and install on a few usbs, but u-boot won't recognize any of them.
Even after running usb reset multiple times and trying multiple ports and cables, usb-c and usb-a, the usb only shows up maybe 1 / 100 times (not sufficient).
Even when I was finally able to get u-boot to recognize the usb, booting from it failed.
After selecting "usb0" from the bootmenu, I got:

Error reading cluster
Loading Boot0003 'usb 0' failed
Loading from BootNext failed, falling back to BootOrder
Booting: nvme 0

Are there any more recent guides on setting up a usb drive with asahi fedora?
Or any other methods to get an encrypted internal fedora install?

[christianhorn]

@trickpattyFH20 Fair enough.. I had done this a year ago. I used a USB-C connected NVMe enclosure for better performance than most USB-sticks, and I did not run into compat issues by then. If someone has a stick setup, offering that as image might help a bit already.

[albert-a]

@trickpattyFH20,

I use this script to encrypt the installation with one command: https://github.com/osx-tools/asahi-encrypt

As in recommendations in README, I installed a 16G Asahi minimal system at the end of the disk and encrypted my main installation from there. No need to mess with USB sticks, although you can run it from USB.

It works! I tested it multiple times.