Since a few versions zfs now comes with a tool to write a hostid to /etc/hostid. Should we recommend using it instead of the provided C code?

Charlesmilette (talk) 22:32, 2 January 2018 (UTC) Charles Milette

With the changes to `base` and looking at ALEZ, it looks as though ALEZ may not be up to date with the metapackage change which could potentially lead to an unbootable system. Is there any confirmation that ALEZ still works?

Johncrist1988 (talk) 04:34, 16 October 2019 (UTC)

It should be working as is since the current release from last month was before the base change, however I will update the script accordingly and release new ISO.

Johnramsden (talk) 05:07, 16 October 2019 (UTC)

If you follow the suggestions on encryption one ends up with not being able to use ZFS's send/recv of all child datasets, without the drawback, that a encryption key needs to be loaded for each dataset (when they are send one by one). The reason is, that the dataset zroot is created due to the zpool creation and therefor it is read only. When you want to receive a (recusive) raw-data stream (which is IMO the only option) it can not take place on the existing zroot (even with recv -F option). Since rootfs is anyhow not suggested to reside on zroot but zroot/ROOT/default, I think think a layout like an unencrypted z pool with a residing encrypted z/root filesystem would be best option that can be send away in order to clone a complete system (e.g. desktop setup).

Einsiedlerkrebs (talk) 13:25, 14 November 2022 (UTC)

As the current situation stands, GRUB severely lags behind OpenZFS development. Many features need to be disabled on the pool which GRUB will boot from.

OpenZFS official guide has adopted the approach of creating separate boot pool (mounted at /boot) and root pool (mounted at /) since at least Debian Stretch days.

A separate swap partition is also recommended over swap on zvol to avoid deadlocks.

I've completed a guide for Root on ZFS here, containing the above fixes.

One might argue why don't just mount esp at /boot, here's my argument: with /boot on a ZFS pool, it is possible to select initramfs from a ZFS snapshot in GRUB, which enables recovery from a faulty initramfs. If stored in esp, there's no way to rescue a system with bad initramfs, or do a full system rollback to a previous state, as contents in /boot is not protected by ZFS.

rozb3-pac^AUR relies on separate boot and root pools to perform a full system rollback.

M0p (talk) 16:38, 24 December 2020 (UTC)

Hi,

Since I broke my grub-compatibility by accidentally enabling a zfs feature which is not supported by grub, I looked for alternative methods to boot a ZFS root pool I found zfsbootmenu https://zfsbootmenu.org/ which is IMHO the best way to boot a ZFS (EFI only?):

• Just drop the zfsbootmenu.EFI file from https://github.com/zbm-dev/zfsbootmenu/releases in a EFI subdirectory on your EFI Partition and configure your NVRAM with efibootmgr to use that file
• You now get a menu which finds all pools and boot environments, provides an emergency shell (with zfs tools) and a nice menu which allows for cloning/booting older snapshots and much more
• It works with probably every ZFS feature because it boots a complete kernel with ZOL enabled.

I am new to writing wiki entries and I don't have the rights to modify this article, (which is probably a good idea) but maybe any of you arch-zfs-enthusiasts can look into zfsbootmenu and confirm that it is what we are all looking for.

More detailed instructions (may be used to include in the wiki):

Install ZFS Boot Menu

#mount your EFI Partition
mount /dev/sdXY /efi
#create subfolder for ZBM
mkdir -p /efi/EFI/zbm
#download the latest release from https://github.com/zbm-dev/zfsbootmenu/releases
wget https://github.com/zbm-dev/zfsbootmenu/releases/download/v1.10.1/zfsbootmenu-x86_64-v1.10.1.EFI -O /efi/EFI/zbm/zfsbootmenu.EFI
#add entry to your bootmenu
efibootmgr --disk /dev/sdX --part Y --create --label "ZFSBootMenu" --loader '\EFI\zbm\zfsbootmenu.EFI' --unicode "spl_hostid=$(hostid) zbm.timeout=3 zbm.prefer=zroot zbm.import_policy=hostid" --verbose

