-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleanup systemd dependencies #6822
Conversation
Some redundancy is present in the systemd dependencies, as noticed in PR#6764. Existing setups might rely on these quirks, so these cleanups have been moved to the development branch. Signed-off-by: Antonio Russo <[email protected]>
I do use ZFS root and trying to switch to dracut for initramfs. I confirm that this (and PR#6764) boots fine with genkernel generated initramfs. However I can't make it boot with dracut-generated initramfs. I suspect that mount of ZFS root dataset is attempted before the Import ZFS pools by cache file is completed. I'm dropped to an emergency shell, where I can see imported pools and I can mount my ZFS root dataset manually. I attach the rdsosreport.txt from the dracut boot. |
@rugubara Thanks for testing this out! I'm really confused about what's going on here, because it's looking like the pools managed to get mounted before
Did you have dracut working before, and then this patch broke it? It sounds like your cache file is properly present in your initramfs, because you have said the pools were indeed already imported, correct? |
@aerusso, I was never able to get booted from zfs root with initramfs built by dracut. I'm desperately looking for the information how dracut boot works and why my rig refuses to boot this way, while it works ok with initramfs by genkernel.
I also found out that I have 2 sysroot.mount units:
and apparently systemd tries to start the 1st one and fails. |
If my understanding of systemd is correct, both of those should be processed. This can be confirmed with, inside your emergency shell, Also, since this setup wasn't running before, we're still going to need other input from people to see how exactly this interacts with the dependencies. |
I attach systemctl show sysroot.mount:
|
I tried to execute mount in the exact form as sysroot.mount attempts to do:
|
it seems that |
@rugubara This doesn't look to be caused by this pull request. If I had to guess, it would be that your mount is failing because you have it set to That said, this PR isn't the right place for this discussion. |
Codecov Report
@@ Coverage Diff @@
## master #6822 +/- ##
=========================================
- Coverage 75.3% 75.11% -0.2%
=========================================
Files 297 297
Lines 94441 94441
=========================================
- Hits 71116 70936 -180
- Misses 23325 23505 +180
Continue to review full report at Codecov.
|
@aerusso, I agree with you. I'm sorry for polluting your PR. After changing the root dataset mountpoint to / I could boot ok. Thank you for your explanation and help. |
Cherry picked line from PR openzfs#6822, this enables the new target introduced in PR openzfs#6764. Signed-off-by: Antonio Russo <[email protected]>
Cherry picked line from PR #6822, this enables the new target introduced in PR #6764. Signed-off-by: Antonio Russo <[email protected]>
Can we please add this to a minor release on 0.7 branch? I just had a problem after upgrade to linux 4.14 and systemd 235 where the system would no longer mount ZFS filesystems, due to |
@aerusso I am confused. I applied the patch 80b4852 on my ZFS package and it fixes the problem for me. Should I now revert this patch and try enabling zfs-import.target instead? Does that mean there is something wrong with this patch? To me it seems just right ... FWIW my distribution is ArchLinux, I build both kernel and ZFS myself, I use mkinitcpio, I do not use dracut, and systemd presets are ignored in this distribution (at least for ZFS). Setting up targets and services manually are documented part of installing ZFS on ArchLinux. |
@Bronek da16fc5 (due to #6968, and which is included in 0.7.5) contains the portion of 80b4852 which I believe resolves your issue. 80b4852 also includes additional cleanup that may be more intrusive (esp. for dracut users). I hadn't realized 0.7.5 was released---I would have just asked you to try with that. Can you check if that resolves your issue? |
@aerusso thank you, it does. I installed 0.7.5 , verified that zfs-import.target is enabled and now ZFS is mounted correctly, i.e. after import has completed. All is good now, thanks again! FWIW this is what systemd ZFS dependencies look like on my system now:
PS. in ArchLinux , presets are ignored. You can read more about it here archzfs/archzfs#72 (this issue is brought to attention during the installation of ZFS, so users know to enable services) |
Some redundancy is present in the systemd dependencies, as noticed in PR#6764. Existing setups might rely on these quirks, so these cleanups have been moved to the development branch. Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: George Melikov <[email protected]> Signed-off-by: Antonio Russo <[email protected]> Closes openzfs#6822
Some redundancy is present in the systemd dependencies, as noticed in PR#6764. Existing setups might rely on these quirks, so these cleanups have been moved to the development branch. Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: George Melikov <[email protected]> Signed-off-by: Antonio Russo <[email protected]> Closes openzfs#6822
Some redundancy is present in the systemd dependencies, as noticed in PR#6764. Existing setups might rely on these quirks, so these cleanups have been moved to the development branch. Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: George Melikov <[email protected]> Signed-off-by: Antonio Russo <[email protected]> Closes openzfs#6822
Some redundancy is present in the systemd dependencies, as
noticed in PR#6764. Existing setups might rely on these quirks,
so these cleanups have been moved to the development branch.
Description
Enable zfs-import.target by default, move dracut-mount and zfs-zed dependencies from zfs-import-*.unit to zfs-import.target, cleanup zfs-share dependency by relying on systemd default dependencies. Relax zfs-mount dependency on zfs-import to help for pools mounted before systemd, e.g., by initrd.
How Has This Been Tested?
I don't use dracut, zed, use zfs-share or have zfs on root, so I cannot test most of this. This will require eyes, and especially other users to test.
Types of changes
Checklist:
Signed-off-by
.