This mirrors what was done in 564761fcae
for sysusers.d. If we allow separating resolved sysusers config
in a subpackage, we should do the same for the symlink that is
only useful when resolved is installed.
Related to #21317.
The sentence wasn't correct English language, let's fix that. More
importantly: if the mount options are empty we'd display "(null)" here.
Fix that. (And they can be empty IRL, see CI results)
The man page doesn't quite match what --help says, and I needed to use "-f" to
write a wiped partition. This all feels a bit experimental, but the fs has some
adherents, and we should make it easy to use.
(Also, an empty 256MB device formatted and mounted shows up as
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 254M 85M 170M 34% /var/tmp/mount
which also seems a bit over the top…)
Requested in https://github.com/systemd/systemd/pull/21275#issuecomment-967928690.
Apparently mkswap has it's own limit, and it seems to be one lower than the one
for ext2/3/4.
$ for i in ext2 ext3 ext4 btrfs xfs vfat swap minix; do
echo $i && wipefs -q -a '/var/tmp/głąbźśńćąśððð.img'
build/systemd-makefs $i '/var/tmp/głąbźśńćąśððð.img'
done
ext2
/var/tmp/głąbźśńćąśððð.img successfully formatted as ext2 (label "głąbźśńćą", uuid 7626bc5c-8ac4-43cf-87b7-1b2761272dd3)
ext3
/var/tmp/głąbźśńćąśððð.img successfully formatted as ext3 (label "głąbźśńćą", uuid 0da22cad-0dbf-4a7a-962d-12cd39d006b5)
ext4
/var/tmp/głąbźśńćąśððð.img successfully formatted as ext4 (label "głąbźśńćą", uuid dded267b-8955-4d19-82a5-1f231d446059)
btrfs
/var/tmp/głąbźśńćąśððð.img successfully formatted as btrfs (label "głąbźśńćąśððð.img", uuid 9e2e89f1-010d-4ab6-80f3-f9e215dbc225)
xfs
/var/tmp/głąbźśńćąśððð.img successfully formatted as xfs (label "głąbźśń", uuid 2cc937af-4c41-465c-8f52-aab2304bd860)
vfat
mkfs.fat 4.2 (2021-01-31)
/var/tmp/głąbźśńćąśððð.img successfully formatted as vfat (label "G__B_______", uuid a3a9e028)
swap
...
LABEL=głąbźśńć, UUID=0ab787aa-37a6-4b32-978b-d71efc6e6098
/var/tmp/głąbźśńćąśððð.img successfully formatted as swap (label "głąbźśńć", uuid 0ab787aa-37a6-4b32-978b-d71efc6e6098)
minix
...
/var/tmp/głąbźśńćąśððð.img successfully formatted as minix (no label or uuid specified)
I was testing with a "test1.img" and mkfs.vfat rejects "TEST1.IMG" with the
error "Labels with characters *?.,;:/\|+=<>[]" are not allowed". So let's
replace those characters with "_".
Users may use rules that refer to binaries e.g. in /opt or /usr/local,
and those directories may be separate mount points. We don't need the
binfmt rules in early boot, so let's delay the service so that we can
rely on the full local filesystem being visible.
Fixes#21178.
This new helper converts libc style syscall return values into
systemd-kernel (actually: kernel style) negative errno values.
It's implemented as macro-like inline function, and propagates return
values >= 0 as themselves and returns -errno for negative error returns.
THis is supposed to be little more than syntactic sugar so that we can
reduce a lot of (short, but still) boilerplate code whever we convert
libc style error handling into our own.
As discussed here:
https://github.com/systemd/systemd/pull/21326#discussion_r748413537
There are two ways to deactivate a home dir: the official way if someone
calls "homectl deactivate" or something similar. Or the
error-case/side-effect code path, where we unwind exactly what we
already set up.
The .undo_dm field is supposed to tell us whether we shall still detach
the DM device. We forgot to update it in the official code path. Add
that. (We did it correctly in the error case codepath already).
(The issue is minor: if we forget to reset it in the clean code path,
then we'll try to unmount again what is already unmounted in the error
code paths, but since we ignore errors there — to not "stack" errors –
we never noticed and there's no bad effect of it)
smb3 is an alias for modern CIFS, not the old SMB fs (see kmod alias list, i.e. modinfo fs-smb3).
(the old smbfs has long been removed from the kernel actually, it's dead
and obsolete)
There are a bunch of filesystems that actually are just aliases for
other filesystems. So far we listed them as "ungrouped", suggesting they
should be added to some file system group. But that's not really
something needed, since they are after all not file systems in their own
right, but aliases only (and usually legacy at that).
hence, let's hide them from display (but debug log about them)
devtmpfs and cpuset are not actual filesystems of their own. cpuset used
to be but is now an alias for cgroupsfs. devtmpfs is the same as tmpfs
as its just a "named superblock", i.e. a specific instance of tmpfs, but
not a file system of its own.
This group shall cover file systems whose job is to make stuff that
isn't actually storing anything in itself, and isn't just an API file
system, but allows exposing stuff with special semantics in the VFS.
1. @anonymous → for file systems that aren't real file systems but
simply the backing for sockets, pipes and other "anonymous" fds.
2. @security → for the various MAC security file systems.
