Encrypted ZFS root unlockable by presence of a USB drive OR password

Lockheed · 2025-01-11 12:04:06

Currently, I am running ZFS on LUKS. If a USB drive is present (with some random dd written to an outside-of-partition space on the USB drive) is present, my laptop boots without any prompt. If the USB drive is not present, it asks for password.

I want to ditch LUKS and use root ZFS encryption directly. Is that possible to replicate that functionality with encrypted ZFS? All I found so far was things that relied on calling modified zfs-load-key.service
(like so: https://forum.openmediavault.org/index. … l-no-luks/ )
but I don't think that would work for root, as the service file would be on the not-yet-unlocked partition.

WorMzy · 2025-01-11 12:56:00

Mod note: moving to AUR Issues

cryptearth · 2025-01-11 13:02:50

if at all it's job of the initrd to load the key and unlock the root dataset - so however you setup your current setup with luks (which, btw, should be avoided as in don't layer zfs inside other containers - zfs is designed with direct whole drive access in mind) to search for the key and load it this "just" has to be switched to use zfs instead

my very personal opinion: aside from encryption, unless you have a specific requirement to have the OS on a raid setup (like for a sever which requires high availability) just don't - follow KISS and keep the OS and its boot as simple as possible - if at all maybe encrypt /home - or just have a mountpoint in it to which some encrypted container can be mounted to
don't get me wrong - for me ZFS is the future of a hopefully proper cross-platform array filesystem - but to rely on it for boot and the OS quite a lot of the overall surrounding infrastructure like UEFI and boot loaders(/managers) have to change and properly support it - as long as we still limited to the UEFI spec only requires a single ESP on a single drive to be the sole start point of the boot chain and hence the user has to keep several ESPs across multiple boot drives in sync in such a way that in the event the current boot drive fails the uefi can just failover to the next drive all on its own without manual intervention and fully boot the system back up from there to me there's just no practical difference between using ZFS for the system root and just an EXT4 and mount the pool at some mountpoint within it - and I don't see that ZFS will become part of the UEFI spec any time soon
as for encryption: to keep it short: I do see the point in mobile devices and business use - but for a private desktop at home I just don't - and don't start with nonesense like "but what if a buglar breaks into your home" - well then you have way more serious problems than your desktop got stolen along with all your other stuff

Lockheed · 2025-01-11 13:26:03

@WorMzy, it has nothing to do with AUR. But thanks for burying my question in an irrelevant pile, preventing it from getting any non-accidental glance from a competent responder. Top job there, pal. Competent mod of a year award, no doubt.

@cryptearth, Root ZFS is not any kind of ride. Single-device only.

Also, I have learnt this is impossible since ZFS for some nonsensical reason has only one unlock method per dataset enabled. However, it gave me an idea to have a small LUKS partition, containing just the keyfile, unlock in the old way, and they have it available for root dataset at boot.

Lone_Wolf · 2025-01-11 13:33:28

ZFS is not in arch repos and the archwiki zfs page clearly states users need to install aur packages.

If you want a more general discussion about the ZFS filesystem, try posting in GNU/Linux Discussion .

Lockheed · 2025-01-11 13:35:43

You can also install ZFS from external repos, not AUR. And the discussion is not about installing ZFS, but about ways to make it boot while encrypted. Hard to get more "System Administration" than that.

WorMzy · 2025-01-11 13:57:29

They are still unsupported packages whether they are pre built by someone other than yourself. ZFS is not supported by Arch, and moving the topic here is preferable, I think, than to the dustbin? Up to you, of course, feel free to request deletion if you prefer.

cryptearth · 2025-01-11 14:37:11

@OP doesn'T really matter if a single-drive pool or an array of multiple drives - a zfs pool is a zfs pool - which is an implicit stripe (raid0) across one or more data vdevs, which can have different layouts, and maybe additional special vdevs
point is: zfs requires a zfs capable bootloader along with additional work to keep the system in sync with the boot files - although, according to the countless topics about boot issues after update this seems to be a more general issue of Arch itself

anyway - I recommend you open an issue at the upstream zfs repo about your feature request: https://github.com/openzfs/zfs

@mods
actuall the archzfs team currently works on to make the github repo an actual pacman-repo with proper key management https://github.com/orgs/archzfs/discussions/555 - so the wiki info "AUR has to be used" is outdated at best - so I agree with OP that the question isn't really AUR related
also have a look at the AUR pkgbuild:

# This PKGBUILD was generated by the archzfs build scripts located at
#
# http://github.com/archzfs/archzfs

so if at all the AUR version could be seen as just another way to aquire the exact same package already provided at github which increases the "distance" between zfs and aur even further and by implication OPs question about how to USE zfs - not how to acquire or build it
in fact: I build, use and provide packages on my "fork" https://github.com/n0xena/archzfs as the archzfs auto-build-bot sometimes encounters issues due to kernel and zfs updates and currently doesn'T prodive 2.3.0-RC builds - so no need for aur or even dkms

Lockheed · 2025-01-11 15:13:23

cryptearth wrote:

anyway - I recommend you open an issue at the upstream zfs repo about your feature request: https://github.com/openzfs/zfs

The issue has been opened over 7 years ago and to this day hasn't been implemented or even worked on.
https://github.com/openzfs/zfs/issues/6824
It is quite staggering as it is a pretty basic and critical function, and the underlying fundamentals seem to be have been in place from the start.

BTW
What is the difference in use case between your repo and main archzfs repo?

Last edited by Lockheed (2025-01-11 15:18:53)

cryptearth · 2025-01-12 03:40:51

Lockheed wrote:

The issue has been opened over 7 years ago and to this day hasn't been implemented or even worked on.
https://github.com/openzfs/zfs/issues/6824
It is quite staggering as it is a pretty basic and critical function, and the underlying fundamentals seem to be have been in place from the start.

I only gave it rough look so I likely miss something of the history of this issue - can't say anything to it - but as mentioned in my first reply: aside from obvious needs I'm not a fan of encrypting local drives

Lockheed wrote:

What is the difference in use case between your repo and main archzfs repo?

- I provide 2.3.0-RC
- I build my packages manual instead of rely on an auto pipeline - which keeps breaking from time to time
- I provide my fork so noone has to trust me but everyone can start from the archzfs repo and implement my changes on thier own - which is pretty much just keep uptodate with upstream zfs and current kernel versions
I also looked into getting the broken targets linux-vfio and archiso working again - but as I don't have any reference that's a task I'm not up to

overall I do recommend the official archzfs repo - but be aware it keeps breaking from time to time - and if you want to test zfs 2.3 it only provide git packages
with the release of zfs-2.3.0 and the archzfs already up to date my repo is now obsolete

Last edited by cryptearth (2025-01-15 09:49:33)

mackin_cheese · 2025-01-12 18:47:28

cryptearth wrote:

actually the archzfs team currently works on to make the github repo an actual pacman-repo with proper key management https://github.com/orgs/archzfs/discussions/555 - so the wiki info "AUR has to be used" is outdated at best - so I agree with OP that the question isn't really AUR related

Until it's in the official arch repos, the archwiki is correct and the mods are correct. it's an AUR issue. Until ZFS has a dedicated package maintainer and becomes part of the official repo, it's not supported (therefore not a System Administrator issue).

Last edited by mackin_cheese (2025-01-12 20:58:21)

Arch Linux

#1 2025-01-11 12:04:06

Encrypted ZFS root unlockable by presence of a USB drive OR password

#2 2025-01-11 12:56:00

Re: Encrypted ZFS root unlockable by presence of a USB drive OR password

#3 2025-01-11 13:02:50

Re: Encrypted ZFS root unlockable by presence of a USB drive OR password

#4 2025-01-11 13:26:03

Re: Encrypted ZFS root unlockable by presence of a USB drive OR password

#5 2025-01-11 13:33:28

Re: Encrypted ZFS root unlockable by presence of a USB drive OR password

#6 2025-01-11 13:35:43

Re: Encrypted ZFS root unlockable by presence of a USB drive OR password

#7 2025-01-11 13:57:29

Re: Encrypted ZFS root unlockable by presence of a USB drive OR password

#8 2025-01-11 14:37:11

Re: Encrypted ZFS root unlockable by presence of a USB drive OR password

#9 2025-01-11 15:13:23

Re: Encrypted ZFS root unlockable by presence of a USB drive OR password

#10 2025-01-12 03:40:51

Re: Encrypted ZFS root unlockable by presence of a USB drive OR password

#11 2025-01-12 18:47:28

Re: Encrypted ZFS root unlockable by presence of a USB drive OR password

Board footer