Intended method to automatically mount root on ZFS


related to my other post ([ZFS] Manjaro not booting, because it fails to automount ZFS dataset) I’m struggling to understand, which is the preferred to automatically mount ZFS datasets and pool, which are used to Linux root and boot.

There are two methods described in the Arch Wiki:

  • Using zfs-mount.service
  • Using zfs-mount-generator

And I’m using the method described in the OpenZFS Wiki, which uses fstab.

So far, mounting the root filesystem works with my configuration, but what is the intended, correct and most recent way to do it?


There is no “correct” way. Just different options to choose from.

If you want to use /etc/fstab to mount ZFS datasets, make sure you set the mountpoint for the datasets to legacy

1 Like

Then let’s not say “correct”, but “most recent”, “intended by the developers of Manjaro/Arch/OpenZFS” or “rational”.

E.g. I’m not using datasets with the property mountpoint=legacy and the “official” OpenZFS Wiki also does not describe it like you said.

As far as I understand, my current configuration generates systemd mount units out of the fstab definition. But that’s exactly what I want to understand. :slight_smile:

There are literally multiple ways to do it. All are rational. zfs in general isn’t a thing that only works a single way. It is intended to be flexible and used in different ways. Different people have different preferences.

That being said, the method described the arch wiki using the zfs-mount.service is definitely more common and more simple.

I just looked at the wiki you referenced. It looks like it is setting canmount=noauto on all datasets with mountpoints then mounting them manually by zfs using the zfsutils mount option in /etc/fstab. That is yet another valid way to do it.

For the dataset that isn’t working for you, did you set canmount=noauto and set the mountpoint properly

I don’t really think that is the “official method”. I think that the author’s preference. If a descriptive howto like that described all the options, it would be very long and confusing.

That is how fstab works on a system with systemd. It does that for everything in /etc/fstab with any filesystem.

1 Like

Thank you for you answer and the information.

I understand that, there is now “wrong” or “right”. But there has to be reasons to choose one or another solution. That is, what I’m trying to understand. E.g. my configuration, from the OpenZFS Wiki “Root on ZFS” for Arch, is using the fstab method, to control the order folders are mounted more precisely:

At boot, datasets on rpool are mounted with /etc/fstab , which can control the mounting process more precisely than zfs-mount.service .

So what are the pros and cons using other method?

As far as I understand it, it is using the canmount=noauto property only for the root dataset ‘rpool/manjaro/ROOT/default’. I’m not using a boot pool, that did not work out for me. :slight_smile:

