Introduce vfstab support for mount.fstab, entries for opts look a bit
weird. Default are '-' so it will end up as a list containing '-'.
I left this to keep 'opts' the same as for normal fstabs.
Example output:
/dev/fd:
----------
device:
fd
device_fsck:
-
fstype:
fd
mount_at_boot:
no
opts:
- -
pass_fsck:
-
/devices:
----------
device:
/devices
device_fsck:
-
fstype:
devfs
mount_at_boot:
no
opts:
- -
pass_fsck:
-
/etc/dfs/sharetab:
----------
device:
sharefs
device_fsck:
-
fstype:
sharefs
mount_at_boot:
no
opts:
- -
pass_fsck:
-
/proc:
----------
device:
/proc
device_fsck:
-
fstype:
proc
mount_at_boot:
no
opts:
- -
pass_fsck:
-
/system/contract:
----------
device:
ctfs
device_fsck:
-
fstype:
ctfs
mount_at_boot:
no
opts:
- -
pass_fsck:
-
/system/object:
----------
device:
objfs
device_fsck:
-
fstype:
objfs
mount_at_boot:
no
opts:
- -
pass_fsck:
-
/tmp:
----------
device:
swap
device_fsck:
-
fstype:
tmpfs
mount_at_boot:
yes
opts:
- size=2048m
pass_fsck:
-
* mount.swaps now works on solarish like systems
* mount.swapon / mount.swapoff supported on solarish platforms
* mount.active (and internal consumers) now work on all solarish platforms
* unit-tests - mount_tests should set kernel grain
* Add salt.utils.is_hex()
* dulwich: use salt.utils.is_hex() to confirm ref is hexidecimal
* Restore ability for SHA1 saltenvs to be used in gitfs
This uses salt.utils.is_hex() to check if the desired environment is
hex, and allowing it to be used for gitfs operations when it is.
* pygit2: Catch ValueError when trying to resolve SHA1
Hex SHAs which are less than 4 characters will raise a ValueError, this
commit catches these exceptions.
See https://github.com/saltstack/salt/issues/34213 for more information.
Some providers (esp. Bitbucket) have faulty git/SSH endpoints which
often simply return empty results. A previous attempt in Salt to improve
this by adding an optional timeout value didn't change much here, as it
just increased the time it took to return: nothing.
Repeating the request a few times until the host returns a value works
around this issue far more reliable.
Signed-off-by: Elias Probst <mail@eliasprobst.eu>
Catching the ValueError around line 416 means that when we re-raise
the exception below, we raise the wrong exception. This commit
explicitly raises the outer-scope exception that we caught above the
block where we attempt to read from the lock file.
Resolves#34114.
