dracut: Fix race condition between load-key and import #11500
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
zfs-load-key.sh is called by the dracut-pre-mount.service unit which has no explicit 'After' dependency on zfs-import.target. That way it can be that the pool has not yet been imported and the zfs-load-key.sh finishes without ever seeing the relevant pool. Signed-off-by: Lorenz Hüdepohl <dev@stellardeath.org>
behlendorf
added
Component: Dracut
behlendorf
reviewed
Jan 22, 2021
behlendorf
added
Status: Accepted
behlendorf
approved these changes
Jan 25, 2021
|
Debian does package dracut, and the Debian ZFS team packages zfs-dracut. I also personally use it on two ZFS on root machines. Now with the (recently merged) path change to zgenhostid, Debian doesn't change very much related to dracut. So I think this should work as well on Debian as anywhere else. Unfortunately, I don't have time right now to test this, though. |
|
Thanks for the feedback. I'll go ahead and merge this to master. |
behlendorf
pushed a commit
that referenced
this pull request
Feb 5, 2021
zfs-load-key.sh is called by the dracut-pre-mount.service unit which has no explicit 'After' dependency on zfs-import.target. That way it can be that the pool has not yet been imported and the zfs-load-key.sh finishes without ever seeing the relevant pool. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Lorenz Hüdepohl <dev@stellardeath.org> Closes #11500
jsai20
pushed a commit
to jsai20/zfs
that referenced
this pull request
Mar 30, 2021
zfs-load-key.sh is called by the dracut-pre-mount.service unit which has no explicit 'After' dependency on zfs-import.target. That way it can be that the pool has not yet been imported and the zfs-load-key.sh finishes without ever seeing the relevant pool. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Lorenz Hüdepohl <dev@stellardeath.org> Closes openzfs#11500
sempervictus
pushed a commit
to sempervictus/zfs
that referenced
this pull request
May 31, 2021
zfs-load-key.sh is called by the dracut-pre-mount.service unit which has no explicit 'After' dependency on zfs-import.target. That way it can be that the pool has not yet been imported and the zfs-load-key.sh finishes without ever seeing the relevant pool. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Lorenz Hüdepohl <dev@stellardeath.org> Closes openzfs#11500
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Another dracut issue that surfaces for me on openSUSE. With this commit (and the recently merged #11487) I can boot from an encrypted dataset just fine.
(Note that I have a separate
/bootpartition with the kernels, as I don't want to deal with grub's zfs support for now)Description
zfs-load-key.sh is called by the dracut-pre-mount.service unit which has no explicit 'After' dependency on zfs-import.target. That way it can be that the pool has not yet been imported and the zfs-load-key.sh finishes without ever seeing the relevant pool.
How Has This Been Tested?
I build zfs packages for openSUSE, available at https://build.opensuse.org/project/show/home:lorenz:filesystems
This commit and the recently merged #11487 are included as a patch there, and the resulting packages are in active use by myself and a few others. With the patch, the affected dracut initrd zfs services are then active also on openSUSE.
Types of changes
Checklist:
Signed-off-by.