So for me the scheme is:

  1. Every virtual dataset gets the canmount=off property set, because it just used for organisation and inheriting properties to child datasets.
  2. The datasets for /usr, /var and /var/lib are set to ‘canmount=off’. This is mentioned in nearly any howto I found, even though I don’t know the actual reason.
  3. All other datasets, which are actually mounted have the `canmount=on’ property set.

The dataset, which is not working for me, is discussed in another thread
(Manjaro not booting, because it fails to automount ZFS dataset) as I wanted to split this topics. But its canmount property is set to on.

Thx again, that is something that I did not know. :smiley:

This is only useful/important if you need to control the order they are mounted more precisely.

One pro is that it is easier to manage. You just set the mountpoints and they instantly mount themselves. Especially as the number of datasets grows.

When you do that, they basically become containers for the datasets they hold. There is no reason to mount them or set their mountpoints. That being said, your layout, is very odd. From a peek at your fstab it looks like you are explicitly mounting nested datasets. What is the point of that? Most people would either allow them all to be implicitly mounted or don’t create those extra containers in the first place. Is that just how you keep them organized?

If you are mounting them in /etc/fstab, I don’t think you want canmount=on. That doesn’t seem to be what they recommend in the tutorial you followed either.

One important warning I would give you is that everyone does this kind of setup differently so if you are mixing and matching information from different tutorials, it is important that you have a detailed understanding of what you are doing or you will end up in a mess.

1 Like

Ok, then why do they need to do this more precisely in the howto?

I just followed the wiki to get to a starting point and to learn something. I just don’t have a mirrored pool and I’m not using a separate boot pool, but anything else I have done, is as described the OpenZFS wiki.

As I said, I just followed the howto, which is also by the way, the most recent one. I still could have done something wrong, though.

I also understand this, but at some point you’ll have to try something to get a better understanding. I’m at this point now.

There isn’t enough information there to determine if it is needed or not. To be fair, I don’t usually use a boot pool so it could be needed there.

Alternatively, it may just be the author’s preference.

I do something similar but in my case it is because I multi-boot out of a single zpool and I have overlapping mountpoints. This is probably not a common use case though.

Maybe I am not reading that link closely enough but where it does it recommend creating a dataset called something like rpool_<randomUUID>/manjaro/DATA/default/var/lib/libvirt with that much nesting? I mean, you can, it will work. But what is the point?

The same thing could be achieved by the dataset rpool_<randomUUID>/manjaro/DATA/libvirt.

To be clear, I am not recommending you change it. I am just trying to understand why you would do it in the first place when you are explicitly mounting everything in /etc/fstab

For example, I have a dataset mounted at /home/dalto/.local/share/Steam. In your model, would you create a dataset called rpool_<randomUUID>/manjaro/DATA/default/home/dalto/.local/share/Steam?

That just seems like a bunch of pointless empty datasets to me. :person_shrugging:

But, ultimately, this is what I was referring to earlier. There are a bunch of different ways to do this stuff. As long as you understand why you do it that way and have a reason for doing so, great!

Damn it, would have been nice to know. :smile: If the entries in /etc/fstab would be removed, would the system still boot?

It is described here, from point 5ff. At point 8 they create the /lib/libvirt dataset:

zfs create -o canmount=on rpool_$INST_UUID/$INST_ID/DATA/default/var/games
zfs create -o canmount=on rpool_$INST_UUID/$INST_ID/DATA/default/var/www
# for GNOME
zfs create -o canmount=on rpool_$INST_UUID/$INST_ID/DATA/default/var/lib/AccountsService
# for Docker
zfs create -o canmount=on rpool_$INST_UUID/$INST_ID/DATA/default/var/lib/docker
# for NFS
zfs create -o canmount=on rpool_$INST_UUID/$INST_ID/DATA/default/var/lib/nfs
# for LXC
zfs create -o canmount=on rpool_$INST_UUID/$INST_ID/DATA/default/var/lib/lxc
# for LibVirt
zfs create -o canmount=on rpool_$INST_UUID/$INST_ID/DATA/default/var/lib/libvirt
##other application
# zfs create -o canmount=on rpool_$INST_UUID/$INST_ID/DATA/default/var/lib/$name

I don’t know the author, either and there is no description regarding this point, but I guess they wanted to stick to the folder structure and that’s it. I thought It would make sense and adopted it. It is not the only howto doing it in this way.

I know what you mean. I took some effort to think about my dataset structure and finally I adopted the structure from the OpenZFS Arch wiki.

Only one way to find out!

Given your layout where everything is under your / dataset and you have canmount=on, I suspect it would work because the initramfs would probably mount them all.

I wonder why they create datasets for /var/games and /var/lib/AccountsService. I don’t know what goes in /var/games, mine is empty.

I a little bit frightened, but I will try it. :rofl:

I’m just not sure about the root dataset. It is set to canmount=noauto. Every data set, under / has a mountpoint set and canmount is on.

How does the system know it has to mount rpool_${poolUUID}/manjaro/ROOT/default if canmount=noauto is set?

All articles I read, are using bootfs=rpool_${poolUUID}/manjaro/ROOT/default, which is 1. deprecated and 2. only available if dnodesize=legacy.

It seems to be a official folder, but I also read it is rarely used. Link

Your bootloader config should be describing how to load the root in the options.

Thx again, found it in the systemd-boot config files.

Also, the system boots without the fstab entries for the zfs datasets.

P.S.: Keep this in mind if using the zfs-mount.service:

Note: This does not work with separated /var dataset because it does not get mounted early enough. Instead you should use zfs-mount-generator option. /var dataset requires legacy mount on systemd based distros. · Issue #3768 · openzfs/zfs · GitHub for more information.

From ZFS - ArchWiki.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.