3008.x: Fix "mount.swap" activation when using UUID and introduce "resolve_canonical" argument - #70201
Open
meaksh wants to merge 8 commits into
Open
Conversation
fstab(5) allows a swap to be identified by a TAG=value specification
instead of a device path, and swapon(8) resolves those tags. The state
did not: it compared the configured name against the output of
mount.swaps, which is read from /proc/swaps and therefore only ever
contains device paths.
The comparison could never match, so the state called mount.swapon on
every run and then reported
Swap UUID=... failed to activate
even though the swap was active all along.
Resolve TAG=value specifications to a device path with blkid before
looking them up, reusing the _convert_to() helper that fstab_present
already uses for the same purpose. Specifications that no block device
matches are left untouched, so a genuine failure is still reported with
the name the user configured.
/proc/swaps, and therefore mount.swaps, reports the path the kernel
arrived at when the swap was activated, which need not be the name used
to activate it: swapon(8) follows symlinks, so a swap activated as
/dev/mapper/system-swap is reported as /dev/dm-0.
That is not a corner case for the TAG=value specifications resolved in
the previous commit, it is the normal result for LVM and dm-crypt
setups. blkid names those devices through /dev/mapper:
# blkid -t UUID=42fbd303-5ed5-4c40-b382-d1bef97e5d88
/dev/mapper/cr_home: UUID="42fbd303-..." TYPE="ext4"
so the resolved device still would not have matched what the kernel
reports. The same applies to a swap configured as a symlink, such as
/dev/disk/by-uuid/<uuid>.
Resolve both the configured name and the keys of the active swaps with
os.path.realpath() before comparing them. This also replaces the
hand-rolled symlink resolution, which only followed a single level and
assumed that a relative link target lived in /dev.
While here, use the resolved device for the "is set to be added to the
fstab and to be activated" test-mode check as well; it looked up the
unresolved name and so never fired for a symlinked device.
Adjust code after moving functions to salt.utils.mount
Co-authored-by: Yeray Gutiérrez Cedrés <yeray.gutierrez@suse.com>
meaksh
force-pushed
the
3008.x-fix-mount-swap-check-canonical-names
branch
2 times, most recently
from
September 1, 2026 15:39
f249103 to
4dde1c8
Compare
twangboy
previously approved these changes
Sep 1, 2026
Contributor
|
Looks like you have some pre-commit failures |
3 tasks
twangboy
previously approved these changes
Sep 2, 2026
Contributor
Author
|
@twangboy I just pushed a small variable rename to make the name really consistent with its purpose. Sorry because this has dismissed your previous approval. |
twangboy
approved these changes
Sep 3, 2026
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
What does this PR do?
This PR fixes an issue on
mount.swapstate, when a device is passed usingUUIDor other labels instead of its canonical name. The state execution fails when trying to activate the swap.For example, given the following context:
And given the following SLS:
The state execution fails with:
Additionally to fixing the above issue, this PR introduces the
resolve_canonicalargument (Default:False) for the followingmountfunctions:mount.set_fstabmount.rm_fstabmount.mounted(state)mount.unmounted(state)mount.swap(state)mount.fstab_present(state)mount.fstab_absent(state)When
resolve_canonicalis set toTrue, then the mechanism to detect existing entries will always resolve the device to its canonical name, preventing the creation of duplicate entries when using canonical names and your existing entries are using UUID references (or viceversa)What issues does this PR fix or reference?
Fixes #16084
Fixes openSUSE/salt#679
Merge requirements satisfied?
[NOTICE] Bug fixes or features added to Salt require tests.
Commits signed with GPG?
Yes