summaryrefslogtreecommitdiff
path: root/src/kernel-install
Commit message (Collapse)AuthorAgeFilesLines
* test/60-ukify: override stub location in testsZbigniew Jędrzejewski-Szmek2023-05-051-0/+2
| | | | Without this, build would fail if the stub is not available in /usr/lib/.
* test-kernel-install: test 60-ukify.install and 90-uki-copy.installZbigniew Jędrzejewski-Szmek2023-05-052-7/+33
| | | | | | 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: kernel-install plugin that calls ukify to create a UKIZbigniew Jędrzejewski-Szmek2023-05-052-2/+234
| | | | | | | | | | | | | 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.
* 90-loaderentry: make sure that variables are setZbigniew Jędrzejewski-Szmek2023-05-031-3/+3
| | | | | We unconditionally use the variables later on, so let's make sure that they were passed as expected.
* test-kernel-install: several cleanupsYu Watanabe2023-03-301-10/+15
| | | | | | | | - 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_GENERATORGertalitec2023-03-262-1/+7
| | | | 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
* kernel-install: check all entry candidates first, then check existence of ↵Yu Watanabe2023-03-171-8/+8
| | | | | | | | | | $pref/loader/entries only once 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 1b43f868934e971480249a6e0fa2f45da906ea2e.
* Revert "kernel-install: also try to find $BOOT by partition GUID"Yu Watanabe2023-03-171-20/+0
| | | | | | | | | | | This reverts commit 41f39e2144c935868059e894c1a1e13803e3568f. 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
* Merge pull request #26119 from kraxel/uki.installLuca Boccassi2023-03-082-4/+12
|\ | | | | kernel-install: improve uki handling
| * kernel-install: handle uki installs automaticallyGerd Hoffmann2023-03-071-2/+10
| | | | | | | | | | | | | | | | | | | | 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
| * 90-uki-copy.install: create $BOOT/EFI/Linux directory if neededGerd Hoffmann2023-03-071-2/+2
| | | | | | | | | | Do not consider a missing 'Linux' subdirectory an error. Just create it instead.
* | kernel-install: also try to find $BOOT by partition GUIDLuca Boccassi2023-03-031-0/+20
| | | | | | | | | | | | | | | | 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
* | kernel-install: use log_verbose everywhereLuca Boccassi2023-03-021-7/+4
|/
* boot: Make sure we take --root into account everywhere.Daan De Meyer2023-02-091-4/+7
|
* meson: Properly install 90-uki-copy.installJan Janssen2023-01-271-2/+5
|
* bootctl: unlink and cleanup functionsLudwig Nussel2023-01-192-1/+33
| | | | | | | | | | 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.
* kernel-install: refactor some variablesLudwig Nussel2023-01-101-10/+12
| | | | In preparation for plugin support
* kernel-install: run depmod only if writeableLudwig Nussel2023-01-051-0/+2
|
* kernel-install: Add uki layoutJoerg Behrmann2022-11-292-0/+99
| | | | | | | | | | | | | | 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.
* kernel-install: add header to generate entry filesZbigniew Jędrzejewski-Szmek2022-11-231-0/+2
| | | | | | | | | | | | | 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^)
* kernel-install: make 90-loadentry.install templatedZbigniew Jędrzejewski-Szmek2022-11-222-2/+10
| | | | | It's a bit annoying that this causes so much churn, but I don't see a different way to do this.
* Handle MACHINE_ID=uninitializedMarcus Schäfer2022-11-171-0/+1
| | | | | | | | | 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 (#25388)Marcus Schäfer2022-11-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | * 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.
* kernel-install: skip 50-depmod if depmod is not availableLuca Boccassi2022-11-071-0/+1
| | | | | | | Images might be built without any kernel module, and without installing depmod as it is not needed. Skip it. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023607
* kernel-install/90-loaderentry: do not override an existing systemd.machine_idAntonio Alvarez Feijoo2022-11-071-1/+1
| | | | | If the systemd.machine_id command line option is already set, do not override it.
* kernel-install/90-loaderentry: do not add multiple systemd.machine_id optionsAntonio Alvarez Feijoo2022-11-041-1/+1
| | | | | | | Do not unconditionally add a new systemd.machine_id command line option, first check if it already exists with the expected value. Fixes #25203
* kernel-install: do not fail if a plugin exits with 77Yu Watanabe2022-09-281-5/+4
|
* kernel-install: do not fail if $layout is not "bls"Yu Watanabe2022-09-281-2/+2
| | | | Fixes #24836.
* kernel-install/90-loaderentry: fix chownнаб2022-09-211-2/+2
|
* tree-wide: fix typoYu Watanabe2022-07-201-1/+1
|
* kernel-install: add helper for loggingZbigniew Jędrzejewski-Szmek2022-07-141-36/+30
|
* kernel-install: suppress bogus shellcheck hintZbigniew Jędrzejewski-Szmek2022-07-121-0/+1
| | | | | 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.
* kernel-install: use set -eZbigniew Jędrzejewski-Szmek2022-07-123-0/+6
| | | | | | 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.
* kernel-install: return 0 for unknown verbs in pluginsZbigniew Jędrzejewski-Szmek2022-07-122-1/+2
| | | | | | | | | | | 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.)
* kernel-install: raise fuss if plugins are called without the expected parametersZbigniew Jędrzejewski-Szmek2022-07-122-5/+5
|
* test-kernel-install: add a simple test that kernel-install copies the filesZbigniew Jędrzejewski-Szmek2022-07-122-1/+86
| | | | | | | | | | 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.
* kernel-install: mark the plugins as executable in gitZbigniew Jędrzejewski-Szmek2022-07-122-0/+0
| | | | | We mark them as executable during installation, but it's also nice to mark them as such in sources, so they can be executed directly.
* kernel-install: allow overriding the plugin list tooZbigniew Jędrzejewski-Szmek2022-07-121-10/+15
| | | | | The use of IFS=<newline> is dropped. Let's just iterate over the list, using any whitespace as separator.
* kernel-install/90-loaderentry: make ownership change optionalZbigniew Jędrzejewski-Szmek2022-07-061-2/+4
| | | | | This can be useful when running as non-root, e.g. for tests or when installing to a chroot.
* kernel-install: allow overriding the path to config filesZbigniew Jędrzejewski-Szmek2022-07-062-9/+19
| | | | | | 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.
* kernel-install: do not silently ignore files we can't readZbigniew Jędrzejewski-Szmek2022-07-062-11/+15
| | | | | | | | | '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.
* kernel-install: do not let config file override variablesZbigniew Jędrzejewski-Szmek2022-07-061-6/+21
| | | | | | This implementation is pretty ugly, but POSIX sh doesn't allow indirect variable expansion, so I couldn't figure out a way to make it less verbose.
* kernel-install: fix invocation as installkernelZbigniew Jędrzejewski-Szmek2022-07-061-1/+1
| | | | Fixes #23681.
* Use https for gnu.orgMichael Biebl2022-06-283-3/+3
|
* Merge pull request #23529 from nabijaczleweli/dollar-asteriskZbigniew Jędrzejewski-Szmek2022-05-301-14/+7
|\ | | | | Don't linebreak after each initrd in kernel-install verbose mode
| * kernel-install: don't log each initrd on its own line in verbose modeнаб2022-05-261-2/+2
| |
| * kernel-install: actually ignore the last two argumentsнаб2022-05-261-13/+6
| |
* | kernel-install: if a plugin fails, return error immediatelyZbigniew Jędrzejewski-Szmek2022-05-261-2/+2
|/ | | | | | | | | Since the first version in 81516adcb71a47837544340f72eb8ee810274119, 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-install: ignore extra args passed when invoked as installkernelZbigniew Jędrzejewski-Szmek2022-05-241-2/+13
| | | | | | | | | | | | | | | | | | | 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. 742561efbe938c45936f2e4f5d81b3ff6b352882 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.
* shellcheck-clean kernel-install againнаб2022-05-231-1/+4
|
View Lorry Controller Status