0

I have a Ubuntu 19.10 install that was originally setup with EXT4 but I migrated to root on ZFS, loosely following the instructions at https://github.com/zfsonlinux/zfs/wiki/Ubuntu-18.04-Root-on-ZFS.

I had numerous issues with the install that I didn't have with PopOS or Arch when I set them up with ZFS (such as not being able to have /var being a mounted dataset).

My only remaining issue is that I have a second hard drive, also ZFS, that I'm trying to have the system automatically import at boot. Both the system and this secondary hard drive are using LUKS. I correctly have cryptsetup setup so that the secondary hard drive is decrypted at the same time that I type the password for the root system.

The pool was not being imported by the cache file (despite this being set to run after cryptsetup), which is apparently another bug that I saw referenced on AskUbuntu. I then setup a systemd service to import the pool specifically, in the same way that the instructions above recommend creating a service for importing the boot pool.

The problem is that I cannot get the service to run at the correct time and so importing the pool always fails with ZFS saying the pool does not exist. It seems that I cannot get systemd to run the service at the correct time. With the file below I noticed that the service definitely is being run after cryptsetup is complete, so I don't know why ZFS cannot find the pool. The weird thing is that it appears to be the first service that's being run after cryptsetup is finished. I did notice at some point some systemd logs specifying that the cryptsetup dependency was tossed due to a dependency loop but I haven't seen that error now in a while and am not sure what could be causing that.

So the question is - how do I make this work? Is there something obvious with systemd that I'm missing?

Here is the service file that I am using.

[Unit]
DefaultDependencies=no
Requires=zfs-load-module.service
After=systemd-udev-settle.service
After=zfs-load-module.service
After=cryptsetup.target
Before=zfs-import-scan.service
Before=zfs-import-cache.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=/bin/sleep 3
ExecStart=/sbin/zpool import -N zfsmedia

[Install]
WantedBy=zfs-import.target

Without the ExecStartPre, it never works. The system boots without mounting the pool. With the ExecStartPre, it works about 50/50. I haven't tried a bigger delay. I also tried adding After=fs-remount-rw.service to no effect. If I remove the Before= lines then the system bizzarely drops into a rescue shell with half of the system datasets not mounted (I also had that symptom numerous times while trying to get the root on ZFS).

After the failure to import at boot, I can then enter "zpool import zfsmedia" after boot and it works fine. It seems like it's just the timing of the systemd unit that is wrong and I can't figure out how to get it right, or what to do if the problem is systemd not honoring dependencies.

0

TL;DR - working systemd service below!

Thank you for posting as I had the exact same problem, also running ZFS root on Ubuntu 19.10.

I THINK what is happening is when booting ZFS root, an initrd specific zfs script runs which differs from the standard zfs-import scripts in /etc/init.d and ignores some of the standard config from /etc/default/zfs. I didn't find this exact file elsewhere on the main system. Though, I also was getting frustrated and stopped digging further.

Since I'd seen your post, I decided to look at systemd to mount the zpool, but I used an Ubuntu provided zfs systemd service as a starting point.

I inspected the zfs-import-cache service... which obviously wasn't working for me, but figured it would provide hints about relative dependencies. Then I used that to create my own service.

systemctl cat zfs-import-cache > /etc/systemd/system/zfs-import-datastore.service
# edit as needed (see below)
systemctl daemon-reload
systemctl enable zfs-import-datastore

The resulting service:

# /etc/systemd/system/zfs-import-datastore.service
[Unit]
Description=Import ZFS pool - datastore
Documentation=man:zpool(8)
DefaultDependencies=no
Requires=systemd-udev-settle.service
Requires=zfs-load-module.service
After=systemd-udev-settle.service
After=zfs-load-module.service
After=cryptsetup.target
After=systemd-remount-fs.service
After=zfs-import-cache.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/zpool import datastore

[Install]
WantedBy=zfs-import.target

With this service my Ubuntu 19.10 system boots cleanly and automatically imports the datastore zpool in addition to bpool and rpool.

| improve this answer | |
  • Ah, I really wanted this to be right. Unfortunately, it doesn't work for me. I copied/pasted what you had (with the correct pool name) and the zpool is still not imported automatically after boot. Adding a 5-second sleep in ExecStartPre with the same file does import the pool. Glad you found a solution that solves your issue though! Also should note that I'm using a custom after-the-fact ZFS install not one created with the 19.10 ZFS installer, if that makes a difference. – raybob95 Feb 15 at 20:05
  • I also used the github.com/zfsonlinux/zfs/wiki/Ubuntu-18.04-Root-on-ZFS instructions but tweaked to taste for installation via 19.10 live-server ISO, not the desktop ISO's experimental zfs-root installer. To be clear, my solution works, given you add a "ExecStartPre=/bin/sleep 5" and change the name of the pool? Is it more reliable than what you had before? I did notice the stock /etc/default/zfs has a variable, ZFS_INITRD_POST_MODPROBE_SLEEP, which defaults to 0... so it seems there are cases where the disks simply take longer to be available. – bsherman Feb 17 at 1:49
  • It works consistently with the sleep, both in my original script and with yours. I don't remember where I saw this, but at some point I saw something mentioning an issue with a dependency cycle in systemd. In fact if I watched systemd do its thing while booting it looked like my zfs mount was one of the first things to run, no matter what targets I added as dependencies. Seems like there's an issue and it's just ignoring the ordering. No idea what's causing that, though. – raybob95 Feb 29 at 17:27
  • It's a shame I have to use this hack but at this point it would take me longer to fix than the extra 5 seconds I have to wait for the computer to boot. Hopefully this becomes a non-issue as ZFS is better supported by Ubuntu in the future. – raybob95 Feb 29 at 17:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.