Defaulting to fedora makes it a pain to override mkosi.default
point to one of the other mkosi settings files. Instead, have
every developer manually add the symlink to his distro
of choice and don't commit the symlink to the repository by
putting it in the .gitignore.
Currently systemd-user-runtime-dir does not create the files in
/run/user/$UID/systemd/inaccessible with the default SELinux label.
The user and role part of these labels should be based on the user
related to $UID and not based on the process context of
systemd-user-runtime-dir.
Since v246-rc1 (9664be199a) /run/user/$UID/systemd is also created by
systemd-user-runtime-dir and should also be created with the default
SELinux context.
This commit enables the microphone mute button and the screen rotate button, even if the latter is improperly linked. I have documented how to achieve this in https://wiki.archlinux.org/index.php/MSI_P15#Fn_Keys .
We never return anything higher than 63, so using "long unsigned"
as the type only confused the reader. (We can still use "long unsigned"
and safe_atolu() to parse the kernel file.)
We would refuse to print capabilities which were didn't have a name
for. The kernel adds new capabilities from time to time, most recently
cap_bpf. 'systmectl show -p CapabilityBoundingSet ...' would fail with
"Failed to parse bus message: Invalid argument" because
capability_set_to_string_alloc() would fail with -EINVAL. So let's
print such capabilities in hexadecimal:
CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search
cap_fowner cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap
cap_linux_immutable cap_net_bind_service cap_net_broadcast cap_net_admin
cap_net_raw cap_ipc_lock cap_ipc_owner 0x10 0x11 0x12 0x13 0x14 0x15 0x16
0x17 0x18 0x19 0x1a ...
For symmetry, also allow capabilities that we don't know to be specified.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1853736.
The call would always fail with:
systemd-userwork[780]: Failed to dlopen(libnss_systemd.so.2), ignoring: /usr/lib64libnss_systemd.so.2: cannot open shared object file: No such file or directory
For some reason the wait-online is failing intermittently; it's unclear
exactly why, but this hopefully avoids the failure for unrelated PR.
This is a workaround (not fix) for #16105
Several recent failed runs show that the test is still racy in two ways:
1) Sometimes it takes a while before the PID file is created, leading
to:
```
[ 10.950540] testsuite-47.sh[308]: ++ cat /leakedtestpid
[ 10.959712] testsuite-47.sh[308]: cat: /leakedtestpid: No such file or directory
[ 10.959824] testsuite-47.sh[298]: + leaked_pid=
```
2) Again, sometimes we check the leaked PID before the unit is actually
stopped, leading to a false negative:
```
[ 18.099599] testsuite-47.sh[346]: ++ cat /leakedtestpid
[ 18.116462] testsuite-47.sh[333]: + leaked_pid=342
[ 18.117101] testsuite-47.sh[333]: + systemctl stop testsuite-47-repro
...
[ 20.033907] testsuite-47.sh[333]: + ps -p 342
[ 20.080050] testsuite-47.sh[351]: PID TTY TIME CMD
[ 20.080050] testsuite-47.sh[351]: 342 ? 00:00:00 sleep
[ 20.082040] testsuite-47.sh[333]: + exit 42
```
Add support for creating a MACVLAN interface in "source" mode by
specifying Mode=source in the [MACVLAN] section of a .netdev file.
A list of allowed MAC addresses for the corresponding MACVLAN can also
be specified with the SourceMACAddress= option of the [MACVLAN] section.
An example .netdev file:
[NetDev]
Name=macvlan0
Kind=macvlan
MACAddress=02:DE:AD:BE:EF:00
[MACVLAN]
Mode=source
SourceMACAddress=02:AB:AB:AB:AB:01 02:CD:CD:CD:CD:01
SourceMACAddress=02:EF:EF:EF:EF:01
The same keys can also be specified in [MACVTAP] for MACVTAP kinds of
interfaces, with the same semantics.
Daan De Meyer