Like the cmdline file we look for a devicetree file in
$KERNEL_INSTALL_CONF_ROOT, /etc/kernel and /usr/lib/kernel. If it is
present we look for the specified device tree that comes with the kernel
we're adding and install it into $ENTRY_DIR_ABS and add a devicetree
stanza to the loader entry.
Unfortunately it seems there is no common consensus on where to install
device tree blobs, so we have to look in a few different places for it.
60-ukify.install would only work with initrd provided by command line
arguements. Fixed to look for both microcode and initrd is found in
$KERNEL_INSTALL_STAGING_AREA which is placed by initrd generator like
mkinitcpio
The shell script version of kernel-install silently ignored unexpected
arguments, but C version refused that. Unfortunately, Fedora's kernel
script specifies kernel file even for 'remove' command. Let's accept
extra arguments and silently ignore them to keep backward compatibility.
Fixes#28448.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2223794.
kernel-install used to work without /proc mounted before the rewrite
in C. Let's restore that property by making sure we don't reopen
file descriptors via /proc. In this case, parse_env_file_fdv() calls
fdopen_independent() to get a FILE * for the given file descriptor
(which itself calls fd_reopen()). Let's avoid the call to
fdopen_independent() by using chase_and_fopenat_unlocked() which
gives us a FILE * immediately without having to reopen any file
descriptors.
We do not provide any way to override /etc/machine-info.
As the file is deprecated in kernel-install, let's skip to read it when
we test kernel-install.
Fixes#28011.
This simplifies the logic: finalize_options() is the step that does the
checks and the mangling. The checks for consistency are done in more places,
so we need to pass a verb (we only have 'build', but once we add other verbs,
any would do).
This is mostly a one-to-one translation of kernel-install.sh, except for
the followings:
- BOOT_ROOT is searched with find_{esp,xbootldr}_and_warn().
- entry token is searched with boot_entry_token_ensure().
- inspect command verboses more information, e.g. found plugins,
environment variables explicitly passed to plugins, arguments passed
to plugins.
- paths specified in $KERNEL_INSTALL_PLUGINS must be absolute.
- LC_COLLATE is set to C.UTF-8 (or any specified on build time).
By writing kernel-install C, we can share the code used by bootctl or
so, and can introduce --root and/or --image options later.
We install a kernel with layout=uki and uki_generator=ukify, and test
that a UKI gets installed in the expected place. The two plugins cooperate,
so it's easiest to test them together.
60-ukify.install calls ukify with a config file, so singing and policies and
splash will be done through the ukify config file, without 60-ukify.install
knowing anything directly.
In meson.py, the variable for loaderentry.install.in is used just once, let's
drop it. (I guess this approach was copied from kernel_install_in, which is
used in another file.)
The general idea is based on cvlc12's #27119, but now in Python instead of
bash.
- allow to run without $PROJECT_BUILD_ROOT,
- drop unnecessary export for bootctl,
- enable -x option to show commands,
- use 'test ! -e' to check the nonexistence of files,
- show more debugging logs.
Define $KERNEL_INSTALL_UKI_GENERATOR in case one wants it to be different from $KERNEL_INSTALL_INITRD_GENERATOR. This can be useful if one wants to use mkinitcpio / Dracut to generate the initrd, but without creating the UKI so this can be left for e.g. ukify or something else. Right now these initrd generators will read /etc/kernel/install.conf and generate the UKI
If we have multiple entries in $ENTRY_TOKEN_SEARCH, and $pref/loader/entries
exists, then previously we would always exit after the first candidate and
ignore the second and later candidates.
Follow-up for 1b43f86893.
This reverts commit 41f39e2144.
From the post merge comment in #26648:
> Hmm, this is highly problematic, no? if I boot from my ssd and then
> plug in a fedora live usb stick, then there will be two ESPs around,
> the one from my ssd and the one from the live usb one, and this code
> might find the wrong one and bad things will happen
Detect image type using "bootctl kernel-identify $kernel",
store result in KERNEL_INSTALL_IMAGE_TYPE.
Extend layout autodetection to check the kernel image type
and pick layout=uki for UKIs.
Resolves: #25822
When there is nothing set up on /boot, /boot/efi or /efi, try to find the
$BOOT partition checking for the XBOOTLDR or ESP partition GUIDs.
Prefer XBOOTLDR as per BLS.
Fixes https://github.com/systemd/systemd/issues/26644
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^)
