ZFS 0.8.4 Encrpyted dataset on rootpool introduces systemd ordering cycle #10356
Comments
Arch specifics:
My laptop currently boots arch configured something like this:
Let me preface this with "This feels like a terrible hack". There we go. My /boot is on a LUKS partition, the unencrypted EFI partition holds only grub.efi, the rest is on encrypted ZFS. Don't ask. :) and a manually created aaaand a modified keyload service. The This is probably not everything someone would need to replicate my setup, but it might help you get on the right way. |
Arch specifics:
If you need any further information, feel free to ask, it's really nice to see you respond so quickly 👍 |
Is this just what worked for you or have you determined these to be the minimal necessary modifications? :)
Are you sure it's that unit prompting you and not the mkinitcpio To my understanding, your boot goes something like this: Seems the biggest problem is that the pool is imported, unlocked and partially mounted before systemd was involved, which it finds confusing; e.g. zfs-import.target wasn't hit although the pool is clearly imported, etc. At this point I'm unsure whether a) this is a bug with your setup OR b) a bug between the assumptions of the generator and some setups like the zfs hook OR c) if we can sit back and blame the zfs initcpio hook. c) could be solved by adding instructions to modify -.mount and the keyload .service to the archwiki, but i doubt it's anyone's preferred solution. |
|
I'm not immediately seeing the root cause here and I unfortunately don't have a lot of time to dig into this. However, Ubuntu ran into an ordering cycle too and this patch of mine (which I have not yet submitted) fixes it: Does that patch have any effect on this situation? |
|
@rlaager Your patch doesn't fix the problem for me, although it simplifies it. Now there's only systemd-journald.socket in an ordering cycle (Take a look at the logs, systemd-journal is conflicting with itself :D) |
Those are the changes I need to make to stop systemd from ending up in an ordering cycle.
I just masked both units and it didn't make any difference (I already applied my solution as mentioned in my first post). To be fair, I'm a human and I make mistakes, so it could be a bug with my setup and all the machines I deployed this particular setup on... I tell you if I find anything else that seems a bit odd and I can share my zfs/zpool properties/boot information/whatever you need, just keep asking, as I'd like this issue to be resolved asap as well :) |
rlaager
added a commit
to rlaager/zfs
that referenced
this issue
May 31, 2020
zfs-load-key-DATASET.service was gaining an After=systemd-journald.socket due to its stdout/stderr going to the journal (which is the default). systemd-journald.socket has an After (via RequiresMountsFor=/run/systemd/journal) on -.mount. If the root filesystem is encrypted, -.mount gets an After zfs-load-key-DATASET.service. By setting stdout and stderr to null on the key load services, we avoid this loop. Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes: openzfs#10356
|
@Schebang I submitted that patch as #10388. I've pushed another commit there that I think should fix your loop. Can you test: |
|
@rlaager Sadly I'm still running into dependency issues |
|
Is that with both changes applied? The first commit should eliminate -.mount depending on zfs-import.target. |
|
I managed to resolve this using this dataset property (Im on Seeh the manpage of Not sure what a general solution would look like. |
|
@rlaager I've applied both of your patches and I'm still getting an awful lot of dependency cycles, maybe I didn't set up my rootpool properly? dmesg -H zpool get all rootpool zfs get all rootpool/ROOT |
|
Alright, I've got myself a pretty NVMe SSD and put a new pool on it, this time I followed all the guides again and I didn't run into any problems regarding the zfs-mount-generator. No idea how this is all working out now, but I can't seem to find any issues anymore. I'll attach you the structure of my zpool, after all that's most likely what causes everything to run smoothly now! If there's anything else you need, don't hesitate and just ask me :) |
rlaager
added a commit
to rlaager/zfs
that referenced
this issue
Jul 30, 2020
zfs-load-key-DATASET.service was gaining an After=systemd-journald.socket due to its stdout/stderr going to the journal (which is the default). systemd-journald.socket has an After (via RequiresMountsFor=/run/systemd/journal) on -.mount. If the root filesystem is encrypted, -.mount gets an After zfs-load-key-DATASET.service. By setting stdout and stderr to null on the key load services, we avoid this loop. Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes: openzfs#10356
rlaager
added a commit
to rlaager/zfs
that referenced
this issue
Aug 1, 2020
zfs-load-key-DATASET.service was gaining an After=systemd-journald.socket due to its stdout/stderr going to the journal (which is the default). systemd-journald.socket has an After (via RequiresMountsFor=/run/systemd/journal) on -.mount. If the root filesystem is encrypted, -.mount gets an After zfs-load-key-DATASET.service. By setting stdout and stderr to null on the key load services, we avoid this loop. Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes: openzfs#10356
rlaager
added a commit
to rlaager/zfs
that referenced
this issue
Aug 1, 2020
zfs-load-key-DATASET.service was gaining an After=systemd-journald.socket due to its stdout/stderr going to the journal (which is the default). systemd-journald.socket has an After (via RequiresMountsFor=/run/systemd/journal) on -.mount. If the root filesystem is encrypted, -.mount gets an After zfs-load-key-DATASET.service. By setting stdout and stderr to null on the key load services, we avoid this loop. Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes: openzfs#10356
rlaager
added a commit
to rlaager/zfs
that referenced
this issue
Aug 1, 2020
zfs-load-key-DATASET.service was gaining an After=systemd-journald.socket due to its stdout/stderr going to the journal (which is the default). systemd-journald.socket has an After (via RequiresMountsFor=/run/systemd/journal) on -.mount. If the root filesystem is encrypted, -.mount gets an After zfs-load-key-DATASET.service. By setting stdout and stderr to null on the key load services, we avoid this loop. Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes: openzfs#10356
rlaager
added a commit
to rlaager/zfs
that referenced
this issue
Aug 1, 2020
zfs-load-key-DATASET.service was gaining an After=systemd-journald.socket due to its stdout/stderr going to the journal (which is the default). systemd-journald.socket has an After (via RequiresMountsFor=/run/systemd/journal) on -.mount. If the root filesystem is encrypted, -.mount gets an After zfs-load-key-DATASET.service. By setting stdout and stderr to null on the key load services, we avoid this loop. Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes: openzfs#10356
rlaager
added a commit
to rlaager/zfs
that referenced
this issue
Aug 2, 2020
zfs-load-key-DATASET.service was gaining an After=systemd-journald.socket due to its stdout/stderr going to the journal (which is the default). systemd-journald.socket has an After (via RequiresMountsFor=/run/systemd/journal) on -.mount. If the root filesystem is encrypted, -.mount gets an After zfs-load-key-DATASET.service. By setting stdout and stderr to null on the key load services, we avoid this loop. Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes: openzfs#10356
rlaager
added a commit
to rlaager/zfs
that referenced
this issue
Aug 18, 2020
zfs-load-key-DATASET.service was gaining an After=systemd-journald.socket due to its stdout/stderr going to the journal (which is the default). systemd-journald.socket has an After (via RequiresMountsFor=/run/systemd/journal) on -.mount. If the root filesystem is encrypted, -.mount gets an After zfs-load-key-DATASET.service. By setting stdout and stderr to null on the key load services, we avoid this loop. Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes: openzfs#10356
behlendorf
pushed a commit
that referenced
this issue
Aug 30, 2020
zfs-load-key-DATASET.service was gaining an After=systemd-journald.socket due to its stdout/stderr going to the journal (which is the default). systemd-journald.socket has an After (via RequiresMountsFor=/run/systemd/journal) on -.mount. If the root filesystem is encrypted, -.mount gets an After zfs-load-key-DATASET.service. By setting stdout and stderr to null on the key load services, we avoid this loop. Reviewed-by: Antonio Russo <antonio.e.russo@gmail.com> Reviewed-by: InsanePrawn <insane.prawny@gmail.com> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes #10356 Closes #10388
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this issue
Sep 22, 2020
zfs-load-key-DATASET.service was gaining an After=systemd-journald.socket due to its stdout/stderr going to the journal (which is the default). systemd-journald.socket has an After (via RequiresMountsFor=/run/systemd/journal) on -.mount. If the root filesystem is encrypted, -.mount gets an After zfs-load-key-DATASET.service. By setting stdout and stderr to null on the key load services, we avoid this loop. Reviewed-by: Antonio Russo <antonio.e.russo@gmail.com> Reviewed-by: InsanePrawn <insane.prawny@gmail.com> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#10356 Closes openzfs#10388
jsai20
pushed a commit
to jsai20/zfs
that referenced
this issue
Mar 30, 2021
zfs-load-key-DATASET.service was gaining an After=systemd-journald.socket due to its stdout/stderr going to the journal (which is the default). systemd-journald.socket has an After (via RequiresMountsFor=/run/systemd/journal) on -.mount. If the root filesystem is encrypted, -.mount gets an After zfs-load-key-DATASET.service. By setting stdout and stderr to null on the key load services, we avoid this loop. Reviewed-by: Antonio Russo <antonio.e.russo@gmail.com> Reviewed-by: InsanePrawn <insane.prawny@gmail.com> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#10356 Closes openzfs#10388
sempervictus
pushed a commit
to sempervictus/zfs
that referenced
this issue
May 31, 2021
zfs-load-key-DATASET.service was gaining an After=systemd-journald.socket due to its stdout/stderr going to the journal (which is the default). systemd-journald.socket has an After (via RequiresMountsFor=/run/systemd/journal) on -.mount. If the root filesystem is encrypted, -.mount gets an After zfs-load-key-DATASET.service. By setting stdout and stderr to null on the key load services, we avoid this loop. Reviewed-by: Antonio Russo <antonio.e.russo@gmail.com> Reviewed-by: InsanePrawn <insane.prawny@gmail.com> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#10356 Closes openzfs#10388
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
System information
Describe the problem you're observing
I have recently updated from ZFS 0.8.3 to ZFS 0.8.4.
I am using the zfs-mount-generator and I used the instructions from the arch wiki.
I've got one ZPOOL (rootpool), with 3 datasets, ROOT, ROOT/HOME, ROOT/SWAP.
rootpool/ROOT is encrypted with a passphrase.
After the upgrade, systemd complained about ordering cycles on bootup
Describe how to reproduce the problem
Use systemd-mount-generator with an encryted dataset for the root filesystem.
Include any warning/errors/backtraces from the system logs
With zfs-import-scan.service:
With zfs-import-cache.service:
How to get it fixed (not properly!)
Edit /usr/lib/systemd/system-generators/zfs-mount-generator
Remove the content of after and before on lines 113 and 114
Comment out line 207 (after="${after} ${keyloadunit}")
It removes the (actually rather useful) dependencies to avoid the ordering cycle with systemd-journald.socket.
The text was updated successfully, but these errors were encountered: