341890de86 made "bootctl install" create
ESP\MID, in preparation of cf73f65089 that
followed it and created 00-entry-directory.install to make ESP\MID\KVER
if ESP\MID existed ‒ this meant that "bootctl install" followed by
"kernel-install $(uname -r) /boot/vml*$(uname -r) /boot/ini*$(uname -r)"
actually installed the kernel correctly.
Later, 31e57550b5 reverted the first
commit, meaning, that now running those two commands first installs
sd-boot, but then does nothing. Everything appears to work right,
nothing errors out, but no changes are actually done. To the untrained
eye (all of them), even running with -v appears to work:
all the hooks are run, as is depmod, but, again, nothing happens.
This is horrible. Nothing in either manpage suggests what to do
(nor should it, really), but the user is left with a bootloader that
appears fully funxional, since nothing suggests a failure in the output,
but with an unbootable machine, /no way to boot it/, even if they drop
to an EFI shell, since the boot bundle isn't present on the ESP,
and no real recourse even if they boot into a recovery system,
apart from installing like GRUB or whatever.
00- is purely instrumentation for 90-,
and separating one from the other has led to downstream dissatisfaxion
(indeed, the last mentioned commit cited cited exactly that as the
reversion reason), while creating $ENTRY_DIR_ABS is only required
for bootloaders using the BLS, and shouldn't itself toggle anything.
To that end, introduce an /{e,l}/k/install.conf file that allows
overriding the detected layout, and detect it as "bls" if
$BOOT_ROOT/$MACHINE_ID ($ENTRY_DIR_ABS/..) exists, otherwise "other" ‒
if a user wishes to select a different bootloader,
like GRUB, they (or, indeed, the postinst script) can specify
layout=grub. This disables 90- and $ENTRY_DIR_ABS manipulation.
link_address_is_dynamic() is costful in general. Call it only when
KeepConfiguration= is set.
Note, it is not necessary to check link->network in the loop, as we have
the assertion for that in the beginning of the function.
If KERNEL_INSTALL_MACHINE_ID is defined in /etc/machine-info, prefer it
over the machine ID from /etc/machine-id. If a machine ID is defined in
neither /etc/machine-info nor in /etc/machine-id, generate a new UUID
and try to write it to /etc/machine-info as KERNEL_INSTALL_MACHINE_ID
and use it as the machine ID if writing it to /etc/machine-info succeeds.
In practice, this means we have a more robust fallback if there's no
machine ID in /etc/machine-id than just using "Default" and allows
image builders to force kernel-install to use KERNEL_INSTALL_MACHINE_ID
by simply writing it to /etc/machine-info themselves.
The way that the cryptsetup plugins were built was unnecessarilly complicated.
We would build three static libraries that would then be linked into dynamic
libraries. No need to do this.
While at it, let's use a convenience library to avoid compiling the shared code
more than once.
We want the output .so files to be located in the main build directory,
like with all consumable build artifacts, so we need to maintain the split
between src/cryptsetup/cryptsetup-token/meson.build and the main meson.build
file.
AFAICT, the build artifacts are the same: exported and undefined symbols are
identical. There is a tiny difference in size, but I think it might be caused
by a different build directory name.
It doesn't make much sense to do this, the result is very similar to including
to objects directly in the output binary without going through an intermediate
target.
The linkage of test-libudev was rather strange too: udev_link_with is used to
allow udev to be linked to a static version of libshared, so that udev is not
linked to libshared.so. But here we were using both, defeating the purpose of
udev_link_with. I don't think it matters what the test is linked to, so let's
use the non-static linkage to save space.
The meson default for static_library() are:
build_by_default=true, install=false. We never interact with the
static libraries, and we only care about them as a stepping-stone towards
the installable executables or libraries. Thus let's only build them if
they are a dependency of something else we are building.
While at it, let's drop install:false, since this appears to be the default.
This change would have fixed the issue with lib_import_common failing
to build too: we wouldn't attempt to build it.
In practice this changes very little, because we generally only declare static
libraries where there's something in the default target that will make use of
them. But it seems to be a better pattern to set build_by_default to false.
Use a 'convenience library' to do the compilation once and then link the
objects into all the files that need it. Those files are small, so this probably
doesn't matter too much for speed, but has the advantage that we don't get the
same error four times if something goes wrong.
The library is conditionalized in the same way importd itself, because we
cannot build it without the deps.
Let's not try to be overly clever here. This code path is not overly
performance sensitive and we should avoid trying to outsmart the kernel
without proper benchmarking.
pread() is not guaranteed to completely fill up the given buffer with
data which we assumed until now. Instead, only increment the offset by
the number of bytes that were actually read.
The variable is not useful outside of the loop (it'll always be null
after the loop is finished), so we can declare it inline in the loop.
This saves one variable declaration and reduces the chances that somebody
tries to use the variable outside of the loop.
For consistency, 'de' is used everywhere for the var name.
This was an undocumented change in behavior introduced by
9e82a74cb0. Previously, we only
checked for "Default" if we didn't find a machine ID. Let's make
sure we keep the previous behavior intact.
We get "upstream" dns server config from ~three places: /etc/resolv.conf,
config files, and runtime config via dbus. With this commit, we'll filter out
our own stub listeners if they are configured in either of the first two
sources. For /etc/resolv.conf this is done quitely, and for our own config
files, a LOG_INFO message is emitted, since this is a small inconsistency in
the config.
Setting loops like this over dbus is still allowed. The reason is that in the
past we didn't treat this as an error, and if we were to start responding with
an error, we could break a scenario that worked previously. E.g. NM sends us a
list of servers, and one happens to be the our own. We would just not use that
stub server before, but it'd still be shown in the dbus properties and such.
We would have to return error for the whole message, also rejecting the other
valid servers. I think it's easier to just keep that part unchanged.
Test case:
$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 57 Dec 15 10:26 /etc/resolv.conf
$ cat /etc/resolv.conf
nameserver 192.168.150.1
options edns0 trust-ad
search .
$ cat /etc/systemd/resolved.conf.d/stub.conf
[Resolve]
DNSStubListenerExtra=192.168.150.1
$ resolvectl
...
Global
resolv.conf mode: foreign
DNS Servers: 192.168.150.1
Fallback DNS Servers: ...
(with the patch):
Global
resolv.conf mode: foreign
Fallback DNS Servers: ...
The message that the "journal begins … ends …" has been always confusing to
users. (Before b91ae210e6 it was "logs begin … end …" which was arguably even
more confusing, but really the change in b91ae210e6 didn't substantially change
this.)
When the range shown is limited (by -e, -f, --since, or other options), it
doesn't really matter to the user what the oldest entries are, since they are
purposefully limiting the range. In fact, if we are showing the last few
entries with -e or -f, knowing that many months the oldest entries have is
completely useless.
And when such options are *not* used, the first entry generally corresponds to
the beginning of the range shown, and the last entry corresponds to the end of
that range. So again, it's not particularly useful, except when debugging
journalctl or such. Let's just treat it as a debug message.
Fixes#21491.
The idea is to be able to distinguish whether we're in a VM/container or something
more substantial at a glance.
Chassis: laptop 💻
Chassis: tablet 具
Chassis: vm 🖴
Chassis: server 🖳
Chassis: handset 🕻
Chassis: watch ⌚
Chassis: desktop 🖥
Chassis: container ☐
Commit 49ef064c8d attempts to handle
"stub loop" by switching to the next server *after the query has
been made*.
The approach may be good enough for link scopes. However, for the
manager / global scope, it is not. First of all, there are more than
one types (SYSTEM and FALLBACK) of servers it can use. Also, whether
those of type FALLBACK should be used depends.
Besides, dns_scope_good_domain() determines whether things should
be routed to a scope by checking whether the scope has a server.
The decision made would be incorrect if stubs were not filtered
beforehand.
Therefore, to avoid failing query unnecessarily, and to make sure
that extra stub listeners will not trigger unexpected and/or
inconsistent behavior, make manager_get_dns_server() do what it
should have done.
This replaces the memmem-based approach of finding a suitable title
for the windows boot manager with one that actually parses the BCD
store. It's probably faster but more importantly, it's more correct.
The memmem approach may detect stale title strings that are still
in the file but unused due to the way registry hives are updated.
This approach also allows us to detect if the BCD store is multi-boot
so that we can fall back on the generic one instead.
наб
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Daan De Meyer
Luca Boccassi
Tom Yan
Jan Janssen