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.