As reported in https://github.com/systemd/systemd/issues/38222, we get the
buffer size calculation wrong on 32-bit arm. The reporter suggested checking if
__TIMESIZE == 64, but I think it's better to just use the bigger size in all
cases. The code to guesstimate the buffer size was already tweaked a few times
and apparently it's not easy to get it right. Systemd and glibc might be
compiled with different combinations of __TIMESIZE, so the compile-time check
is not super reliable, and by using the bigger size, we don't depend on the
details of how glibc decided whether to duplicate the struct or not. The cost
is negligible, 16 bytes on stack, so let's do the easy and robust thing.
Solution based on the suggestion by UZver24.
While at it, drop the mock struct definitions. They are only used to calculate
the size, but since the types involved are 8-bit values, there are no alignment
issues and we can just calculate the size directly.
Fixes https://github.com/systemd/systemd/issues/38222.
The comment in linux_exec() was based on Lennart's comment in
https://github.com/systemd/systemd/pull/37372#discussion_r2142340582, but
shortened. The original wording is more direct and at least for me easier to
grok, so adjust the comment to be more verbose again.
Also, move the comment from shim_loader_available() to the place where it used.
This function is for checking if the new thing is available, no need to describe
the old thing there.
This extends the functionality introduced in #21648 to allow using
addresses chosen from a delegated prefix as well as the existing
SLAAC/LL/DHCP functionality.
Follow-up for 81fb5375b3
The offending commit fails to account for the case where
we have fewer lines before --until= than what's specified
in --lines=. Aside from that, if --grep= + --lines=+N are used,
we might also seek forward in the middle of the loop,
breaking the --until= boundary.
Let's turn the logic around then. Context.until_safe will
be set iff we're certain that there's enough to output,
and it gets reset whenever we seek forward.
Fixes#38121
Replaces #38122
To avoid the following warnings:
```
systemd-networkd-tests.py[3139]: Stopping 'systemd-networkd.service', but its triggering units are still active:
systemd-networkd-tests.py[3139]: systemd-networkd-varlink.socket
```
Follow-up for b0ea79c5b5.
Instead, please use the kernel command line options with the same name.
I am not sure these files are System V complieant or not, but at least
they are very traditional way to control fsck or quotacheck.
However, the concept of the files are really broken, especially for
fsck. As when we want to fsck the root filesystem, we need to access the
filessystem, but it may be broken...
Let's drop such traditional ways to control fsck and quotacheck.
We already support kernel command line options to control the behaviors.
Maybe, also it is better to provide ways to control them by credentials.
Since kernel 4.18 BTRFS_IOC_GET_SUBVOL_INFO exists to query subvolume
metadata without privs. This is much better than the manual approach
with finding objects in the fs tree (which is priv). Let's use it, and
drop the old code (since 4.18 is older than our baseline).
Commit b6d4997683
("Add --entry-type=type1|type2 option to kernel-install.")
Skip removing UKI related contents when BOOT_ENTRY_TYPE=type1
Signed-off-by: Li Tian <litian@redhat.com>