you can probably also just name the file /efi/EFI/BOOT/BOOTX64.EFI on an EFI partition of an USB stick in order to make it bootable without a custom NVRAM entry (https://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/)

Configure ZFS Boot Menu In order to keep your current kernel parameters, you should set them as zfs property **org.zfsbootmenu:commandline** on the bootfs, but exclude the root and bootfs parameters

#lookup your current commandline
cat /proc/cmdline
-> zfs=zroot/ROOT/arch noresume init_on_alloc=0 rw spl.spl_hostid=0xdeadbeef
#set the property without the zfs parameters
 zfs set org.zfsbootmenu:commandline="noresume init_on_alloc=0 rw spl.spl_hostid=0xdeadbeef" zroot/ROOT

Pitfalls

• If your ZFS root is readonly after boot this make sure you have the parameter **rw** in your commandline (you can set this interactively in the menu for one boot, but you should configure the org.zfsbootmenu:commandline property as mentioned above
• If you are booting into an old snapshot and the system does not boot at all you probably have the https://wiki.archlinux.org/title/ZFS#Using_zfs-mount.service enabled which mounts your current rootfs over your snapshottet rootfs. In order to avoid that make sure you set the zfs canmount property to noauto on the root filesystem (which is mounted by the kernel anyway)

—This unsigned comment is by Thomas.oster (talk) 08:38, 16 July 2021 (UTC). Please sign your posts with ~~~~!

Thomas, I think you don't have rights to edit the article because you still don't have the 20 edits needed to become an autoconfirmed user. Regarding `zfsbootmenu`, that's very interesting and helpful, indeed, thank you! I don't have yet that much experience with EFI, otherwise I would've helped myself. My initial impression is that a well-tested AUR package with, among other things, proper initcpio support, may be rather helpful here, otherwise some less experienced or overly enthusiastic users might get themselves in trouble (many of us have at one point or another been guilty of "boldly testing in production", though fewer will probably openly admit to it :D).
— Kerberizer • T/C 10:47, 16 July 2021 (UTC)

I could provide an AUR package, but it is not so easy, because the EFI directory is not mounted on every system and not on the same mountpoint. Also an AUR package writing to the NVRAM on installation does not feel right. However if some people using ZFS root and EFI could just test it by booting from an USB Stick containing ZFS Boot menu, we could add the proper process to the wiki as an alternative to GRUB and create a standard way with defined names and mountpoints.
Thomas.oster (talk) 06:35, 29 September 2021 (UTC)

Thomas, I think that an AUR package with just the EFI binary might indeed be okay as a start, together, as you suggest, with an additional information on the wiki on how to actually use it (not unlike packages like edk2-shell).

There is something that bothers me a little bit, though, in particular if ZBM's EFI binary is used. Their latest release, for example, is built with Linux 5.12.14 and ZFS 2.1.0. The kernel version is fine for the task, I guess, but the ZFS version apparently might lag a bit behind upstream OpenZFS. Perhaps the ZBM developers will be diligent enough to publish new releases as new ZFS versions come out (latest is 2.1.1, but let's say it's okay to skip it, as it is only a patch-level release). Still, that's something that one should perhaps be mindful of; even more so if using the zfs*-git packages. Of course, problems would arise only if new and incompatible ZFS features are introduced, but in the end that's what has also been breaking Grub at different times.

This actually is the reason why for my own systems -- I've been resisting UEFI for years, but recently realized it's high time to abandon BIOS/CSM -- I've chosen an extremely simplistic and hopefully foolproof approach: systemd-boot, an EFI partition on each disk in the root pool, and a path-activated service that copies the kernel, initramfs, firmware, EFI shell, etc. to each EFI partition (mostly following some of the suggestions in systemd-boot). But, of course, I don't use boot environments, which is the main point of ZBM, and which I'm sure many people find useful or even necessary for their own tasks. On a side note, the boot process in Linux probably needs a general refresh, especially in terms of security -- it was interesting to read Poettering's opinion these days. That's quite a different topic, of course, yet I've also been thinking how ZFS would fit in such changes, which might happen one day whether we like them or not, much like systemd did. </offtopic>

As for possible testing, I might be able to do some, but since ZBM, sadly, seems to not fit that well my needs, I hope other people, who would actually use it, will step in.
— Kerberizer • T/C 11:46, 29 September 2021 (UTC)

Kerberizer You are right about the ZFS version problem. That's why I created a docker image which builds the ZBM efi binary: https://github.com/zbm-dev/zfsbootmenu/pull/193. But this still depends on the packages of void linux. They promised they will be nearly instant up to date, but it would be of cause better if that AUR package would build an EFI binary from the currently installed arch packages (similar as DKMS). I personally copy my kernel and initramfs to the EFI partition automatically and boot it directly as efi stub, but if I ever need to rollback or temporarily boot an old snapshot, I can boot zfs boot menu and just select the snapshot, which always contains the kernel and initramfs which was pesent at that time.
Thomas.oster (talk) 12:00, 29 September 2021 (UTC)

Thomas, ah, it's obvious how I still lack experience with UEFI and forget that it's much easier to boot different things—from UEFI itself, from an EFI shell, etc. :D One maybe stupid question comes to mind: how much additional value has ZBM over a live ISO with ZFS? I suppose booting from a snapshot is certainly one thing that you cannot directly achieve with an ISO? (Well, you could of course rollback the snapshot and then boot, but that's more time consuming and less flexible.)
— Kerberizer • T/C 10:54, 5 October 2021 (UTC)

Kerberizer first thing is you don't need to have a separete boot medium. I guess for the ISO you have to use a CD or USB Stick. Also last time I had problems, I had to download the Arch ISO, set up network and build the ZFS modules in the live system until I could import my pool. With e pre-build ISO this might not be so hard. However, the ZFS boot menu is always there (similar to grub) and despite a complete shell with zfs/zpool commands it has a nice overview of snapshots. You could also have multiple boot environments on different zfs filesystems on the same pool. So you could boot either arch or debian or whatever. I don't think it is an alternative to a rescue ISO but an alternative to grub. If your system is EFI capable (which it should be) you can just try it out by dropping the EFI file to any FAT32 formatted partition and select it in the boot-efi-file menu or launch it via efi shell. And last but not least: In the live ISO you can mount/import your ZFS. In ZFS-Boot menu you can boot it (it uses kexec to boot another kernel from a running linux kernel)
Thomas.oster (talk) 19:43, 5 October 2021 (UTC)

Kerberizer and Thomas.oster FYI I've just added two zfsbootmenu packages to AUR and added instructions to the manual, one package includes the tools to generate a zbm image and the other one installs the prebuilt EFI binaries. Following your discussion I decided to add some logic to the efi binaries package so that it detects the ESP partition and installs the efi binaries there. Gardar (talk) 17:42, 4 August 2022 (UTC)

i wanted to add zfsbootmenu too. i see its inclusion has been stalled for years at this point. would it now be possible to add this? Supernova (talk) 07:12, 15 August 2025 (UTC)

As far as I understand, zfsbootmenu was removed from the article with Special:Diff/845496.

In principle, I agree—all in all, it is "just another boot loader", it is not directly related to the installation-on-ZFS-root process. The project has its own documentation, and we have no Arch-specific additions…

• But I think it is worth to mention it somewhere in ZFS#Tips and tricks.

And an off-topic question:) @ReaperX7 could you explain your comment:

removed this section as it no longer applies and contains direct zfs booting which is no longer recommended

I don't understand the phrase "direct zfs booting which is no longer recommended". Andrei Korshikov (talk) 12:27, 10 February 2026 (UTC)

From testing I did several times, getting ZFS to be readable as a direct bootable filesystem on non-UEFI systems was a bit problematic, especially with the provided Grub package. If you attempted to use a strictly all ZFS disk, with /boot on the same partition it ended up unreadable and Grub simply refused to work. There are patches for Grub, but I didn't have the ability to test them against the latest version, and even documentation from OpenZFS still recommended using a separate /boot for all systems. ReaperX7 (talk) 00:53, 11 February 2026 (UTC)

As far as other ZFS direct booting procedures go, I was unable to get any to work with what I had at the time. ReaperX7 (talk) 01:02, 11 February 2026 (UTC)

For the record, I think ZBM should be mentioned in conjunction with clones. For more information, see ZBM 101: Introduction to ZFSBootMenu.

And checkpoints, of course! They are accessible in ZBM on the Pool tab.

— Andrei Korshikov (talk) 16:05, 21 February 2026 (UTC)

@Supernova has opened an inquiry about this to create a new subsection for zfsbootmenu in Topic 15. If you would like to collaborate on creating this, please do.

I would advise creating this in the bootloader section as a new entry to invole clarification on everything boot related.

If any packages are externally needed, they do need to be in the AUR. ReaperX7 (talk) 16:14, 18 March 2026 (UTC)

When going through these instructions, I used the AUR package instead of the archzfs repo. Which led to the inability to boot into my encrypted root. I found out in the end that this was due to a difference between the AUR package and the archzfs repo package's initcpio hooks. This should be noted.

See the difference in zfs-utils here: AUR vs. archzfs

—This unsigned comment is by Dongcarl (talk) 2022-09-08T01:50:28. Please sign your posts with ~~~~!

Can you specifically say what's different and why it didn't work? I also used the AUR package `zfs-dkms`, and I added a note that you need to add 'zfs' to MODULES. Is that true in general, or just for AUR versions? Za3k (talk) 21:14, 2 August 2023 (UTC)

Right now there are about 3 sets of advice for how to create datasets and mount your root. (Legacy mount, automount, etc). Let's reduce it to just the first one presented, and add the rest as options at the end. The datasets explanations get confusing. Za3k (talk) 21:17, 2 August 2023 (UTC)

To enable less downtime in case of a disk failure, a RAIDZ configuration might be desirable for the root and other FSes needed for operation. Perhaps the example should include a raidz ocnfiguration? Wild Penguin (talk) 19:35, 9 November 2023 (UTC)

- I was able to boot but the system was readonly, but the system still managed to boot. I believe this may be still the same problem as the section 9.1.. The section is not clear on whether one should remove spl.spl_hostid, if it was set?

- Also, it seems like zgenhostid $(hostid) generates only one digit. I believe this might not be correct? Wild Penguin (talk) 20:35, 9 November 2023 (UTC)

My first problem was really stupid - I forgot to add rw to Kernel parameters :--DD. I will add a small friendly notice later to the article just for user friendliness.

As for the hostid file, I misinterpreted. It contains a binary number of the hostid. So it is not user readable by cat. Sorry for the noise! Wild Penguin (talk) 14:39, 10 November 2023 (UTC)

I believe a few clarifications could be useful. First, when creating the pool, why so many -O zfsprops are given, why defaults are not desireable and if/when would a user wish to change these? Looking at zfsprops man page, it is not at all clear. From later on, it seems there is a good reason to set posixacl (along with xattr=sa), but what about relatime, dnodesize, normalization=formD? Optimally, a link to some reference would be welcome instead of explaining in the page. Wild Penguin (talk) 21:58, 7 December 2023 (UTC)

Another thing causing confusion for a newbie to zfs is, why do we need so many datasets? On a "regular" filesystem, one would usually not create partitions or separate mounts. What are the downsides of skipping their creation? Optimally, a link to some reference would be welcome instead of explaining in the page. Wild Penguin (talk) 21:58, 7 December 2023 (UTC)

https://github.com/archlinuxcn/repo/issues/4168#issuecomment-2616651912 darkbasic (http://www.linuxsystems.it/) (talk) 19:52, 27 January 2025 (UTC)

Too much out-of-package stuff has been added and excluded which has made proper usage of zfs-root impossible. This revert removed self-promoted projects and non-sensible additions that were unnecessary to the general user at large.

sd-zfs is not needed and zfs-utils already has systemd relevant parts to make the package work properly.

Proper diagrams of setup, creation of datasets, mounting, dismounting, and zpool information were removed without need. This hurts the beginner user who is looking for accurate information, not misleading information leaving them circling the wiki several times to find an answer to a problem, which is how to setup zfs on root for ArchLinux. Even the section to properly set up the zpool.cache was gone in favor of some personal project which was needless.

If necessary, I will maintain this page as needed since it's been half a year since anyone bothered to do anything with it, but it will be maintained in a way that is sensible and sane, as well as minimal to additional packages, which shouldn't be required to do one simple task.... create a ZFS root to install ArchLinux on the right and proper way. ReaperX7 (talk) 17:37, 25 August 2025 (UTC)

currently there are multiple different boot loader methods but without explanation. would it make sense to add them e.g. zfsbootmenu offering full system encryption (even /boot/), booting into separate systems per datasets, easy snapshot management outside of the system, etc. Supernova (talk) 18:02, 25 August 2025 (UTC)

I have a plan to simplify this to use Grub, rEFInd, and systemd-boot only while maintaining zfs encryption from the boot phase, which is supported by Grub from a separate boot partition. REFInd and systemd-boot should support it as well. ReaperX7 (talk) 02:17, 26 August 2025 (UTC)

If anyone notices any information missing, please feel free to add any and all references, links, etc. as needed. Current information should be futureproof unless anything specifically within zfs-utils and zfs-dkms changes. Thanks everyone for helping. ReaperX7 (talk) 06:20, 14 March 2026 (UTC)

I think there should be a section about different kinds of ways to setup zfs on arch with there features for example ZFSBootMenu making a fully encrypted root including /boot possible with secureboot that acts as a completely separate system making archlinux recovery always possible even remotely with SSH. Supernova (talk) 06:32, 14 March 2026 (UTC)

We could look into this. Having an encrypted /boot would be nice, the problem I notice off the bat is FAT32/VFAT has to always be readable by the BIOS (system firmware) to even initiate boot procedures. This might work better for non-UEFI systems using a separate Ext2/3/4 /boot, in my opinion. How exactly does zfsbootmenu relay to the system that the boot partition and bootloader is readable especially for FAT32/VFAT which has almost zero encryption tools and capabilities? ReaperX7 (talk) 13:16, 14 March 2026 (UTC)

i meant the /boot of archlinux itself with vmlinuz-linux, initramfs and ucode will be encrypted. /efi (which can be on an USB too btw) with the actual efi file for zfsbootmenu does need to unencrypted but that does not matter with secureboot. Supernova (talk) 14:16, 14 March 2026 (UTC)

zfsbootmenu.efi needs to be set in the UEFI as a bootable system, for that efibootmgr can be used or the .efi file can be renamed to bootx64.efi which will force most UEFI's to always boot from it first. Supernova (talk) 14:21, 14 March 2026 (UTC)

Not to sound pessimistic, but that seems like a lot of work to do for encrypting /boot. As it is also, the UEFI directory for ArchLinux, by default is at /boot itself, not /efi or /boot/efi. I would prefer not to deviate from the main wiki if it can be helped. ReaperX7 (talk) 09:04, 16 March 2026 (UTC)

it is more effort however i think its well worth all of the features.

- full encrypted boot

- easy secureboot

- easy booting from an USB or any other storage

- full system rollback always possible even if everything with arch itself including bootloader breaks

- booting into other boot environments like other distros and snapshots

- all of that works remotely over SSH Supernova (talk) 16:46, 16 March 2026 (UTC)

i also don't think it is that much more effort compared to zfs itself Supernova (talk) 16:50, 16 March 2026 (UTC)

If you wish to create a separate section for it, please do. ReaperX7 (talk) 01:13, 18 March 2026 (UTC)

Should ArchLinux be given a GeoBlock by the site admins for California and other regions where these draconian laws regarding age verification go into play, I will no longer, except by VPN, which I lack currently, be able to effectively maintain the section of the Wiki and make contributions to this and the ZFS page. We have seen this with archlinux32.org so it may eventually come to the core distribution as well, placing the maintenance of this section of the wiki in a state of unknown. I would prefer for this not to happen as we have done a lot of work to restore this page back to sanity from the previous maintainer who derailed the page heavily.

I leiu of this, should anything happen, I would like to have someone at the ready to maintain the wiki, and would humbly ask for a co-maintainer to be willing to step up if they aren't from a region affected by these laws. If anyone is willing please make it known for the admins to acknowledge. ReaperX7 (talk) 01:20, 18 March 2026 (UTC)

If no one else steps up i would be willing to become co-maintainer although i may lack the experience so having someone else or at least someone additionally would be a good idea. Supernova (talk) 16:47, 18 March 2026 (UTC)

The goal is to keep the wikipage as close to the OpenZFS specifications as possible, by not using out-of-scope packages as like was used prior to the reversion and cleanup.

As of current, I still can access the site in whole, so I would like to wait for other responses before making a final decision.

I would suggest brushing up on the wiki-isms and committing to a practice of what the wiki page offers in a virtual environment for testing. You need to be able to produce a working install first and foremost. Remember, simplicity is the goal, flexibility is the gold standard, and results as key. ReaperX7 (talk) 23:20, 23 March 2026 (UTC)

a lot of time i see ZFS on Arch being mentioned its about complaints with difficulties and breakage because DKMS does not keep track of what kernel is compatible with zfs. Using ArchZFS's archzfs-linux / archzfs-linux-lts avoids this by only allowing updates when the kernel is supported by zfs. Is there a reason why in 4. it says "For simplicity, and better compatibility, this guide only recommends using the zfs-dkms^AUR package for usage with linux-lts." ? Supernova (talk) 17:02, 18 March 2026 (UTC)

The dkms package is used because it meshes easier with the default kernels provided by ArchLinux rather than leaning on the zfs embedded kernels from archzfs or the pre-build modules. You can use either the archzfs or the AUR provided packages with the dkms packages if you so choose to. We recommend the AUR as the primary source for the package source. The archzfs dkms package is used primarily for the creation of the iso and first installation. You can elect to switch to the AUR provided packages or the dkms package from archzfs as either will work.

The reason why we suggest linux-lts is because the long term support kernel may not experience breakages the same as linux and linux-zen. I have experienced this personally, and recommend the linux-lts package due to it's stability. Linux-rt and other kernels have never been recommended. This makes updating the kernel a lot less problematic for end-users. By pairing linux-lts with the dkms package, the pairing provides a kernel that can be updated independent of the module, and a module that can be updated independent of the kernel.

The goal of the wiki is provide the most simple solution without complexity. Unfortunately, zfs still has an air of complexity surrounding it to a degree. ReaperX7 (talk) 23:11, 23 March 2026 (UTC)

we should not discourage the use of DKMS. The current wiki recommendation to use dkms and linux-lts is right on point on what average user should be doing. It's also what is recommended by zfsonlinux. ek9 (talk) 04:58, 7 April 2026 (UTC)

i don't see zfsonlinux/openzfs recommend DKMS explicitly

https://openzfs.github.io/openzfs-docs/Developer%20Resources/Custom%20Packages.html

They have a getting started guide for archlinux that uses non DKMS packages for provided by archzfs

https://openzfs.github.io/openzfs-docs/Getting%20Started/Arch%20Linux/Root%20on%20ZFS.html#system-configuration Supernova (talk) 06:29, 7 April 2026 (UTC)

My 2 cents (everything is IMO). I do believe, that for any controversy we should document all and every options, exactly because ArchWiki is a documentation (the documentation?;), so different people with different mindsets will find their solution and be happy. I.e. the documentation should not be narrowed because of our personal preferences.

The current wiki recommendation to use dkms and linux-lts is right on point on what average user should be doing.

I'm not sure on this—ZFS-on-root is not for average minds at all:D

a lot of time i see ZFS on Arch being mentioned its about complaints with difficulties and breakage because DKMS does not keep track of what kernel is compatible with zfs.

That is exactly why it should be well-documented (IMO).

As for me personally, I used DKMS for a long time (5+ years), now I'm on ArchZFS again, aaaand… I think both options are totally viable—i.e. they both must be documented.

— Andrei Korshikov (talk) 17:52, 13 April 2026 (UTC)

I agree Andrei. From my experience with ZFS and Linux in a union, it is a rather advanced topic, but from my experience the breakages due to using dkms rather than the embedded zfs kernel have been varied. The LTS kernel, from experience seems to be the best course of action to use, which is why from experience, I have it under the recommended flag. I know firsthand the dangers of using the mainline kernel with zfs and have had breakages on various occasions to know it's not always optimal nor recommended.

The dkms usage implies that the user has better control over the kernel and isn't statically limited to just the embedded zfs kernel, which could have some issues, or even be problematic due to the CDDL and GPL licensing issues betwixt and between both. With dkms, the kernel is still just the kernel, and the module is still separate entirely.

My methodology is aimed primarily at mutual license agreements to avoid a cross-violation. ReaperX7 (talk) 00:23, 18 April 2026 (UTC)

So after spending a few days figuring out different ways how to get systemd initramfs work with zfs encrypted root (I've even tried using various different packages like sd-zfs etc.) I only now realised that zfs-utils package has very good dracut hook which works out of the box. For anyone wanting to use systemd initramfs on encrypted root - just use dracut to generate initramfs.

I think this should be somehow better noted in the wiki. So far I've updated the warning that incorrectly stated that zfs-utils does NOT support systemd booting. It does support it, just not via mkinicpio, but with dracut.

The only thing I had to do is I removed /boot/initramfs-linux-lts.img and used `dracut --add-confdir no-network /boot/initramfs-linux-lts.img --force` to regenerate it. Dracut does not need any configuration it will pickup and use systemd and zfs by default. The wiki page on Dracut explains it sufficiently.

I'm also using ZFSBootmenu to boot. ek9 (talk) 04:56, 7 April 2026 (UTC)

Thank you for this post. I'm not as brave as you:)—I'm still using non-systemd mkinitcpio. Could you tell about troubles with ZFS systemd hooks on mkinitcpio? I have nothing against Dracut, just want to understand what is wrong with mkinitcpio stuff, and maybe make some issues/PRs/MRs for developers. — Andrei Korshikov (talk) 17:27, 13 April 2026 (UTC)

the issue is that mkinitcpio hook does not support native zfs encryption when using systemd initrd (you have to use busybox). It was never an issue but since archlinux seems to have moving to using systemd initrd by default instead of busybox, the only way for now is to use dracut. ek9 (talk) 23:12, 17 April 2026 (UTC)

and just to clarify - dracut zfs hook support is great as it's used by other distributions, while mkinitcpio is archlinux specific ek9 (talk) 23:13, 17 April 2026 (UTC)

If you have time, please draft a dracut how-to section. ReaperX7 (talk) 05:40, 8 June 2026 (UTC)

Should the guide skip using cachefile? It's an old way to boot and is not necessary anymore. ek9 (talk) 05:00, 7 April 2026 (UTC)

+1 for this. — Andrei Korshikov (talk) 17:10, 13 April 2026 (UTC)

It will be looked into when I can test it, but the cachefile is still recommended for consistency with re-mounting the zpools with 100% success, especially for zfs-as-root systems. For storage only file systems it can be more useful and probably better due to zfs being more easily managed as a storage only system, but for system partitions, if the zed doesn't update the pool cache files properly it can cause issues at boot, and the status of the bug is listed as solved but the problem then lies with systemd, and if the system crashes the zpool zfs-list.cache is not updated:

https://zfsonlinux.topicbox.com/groups/zfs-discuss/T74605c31a8a6fef0

While for some systems, removing the cache file is probably recommended, such as zfs storage only pools, for a root parition, this might be ill advised. The zpool.cache is still accessible by a recovery system to import the pool, and is needed at boot time.

I would advise more documentation on the pros and cons of zpool.cache vs zfs-zed zfs-list.cache be created for the wiki per use case. Blindly advising users to use one system over the other should be avoided to allow for better understand for the user to know what they're getting themselves into.

If you wish to create a zfs-zed section, please do, but make sure all advisories are in place so the user can make the best informed decision. ReaperX7 (talk) 00:47, 18 April 2026 (UTC)

After some reviewing, zfs-zed seems best used only for hotswap devices where you are hotplugging drives in and out of the system, not as a normal desktop system. This portion should be clarified on the standard ZFS page as that page is better suited for zfs-zed and not the zfs-as-root section. ReaperX7 (talk) 05:43, 8 June 2026 (UTC)

referencing: https://wiki.archlinux.org/title/Talk:ZFS#Revertion I'm coming back after finally testing and solidifying my previous installation steps.

I have an installation using zfsbootmenu, busybox, and the zed event daemon, and everything is stable. I used `linux-lts`, and `zfs-dkms` for the setup. The pool's root dataset is not encrypted, but all the datasets are using native zfs encryption.

I use no external project besides `zfsbootmenu` (I'm not sure if you consider this immediately out-of-scope, read on for a bit more detail), just raw, official-repo Arch linux-lts kernel, and the aur packages for `zfs-utils` and `zfs-dkms`. I don't use the ArchZFS repo.

I use rEFInd (from the official repos) to point to zfsbootmenu which takes care of caching the encryption key. I haven't tested, but now after my journey, I am confident I could get it to work _without_ `zfsbootmenu` if I didn't have encryption enabled (would still rely on busybox). Heck, I could probably get it to work with encryption if I didn't mind typing the encryption key in multiple times. And, as user ek9 mentioned about dracut, I am fairly confident I could get dracut to work without encryption, using the event daemon. I'm not as confident about the `sd-zfs` path, but without encryption I believe it _could_ be possible.

I haven't written up my process in clean notes yet, but I'll post here once I do get them cleaned up.

Before I go through the effort of cleaning my notes up for public release vs my own internal consumption, would they even be helpful? Would it enable a section about `zfs-import-scan` and the `zed` to be added to the main zfs page, and/or this root-on-ZFS page? I'm not sure what your boundaries/definitions are on "external projects". Besides zfsbootmenu (which as I explained I could probably get by without), my current setup is strictly official repos plus the two primary aur packages, zfs-utils and zfs-dkms, and paired with some good-ol' system admin-ing.--Feinedsquirrel (talk) 01:27, 11 June 2026 (UTC)

zfsbootmenu is suitable for this page, but zed is best suited for the ZFS page. ReaperX7 (talk) 05:27, 11 June 2026 (UTC)

While technically, ArchLinux does use systemd as init by default, I have seen OpenRC packages in the AUR and want to ask if we should consider adding information relevant to using OpenRC, seemingly the primary alternative init system in the AUR, which would mainly consist of zfs-openrc package references mainly and a small expansion of the service init setup guide to show commands relevant to adding zfs-mount and zfs-import for the boot runlevel, and zfs-load-key for the encrypted option.

Thoughts? Concerns? Debates? ReaperX7 (talk) 05:51, 8 June 2026 (UTC)

I have gone ahead and cleaned up the hostid section to segregate it from the init setup portion of the wiki. The hostid section is now on it's own properly.

The init section is now incorporating both systemd (the default init system) and OpenRC (from the AUR and wiki page) for completionary purposes and proper documentation since the wiki has an entry for OpenRC.

Other init systems like sysvinit, s6, Runit, and dinit are not included due to permeation of these systems is far lower than OpenRC. I will expand the init section if needed to incorporate these if requested. ReaperX7 (talk) 00:32, 12 June 2026 (UTC)

The clean-up of the How-To Guide is more or less complete as far as basic information to set up and install ArchLinux to ZFS. Some noteable mentions:

1. The initramfs hooks were changed in the core system to use systemd rather than busybox (udev) which resulted in failure to boot during recent testing. The problem as found and mitigated, information added and a warning attached.
2. OpenRC information added for completionism purposes only. While other init systems exist, of the alternatives OpenRC is the most mature.
3. zfsbootmenu is incomplete. Unfortunately, this may not be finished, unless someone wishes to add this information stub entry. While this would be more useful for older msdos MBR style partitions, newer more flexible bootloaders like Grub exist, especially for UEFI systems.
4. hostid section and init setup were finally segregated into their own sections respectively to avoid confusion.
5. California laws seem to not be affecting Arch, so I can remain the sole maintainer of the page for the time being. Other help would be appreciated.

Thank you to everyone who has helped in getting this page fixed up and restored to fully working order. ReaperX7 (talk) 07:17, 15 June 2026 (UTC)

Repository merge:

This section was flagged for possible merging, but to be fair, we don't know if and when archzfs will change their repository and seemingly this URL to their github page seems to be the current channel. I have no issues merging that section back in with a redirect to the unofficial repository page.

sd-zfs to enable usage of systemd in initramfs:

This is not feasible because it relies on an external AUR only package that doesn't exist in archzfs's repository. This package also prevents the usage of encryption. Because ZFS allows for encrypted root for secure systems, this is not acceptable and will not be added to the wiki page. Unless zfs-utils enables native systemd initramfs compatibility internally and allows for encrypted file system support in ZFS, this page will continue to use busybox in the initramfs for the foreseeable future.

Dracut secrion for initramfs:

I am open to someone familiar with dracut to work on this section. Zfs-utils already has support for dracut as it is.

Zfsbootmenu:

This one is tough to call because zfsbootmenu requires usage of external bootloader images to be downloaded rather than native integrated through a package manager, which could be a security risk. With the AUR in the state it's in, I'm hard pressed to really support usage of this, so for now this section will remain dropped unless someone can properly vet and test zfsbootmenu every 6 months to ensure proper reliability of the system.

6 month cycle testing of the wiki page:

Starting as of yesterday, I'm devoting more time to attempt to test the wiki page for build consistency every 6 months. If anyone wishes to do the same and compare results, please do so. ReaperX7 (talk) 10:43, 16 June 2026 (UTC)

Retrieved from "https://wiki.archlinux.org/index.php?title=Talk:Install_Arch_Linux_on_ZFS&oldid=879481"