(RHEL-6210) units: introduce [email protected] for properly ordering mounts/swaps #429
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
github-actions
bot
added
tracker/missing
Commit validationTracker - RHEL-6210 The following commits meet all requirements
Tracker validationSuccess🟢 Tracker RHEL-6210 has set desired product: Pull Request validationFailed🔴 Failed or pending checks - |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
…against cryptsetup Let's hook it into both cryptsetup-generator and gpt-auto-generator with a shared implementation in generator.c Fixes: #8472 (cherry picked from commit a7e8855) Related: RHEL-6210
For static functions the compiler should figure this out on its own. (cherry picked from commit 219f3cd) Related: RHEL-6210
…lter it out (cherry picked from commit 5de0acf) Related: RHEL-6210
This catches up with the logic we do for mounts: we create deps based on /proc/swaps now too, with the right flags set. (cherry picked from commit 61f9cf4) Related: RHEL-6210
This way we shuld be able to order mounts properly against their backing services in case complex storage is used (i.e. LUKS), even if the device path used for mounting the devices is different from the expected device node of the backing service. Specifically, if we have a LUKS device /dev/mapper/foo that is mounted by this name all is trivial as the relationship can be established a priori easily. But if it is mounted via a /dev/disk/by-uuid/ symlink or similar we only can relate the device node generated to the one mounted at the moment the device is actually established. That's because the UUID of the fs is stored inside the encrypted volume and thus not knowable until the volume is set up. This patch tries to improve on this situation: a implicit [email protected] dependency is generated for all mounts, based on the data from /proc/self/mountinfo, which should be the actual device node, with all symlinks resolved. This means that as soon as the mount is established the ordering via [email protected] will work, and that means during shutdown it is honoured, which is what we are looking for. Note that specifying /etc/fstab entries via UUID= for LUKS devices still sucks and shouldn't be done, because it means we cannot know which LUKS device to activate to make an fs appear, and that means unless the volume is set up at boot anyway we can't really handle things automatically when putting together transactions that need the mount. (cherry picked from commit 44b0d1f) Related: RHEL-6210
(cherry picked from commit 68bda07) Related: RHEL-6210
msekletar
force-pushed
the
blockdev-target
branch
from
421ddc0
to
aec5515
Compare
msekletar
force-pushed
the
blockdev-target
branch
from
aec5515
to
825d319
Compare
github-actions
bot
added
tracker/unapproved
In particular, let's just say "is" and "must" instead of "may be" and "should". The weaker forms are obviously correct, but the text is easier to understand if non-conditional forms are used. (cherry picked from commit 8e92d92) Related: RHEL-6210
We want that cryptsetup/veritysetup devices can stick around until the very end, as well as the users of them which might depend on [email protected] for the devices. Hence leave the targets around till the very end. Note that their runtime is managed via StopWhenUnneeded= anyway, hence unless their are volumes that actually survive still the very end they target units will still be stopped. (cherry picked from commit d120ce478dc0043c89899799b5c1aaf62901bea9) Related: RHEL-6210
Follow-up for d120ce478dc0043c89899799b5c1aaf62901bea9 [email protected] is used as a synchronization point between the mount unit and corresponding [email protected]. After the mentioned commit, it doesn't get a stop job enqueued during shutdown, and thus the stop job for [email protected] could be run before the mount unit is stopped. Therefore, let's make [email protected] conflict with umount.target, which is also what [email protected] does. Fixes #29336 (cherry picked from commit 99f360a46b6304d87a483be8e09d5e5176be13aa) Related: RHEL-6210
msekletar
force-pushed
the
blockdev-target
branch
from
825d319
to
4f26150
Compare
github-actions
bot
added
tracker/missing
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.
No description provided.