3

I'm using zfs on a generic Ubuntu 18.04 system. Everything works fine when creating and mounting file systems using normal mountpoints.

However, I have a use case that would be helped if I could use legacy mounts that auto mount at boot time.

If I set my legacy mount as noauto and then manually mount after startup, everything works fine.

But when I remove noauto, I fail to automatically mount at boot. It's obvious what the problem is - during startup the attempt to mount the drive is taking place before the ZFS modules are loaded:

$ systemctl status home-vagrant.mount
● home-vagrant.mount - /home/vagrant
   Loaded: loaded (/etc/fstab; generated)
   Active: failed (Result: exit-code) since Thu 2020-04-30 11:41:07 PDT; 24s ago
    Where: /home/vagrant
     What: vagrant
     Docs: man:fstab(5)
           man:systemd-fstab-generator(8)
  Process: 464 ExecMount=/bin/mount vagrant /home/vagrant -t zfs (code=exited, status=2)

Apr 30 11:41:07 ubuntu mount[464]: The ZFS modules are not loaded.
Apr 30 11:41:07 ubuntu mount[464]: Try running '/sbin/modprobe zfs' as root to load them.
Apr 30 11:41:07 ubuntu systemd[1]: home-vagrant.mount: Mount process exited, code=exited status=2
Apr 30 11:41:07 ubuntu systemd[1]: home-vagrant.mount: Failed with result 'exit-code'.
Apr 30 11:41:07 ubuntu systemd[1]: Failed to mount /home/vagrant.

Of course, later in the boot process the ZFS modules are loaded and it can be mounted properly. I can see the two events in the boot printout, it's pretty obvious what the problem is - but not the fix.

I haven't been able to find a simple how-to for dealing with this. From what I can see, it seems like installing zfs-initramfs is supposed to help with this - but how?

What little information is floating around out there seems to primarily deal with using zfs for the root file system, and in many cases that is a lot more complicated.

Part of the use case might clear up why I want legacy mounts - I have bind mounts that are being mounted in the ZFS file system. So a workaround would be to use links instead of mounts - and if I can't solve this problem that's what I'll do.

But it seems like this should be doable!

EDIT: There are three different ways that I can see the zfs module insertion in my boot: modules_load=zfs in my kernel boot command line, or adding the zfs line to /etc/modules-load.d/modules.conf, or creating /etc/modules-load.d/zfs.conf with that line.

When these are present, I see the line 'Inserted module zfs', but it comes after the failed attempt to mount the drive.

Without any of those three lines, I don't see the 'Inserted module zfs' line, but I do see the companion line 'ZFS: loaded module' that comes after the module is installed.

Anyway, it appears that all of these attempts to force an early module load are not effective.

EDIT2: If I add zfs to /etc/initramfs-tools/module, then update-initramfs -c -k all then update-grub, I see a change in behavior.

It now looks like the ZFS module does get loaded ahead of the systemd module loader service modules, and ahead of the mount command.

The mount still fails with an unable to open the dataset message.

Seems likely that this is because, although the module is loaded, the other ZFS services are not started yet. Even though I get a 'kernel: ZFSL Loaded module' early on, it isn't until much later (after the mount failure) that I see 'systemd[1]: Starting Install ZFS Kernel module'. I think the module has already started, so that's a meaningless output, but that's when the various zfs services start.

I don't see how those services can start any earlier in the boot process, but there are systems that boot off a zfs root drive, so there is some way to do it...

SOLUTION?:

The suggestion from @Gordan Bobic to use _netdev in my fstab entry worked - that's maybe not the most elegant solution, using the wrong tool for the job, but it does delay mounting long enough to avoid the problem.

I went with that idea and tried using noauto,x-systemd.automount which I am guessing might be a little more reliable for my use case. Need some more testing but it seems like it is going to work.

1
  • zsh-initramfs sounds like something relating to zsh (z-shell), which is in no way related to zfs. May 1, 2020 at 11:11

2 Answers 2

1

Not sure if this is the right solution, but this worked for me.

systemctl edit home-vagrant.mount

[Unit]
Requires=zfs-import.target
After=zfs-import.target

EDIT: One of the following ways might work too.

<pool/dataset> /var/log zfs x-systemd.after=var.mount
<pool/data> /home zfs x-systemd.before=zfs-mount.service

source

0

Try adding zfs in /etc/modules-load.d, or on the kernel boot command line using modules_load and rd.modules-load.

Failing that, add _netdev to your fstab options. That will defer the mounting until the network stack is initialized, which will give extra time for the zfs pool import service to load.

9
  • The first suggestion is something i already tried. I added a line with "zfs" in /etc/modules-load.d/modules.conf - no help. I also created a file called zfs.conf and added it there. Again, no help. It's hard to tell when these modules are loaded or if adding these lines make a difference. I believe the the kernel boot command line is one that might work, but I'm a little shaky on how to make it work. Will follow your link to see if there is something there.
    – Mark
    May 1, 2020 at 12:37
  • If I edit my boot line and include 'module_load.zfs', I don't see any change. Maybe the problem isn't when the module loads, but rather when the services start?
    – Mark
    May 1, 2020 at 12:43
  • It's modules_load=zfs, rather than modules_load.zfs. May 1, 2020 at 13:32
  • Yeah the typo was in the comment, not the execution. I updated the question with the results on this - forcing the module install creates an observable change, but the installation of the module is not early enough.
    – Mark
    May 1, 2020 at 14:17
  • 1
    So an interesting side effect of all this - the whole reason for this problem is that I have bind mounts defined in fstab that have mount points in my zfs file system. (I would have rethought this if I had known how much trouble it was going to cause.) Anyway, changing the fstab entry to have the x-systemd.autmount option results in the zfs file system being mounted after boot is complete. So far so good. But for some reason, the bind mounts that have the same x-systemd.automount option don't automount! I might just revert all of them to _netdev and settle for a slightly less satisfying fix.
    – Mark
    May 1, 2020 at 16:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .