kernel-install: create the entry directory only if $BOOT/$MACHINE_ID exists
Things are currently fairly ugly in Fedora: we create $BOOT/$MACHINE_ID/$KERNEL_VERSION/,
and then 20-grub.install that is installed by grub2-common.rpm wants to remove that
directory before 50-dracut.install get a chance to run. 50-dracut.install
checks for the presence of that directory to decide where to install the
kernel. So let's make the creation of the directory conditional. Previous
commit changes bootctl install to create $BOOT/$MACHINE_ID, and this commit
makes kernel-install not create it. In effect, the entry directory will only be
created if 'bootctl install' or something else created the parent directory.
kernel-install: rename $BOOT_DIR[_ABS] to $ENTRY_DIR[_ABS]
"BOOT" is misleading, because it sounds like this refers to /boot or $BOOT,
when in fact it refers to some subdirectory. Those variable names are purely
interal, so we can change them. $BOOT_DIR_ABS was used in NEWS, but it should
not be (because it is an internal detail), so the old NEWS entry is reworded to
use "entry directory".
This makes it easier to see what is going on. Documentation for
--verbose and --help is added to the man page. Our plugins are updated
to also log a bit.
meson: use a convenience library for the sources shared between core/ and the outside
This avoids double compilation. Those files are tiny, so it doesn't save time,
but we avoid repeated warnings and errors, and it's generally cleaner to it
this way.
The number of commands in 'ninja -C build clean && ninja -C build' drops from
1462 to 1455 for me.
pkgconfig: avoid double slash with split-usr configuration
By defining rootprefix= we avoid a double slash in $systemdsystemunitdir and
other variables. This fixes a regression introduced in 1c2c7c6cb3d92315624f3711114e86b0acfbce63 where the variables using rootprefix=/
would start with a double slash. This should be interpreted the same, but is
certainly ugly.
The rootprefix variable was added to systemd.pc in 1c2c7c6cb3d92315624f3711114e86b0acfbce63, so there is no question of backwards
compatiblity. If people try to "override" the prefix and specify
--define-variable=rootprefix=/, they will get a double slash, which should be
OK, and is the same as --define-variable=rootprefix=/something/, which also
results in a double slash somewhere in the strings.
systemctl: add support for booting into boot menu/entry
(This also removes support for booting into the EFI firmware setup
without logind. That's because otherwise the non-EFI fallback logind
implements can't work.)
logind: add support for booting into the boot menu or a specific boot menu entry
This behaves similar to the "boot into firmware" logic, and also allows
either direct EFI operation (which sd-boot supports and others might
support eventually too) or override through env var.
bootspec: get rid of find_default_boot_entry() entirely
Now only two operations are left. Let's just move this into the caller,
since it should make things simpler, clearer and shorter, in particular
as there's only a single user for this.
bootspec: introduce new helper boot_entries_load_config_auto()
It's a simple wrapper around boot_entries_load_config(), but determines
the ESP/XBOOTLDR paths automatically at first. Also, it looks for a path
/run/boot-loader-entries/ and loads the entries from there if it
exists. This is supposed to be a hook for other boot loaders to make our
tools aware of their own entries.
bootspec: move augmentation of loader-discovered entries into bootspec.c
Previously, bootctl would show boot loader entries discovered by the
boot loader which couldn't found locally separately in the output.
Let's move this code into bootspec.c, and beef it up a bit. This way we
can use it later on for logind, and correctly show automatically
discovered windows/macos entries too.
bootspec: move log msg from systemctl.c to bootspec.c
find_default_boot_entry() is only used by systemctl.c, and currently
handles one log message in the caller instead of the callee. Let's
simplify that and move it over, too
logind: optionally support non-EFI reboot-to-firmware
This extends the reboot-to-firmware logic in logind, so that other than
EFI firmwares could be theoretically support. The scheme is like this:
if you want to support this, set the $SYSTEMD_REBOOT_TO_FIRMWARE=1 env
var for logind. If so, this will override the EFI logic, and cause a
file /run/systemd/reboot-to-firmware file to be created when
reboot-to-firmware is requested. This file has no contents, it's mere
existance indicates a reboot with reboot-to-firmware set.
The idea is that for alternative firmwares a drop-in for logind is added
that sets the env var, in combination with some code run during shutdown
that checks for the file and does the right thing.
shutdown: rearrange shutdown sources in source tree
Let's move the shutdown binary into its own subdirectory in
src/shutdown, after all it is relatively isolated from the normal PID 1
sources, being a different binary and all.
Unfortunately it's not possible to move some of the code, since it is
shared with PID 1, that I wished we could move, but I still think it's
worth it.
Previously, RUN and SECLABEL keys are stored in udev_list with its unique
flag is false. If the flag is false, then udev_list is just a linked
list and new entries are always added in the last.
So, we should use OrderedHashmap instead of Hashmap.
resolved: when adding RR to an answer, avoid comparing keys twice
We'd call dns_resource_record_equal(), which calls dns_resource_key_equal()
internally, and then dns_resource_key_equal() a second time. Let's be
a bit smarter, and call dns_resource_key_equal() only once.
(before)
dns_resource_key_hash_func_count=514
dns_resource_key_compare_func_count=275
dns_resource_key_equal_count=62371
4.13s user 0.01s system 99% cpu 4.153 total
(after)
dns_resource_key_hash_func_count=514
dns_resource_key_compare_func_count=276
dns_resource_key_equal_count=31337
2.13s user 0.01s system 99% cpu 2.139 total
resolved: use a temporary Set to speed up dns question parsing
This doesn't necessarily make things faster, because we still spend more time
in dns_answer_add(), but it improves the compuational complexity of this part.
If we even make dns_resource_key_equal_faster, this will become worthwhile.
Same as with the other users, any non-trivial use of the objects requires
use from a single thread only or external locking. Using atomic operations
just for reference counts is not useful.
The sd-hwdb objects cannot be used concurrently from two threads in any
meaningful way, because query and iteration operations modify the object.
Thus atomic reference counts are pointless.
We had atomic counters, but all other operations were non-serialized. This
means that concurrent access to the bus object was only safe if _all_ threads
were doing read-only access. Even sending of messages from threads would not be
possible, because after sending of the message we usually want to remove it
from the send queue in the bus object, which would race. Let's just kill this.
btrfs: when falling back to plain copy when snapshoting exclude submounts
The subvol snapshot logic doesn't cover sub-mounts either, and it really
shouldn't in the general case, hence let's simply stop at submounts in
all cases, both in the main and in the fall-back codepath.
projects / thirdparty / systemd.git / log
