Previously, varlink or dbus methods return
io.systemd.Resolve.NoNameServers or BUS_ERROR_NO_NAME_SERVERS if an
empty hostname is provided, and thus nss-resolve returns NSS_STATUS_TRYAGAIN.
That causes getaddrinfo() returns 'Temporary failure in name resolution'
instead of 'Name or service not known'.
This makes calling varlink or dbus method with an empty hostname result
-EINVAL, and hence nss-resolve returns NSS_STATUS_NOTFOUND.
Fixes RHBZ#2039854 (https://bugzilla.redhat.com/show_bug.cgi?id=2039854).
Currently if systemd-oomd doesn't kill anything in a selected cgroup, it
selects a new candidate immediately. But if a selected cgroup wasn't killed,
it is likely due to it disappearing or getting cleaned up between the time
it was selected as a candidate and getting sent SIGKILL(s). We should handle
it as though systemd-oomd did perform a kill so that it will check
swap/pressure again before it tries to select a new candidate.
There can be a situation where systemd-oomd would kill all of the processes
in a cgroup, pid1 would clean up that cgroup, and systemd-oomd would get
ENODEV trying to iterate the cgroup a final time to ensure it was empty.
systemd-oomd sees this as an error and immediately picks a new candidate even
though pressure may have recovered. To counter this, check and handle
path unavailability errnos specially.
Fixes: #22030
by always calling journal_remote_server_destroy, which resets global
variables like journal_remote_server_global. It should prevent crashes like
```
Assertion 'journal_remote_server_global == NULL' failed at src/journal-remote/journal-remote.c:312, function int journal_remote_server_init(RemoteServer *, const char *, JournalWriteSplitMode, _Bool, _Bool)(). Aborting.
AddressSanitizer:DEADLYSIGNAL
=================================================================
==24769==ERROR: AddressSanitizer: ABRT on unknown address 0x0539000060c1 (pc 0x7f23b4d5818b bp 0x7ffcbc4080c0 sp 0x7ffcbc407e70 T0)
SCARINESS: 10 (signal)
#0 0x7f23b4d5818b in raise /build/glibc-eX1tMB/glibc-2.31/sysdeps/unix/sysv/linux/raise.c:51:1
#1 0x7f23b4d37858 in abort /build/glibc-eX1tMB/glibc-2.31/stdlib/abort.c:79:7
#2 0x7f23b5731809 in log_assert_failed systemd/src/basic/log.c:866:9
```
systemd seems to be failing to compile there with gcc-12 but considering
that gcc-12 hasn't been released yet it doesn't seem to make sense
to add workarounds to get it to compile there. Until gcc-12 is
stabilized it should be enough to build systemd on fedora-35 to
make sure it's buildable on i386.
Jan 17 12:34:59 myguest1 (sd-sysext)[486]: Device '/var/lib/extensions/myext.raw' is loopback block device with partition scanning turned off, please turn it on.
Fixes https://github.com/systemd/systemd/issues/22146
A rolling distro won't set VERSION_ID or SYSEXT_LEVEL in os-release,
which means we skip validation of ExtensionImages.
Validate even with just an ID, the lower level helper already
recognizes and accepts this use case.
Fixes https://github.com/systemd/systemd/issues/22146
Remove the parameter 'only_auto' from the function
boot_entries_augment_from_loader() because each caller set it always to
true.
Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
When bootctl lists the boot entries, considers also the ones
returned by systemd-boot (via the efi LoaderEntries variable),
created at boot time.
Unfortunately this list may became incorrect if (e.g.) the user remove a
kernel package.
This patch changes this behaviour, so bootctl ignores some the
boot entries returned by systemd-boot.
In any case, bootctl still considers the 'auto-xxx' boot entries
listed below:
Boot entrie name Title
----------------------------- ------------------------------
auto-osx macOS boot loader
auto-windows Windows Boot Manager
auto-efi-shell EFI Shell
auto-efi-default EFI Default Loader
auto-reboot-to-firmware-setup Reboot Into Firmware Interface
The other entries that systemd-boot synthetizes (e.g. the ones loaded from
/efi/loader/entries/<uuid>) can be synthetized by bootctl too, so no
information is lost.
Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
The device path should not contain multiple hard drive nodes in it,
so looking at them all should not be needed.
If some crazy firmware/driver were to make nested GPT drives
available like that, we should be only looking at the last partition
and its containing GPT drive anyway.
Some firmware creates partition device paths without a messaging
device path node, making the search for the xboot loader partition
fail.
Fixes: #17756
Yu Watanabe
Jan Janssen
Anita Zhang
Evgeny Vereshchagin
Thomas Batten
Tyson Whitehead
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Ludwig Nussel
Goffredo Baroncelli