For "kernel-install remove ..." only the kernel version is passed, not
the kernel image. So auto-detecting KERNEL_INSTALL_IMAGE_TYPE and
setting KERNEL_INSTALL_LAYOUT does not work for uninstall.
The 90-uki-copy.install plugin must consider this and *not* exit early
for the "remove" command, otherwise $BOOT_ROOT will be filled with stale
kernel images.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Naming is always a matter of preference, and the old name would certainly work,
but I think the new one has the following advantages:
- A verb is better than a noun.
- The name more similar to "the competition", i.e. 'sudo', 'pkexec', 'runas',
'doas', which generally include an action verb.
- The connection between 'systemd-run' and 'run0' is more obvious.
There has been no release yet with the old name, so we can rename without
caring for backwards compatibility.
c0aeff4b99 added this in one unit file, but the
same problem occurs here. (There are no other files where this would apply.)
I think we should solve this systematically somehow, but it's not clear how to
do that, so until we have that better solution, let's apply the manual solution
so that our units work as expected.
Now, networkd accesses the state directory through the file descriptor
passed from systemd-networkd-persistent-storage.service.
Hence, the networkd itself does not need to access the state directory
through its path, and we can use more stronger mode for ProtectSystem=.
The state directory is owned by systemd-networkd-persistent-storage.service,
at least technically. Let's not directly access the storage through the path,
but through the fd.
Addresses https://github.com/systemd/systemd/pull/31746#issuecomment-1993556966.
Suggested-by: Mike Yuan <me@yhndnzj.com>
It's not actually a dbus method, just function that all the various dbus
methods end up calling to update the user record. So rename it to
reflect as such
ukify is part of systemd-experimental on OpenSUSE and not its own
package. Because the OpenSUSE systemd maintainers do not want to
introduce a python dependency for systemd-experimental, we have to
install python3-pefile manually to make sure ukify works properly.
Currently, if a unit file is enabled from outside of the search path,
and that unit has an alias, then the symlink ends up pointing outside of
the search path too. For example:
$ cat /tmp/a.service
[Service]
ExecStart=sleep infinity
[Install]
Alias=b.service
WantedBy=multi-user.target
$ systemctl enable /tmp/a.service
Created symlink /etc/systemd/system/a.service → /tmp/a.service.
Created symlink /etc/systemd/system/b.service → /tmp/a.service.
Created symlink /etc/systemd/system/multi-user.target.wants/a.service → /tmp/a.service.
This then means the alias is treated as a separate unit:
$ systemctl start a.service
$ sudo systemctl status a
● a.service
Loaded: loaded (/etc/systemd/system/a.service; enabled; preset: enabled)
Active: active (running) since Fri 2024-03-15 15:17:49 EDT; 9s ago
Main PID: 769593 (sleep)
Tasks: 1 (limit: 18898)
Memory: 220.0K
CPU: 5ms
CGroup: /system.slice/a.service
└─769593 sleep infinity
Mar 15 15:17:49 six systemd[1]: Started a.service.
$ sudo systemctl status b
○ b.service
Loaded: loaded (/etc/systemd/system/b.service; alias)
Active: inactive (dead)
To fix this, make sure the alias uses a target that is inside the search
path. Since the unit file itself is outside of the search path, a
symlink inside the search path will have been created already. Hence,
just point the alias symlink to that recently created symlink.
In some cases when a query completes there are still pending
transactions that are no longer useful to answer the query. But if this
query is repeated in the future and we don't have the answers cached,
we're going to ask and ignore the answer again.
Instead of purging these superfluous transactions, let's wait and see if
they produce an answer, since we already asked the question, and use it
to fill our cache.
opensuse's OBS has two git mirrors, code.opensuse.org uses pagure,
src.opensuse.org uses gitea. Let's try src.opensuse.org as pagure
doesn't seem to work properly when more advanced git functionality
is used.
Currently the associated units fail if full tpm support is not available
on the system. Similar to systemd-pcrextend, let's add a --graceful option
that exits gracefully if no full TPM support is detected and use it in both
units.
The docs say that support is experimental, but it's better for us if we know
about any problems early.
Header tests pass without any issue with gcc-14.0.1-0.8.fc40.x86_64.
- mention the version format spec for sytsemd-vpick
- say what "systemd-creds --user" can be used by unprivileged users as well
- say what importctl does
- use en dash instead of em dash
- add a missing article