The unlink command removes an entry from the ESP including
referenced files that are not referenced in other entries. That is
useful eg to have multiple entries that use the same kernel with
different options.
The cleanup command removes all files that are not referenced by any
entry.
Currently the kernel-install man page only documents the bls layout for use
with the boot loader spec type #1. 90-loaderentry.install uses this layout to
generate loader entries and copy the kernel image and initrd to $BOOT.
This commit documents a second layout "uki" and adds 90-uki-copy.install,
which copies a UKI "uki.efi" from the staging area or any file with the .efi
extension given on the command line to
$BOOT/EFI/Linux/$ENTRY_TOKEN-$KERNEl_VERSION(+$TRIES).efi
This allows for both locally generated and distro-provided UKIs to be handled
by kernel-install.
I was looking at a bug in bugzilla about some boot loader issue, and it was
hard to say if the boot entry files were generated by our plugin or something
else. Add a header to make this clear.
kernel-install invokes the plugins via absolute path always, so $0 gives as
the full path the location where the plugin is installed. This is what we want:
title Fedora Linux 37 (Workstation Edition)
# Boot Loader Specification type#1 entry
# File created by /usr/lib/kernel/install.d/90-loaderentry.install (systemd 252-409-g5028904^)
systemd supports /etc/machine-id to be set to: uninitialized
In this case the expectation is that systemd creates a new
machine ID and replaces the value 'uninitialized' with the
effective machine id. In the scope of kernel-install we
should also enforce the creation of a new machine id in this
condition
* Fix reading /etc/machine-id in kernel-install
The kernel-install script has code to read the contents of
/etc/machine-id into the MACHINE_ID variable. Depending
on the variable content kernel-install either logs the
value or creates a new machine id via 'systemd-id128 new'.
In that logic there is one issue. If the file /etc/machine-id
exists but is empty, the script tries to call read on an
empty file which return with an exit code != 0. As the
script code also uses 'set -e', kernel-install will exit at
this point which is unexpected.
The condition of an empty /etc/machine-id file exists for
example when building OS images, which should initialize the
system id on first boot but not staticly inside of the image.
afaik an empty /etc/machine-id is also a common approach
to make systemd indicate that it should create a new system
id. Because of this, the commit makes sure the reading of
/etc/machine-id does not fail in any case such that the
handling of the MACHINE_ID variable takes place.
I don't quite understand this, but '{ ! true; }' is not the same as '( ! true )'.
In interactive mode, it seems to work as expected. But in a script, it doesn't.
This means that we'll fail hard if something goes wrong, e.g. reading
of a config file. I think this is appropriate. If errors should be ignored,
the caller should do that on their end.
In practice this makes little difference, because kernel-install will
only call the plugins for 'add' or 'remove', and if we were to add a
new verb to kernel-install, we'd just change the plugins at the same
time. But our plugins serve as documentation for external plugins too,
and there it's better to silently ignore unknown verbs so that we can
add new verbs in the future.
(50-depomod.install was already like that.)
I opted to tweaking kernel-install to allow overriding config
(with $KERNEL_INSTALL_CONF_ROOT, $KERNEL_INSTALL_PLUGINS). An alternative
would be to build a test environment in test/. We can still do that,
but I think it's nice to have a simple test that is very quick and easy
to debug.
Invocation as installkernel is for #23681.
It's pretty hard to write tests without this. I started out by adding separate
variables for each of the files we read, but there's a bunch, and in practice
it's good enough to just override the directory.
'test -r' is changed to 'test -f' everywhere. If the file exists but we
cannot read it, it would be better if we fail with a permission error. E.g. if
/etc/kernel/cmdline is unreadable, and we're running something as non-root, we
shouldn't fall back to /usr/lib/kernel/cmdline. This commit doesn't resolve
this fully, because we're not running with 'set -e', but this is a preparator
step.
Since the first version in 81516adcb7,
kernel-install would "gather" a return value by summing the exit codes
of the plugins… This makes no sense, because those are not additive values.
Let's just break off immediately. We now implement cleanup via trap, so if we
break, we should leave no garbage behind.
kernel's 'make install' invokes install.sh which calls /sbin/install-kernel.
Thus we are invoked as e.g.
/sbin/installkernel 5.18.0 arch/x86/boot/bzImage System.map /boot
The last two arguments would be passed as "initrds".
Before , we would just quitely ignore
/boot, because it doesn't pass the 'test -f' test, and possibly try to do
something with System.map. 742561efbe tightened
the check, so we now throw an error.
It seems that the correct thing is to ignore those two arguments, because
our plugin syntax has no notion of System.map. And the installation directory
we can figure out ourselves better. Effectively, this makes things behave
like before, but less by accident.
Fixes#23490.
Before 9e82a74cb0, we had a check like the
following:
if [[ -d /efi/loader/entries ]] || [[ -d /efi/$MACHINE_ID ]]; then
ENTRY_DIR_ABS="/efi/$MACHINE_ID/$KERNEL_VERSION"
elif [[ -d /boot/loader/entries ]] || [[ -d /boot/$MACHINE_ID ]]; then
ENTRY_DIR_ABS="/boot/$MACHINE_ID/$KERNEL_VERSION"
elif [[ -d /boot/efi/loader/entries ]] || [[ -d /boot/efi/$MACHINE_ID ]]; then
ENTRY_DIR_ABS="/boot/efi/$MACHINE_ID/$KERNEL_VERSION"
…
In stock Fedora 34-, /efi isn't used, but grub creates /boot/loader/entries and
installs kernels and initrds directly in /boot. Thus the second arm of the
check wins, and we end up with BOOT_ROOT=/boot.
After 9e82a74cb0, we iterate over the inner
directory first and over the second directory later:
[ -d /efi/<machine-id> ]
[ -d /boot/efi/<machine-id> ]
[ -d /boot/<machine-id> ]
[ -d /efi/Default ]
[ -d /boot/efi/Default ]
[ -d /boot/Default ]
[ -d /efi/loader/entries ]
[ -d /boot/efi/loader/entries ]
[ -d /boot/loader/entries ]
This was partially reverted by 447a822f8e which
removed Default from the list, and a5307e173b,
which moved checks for /boot up, so we ended up with:
[ -d /efi/<machine-id> ]
[ -d /boot/<machine-id> ]
[ -d /boot/efi/<machine-id> ]
[ -d /efi/loader/entries ]
[ -d /boot/loader/entries ]
[ -d /boot/efi/loader/entries ]
6637cf9db6 added autodetection of an entry
token, so we end up checking the following suffixes:
<machine-id>, $IMAGE_ID, $ID, Default
But the important unchanged characteristic is that we iterate over the suffix
first. Sadly this breaks Fedora, because we find /boot/efi/<machine-id> before
we could find /boot/loader/entries. It seems that every possible aspect of
behaviour matters for somebody, so we need to keep the original order of
detection.
With the patch:
[ -d /efi/<machine-id> ]
...
[ -d /efi/loader/entries ]
[ -d /boot/<machine-id> ]
...
[ -d /boot/loader/entries ]
[ -d /boot/efi/<machine-id> ]
...
[ -d /boot/efi/loader/entries ]
Note that we need to check for "loader/entries" too, even though it is not
an entry-token candidate, so that we get the same detection priority as
before.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2071034.
If $BOOT_ROOT is specified, but entry-token not, we'd skip the detection
altogether, effectively defaulting to entry-token=machine-id.
The case where $BOOT_ROOT was not specied, but entry-token was configured
was handled correctly.
This patch makes the handling of both symmetrical, i.e. will only set what
wasn't configured.
No changes to behaviour, but let's print everything out as we discover it.
The docs say that BOOT_ROOT can be specified by the environment. I have
it locally in /etc/kernel/install.conf, and then the override doesn't work.
It'd be nice to handle such cases more reliably.
In --help output, change "$0" → "kernel-install". We generally don't include
the full path in --help output, and let's not do this here either.
kernel-install is now in build/ directly, not in the subdirectory.
