Brett T. Warden
4e0345e9f4
We check for a microcode update initrd, so we can early-load it, by comparing the resolved file names to the ending "-ucode.cpio". In the case that a user has explicitly masked an initrd by symlinking a name in /etc/kernel/initrd.d/ to /dev/null, we store NULL in the resolved filename pointer. Before we do the actual comparison, we do a strlen to make sure the filename is longer than the desired match. For a NULL pointer, that results in a segfault, so for that case, explicitly code the length to 0 instead of calling strlen on it. Signature: [277506.631610] clr-boot-manage[2369580]: segfault at 0 ip 0000558974796218 sp 00007ffca90d9658 error 4 cpu 18 in libc-2.40.so[196218,558974628000+184000] likely on CPU 18 (core 8, socket 0) [277506.631627] Code: 0f 84 5e fd ff ff 48 89 f8 0f bc c9 f3 a4 c3 0f 1f 00 89 f8 62 a1 fd 00 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 28 01 00 00 <62> f1 7d 20 74 07 c5 fb 93 c0 85 c0 74 1a 0f bc c0 c3 66 0f 1f 44 $ sudo CBM_DEBUG=1 clr-boot-manager update [DEBUG] cbm (../src/cli/cli.c:L142): No such file: //etc/kernel/update_efi_vars [INFO] cbm (../src/bootman/bootman.c:L788): Current running kernel: 6.10.12-1467.native [INFO] cbm (../src/bootman/sysconfig.c:L179): Discovered UEFI ESP: /dev/disk/by-partuuid/cb7f514a-2dd7-445d-9dec-2d5d105c6eee [INFO] cbm (../src/bootman/sysconfig.c:L256): Fully resolved boot device: /dev/sda1 [DEBUG] cbm (../src/bootman/bootman.c:L141): shim-systemd caps: 0x26, wanted: 0x26 [DEBUG] cbm (../src/bootman/bootman.c:L156): UEFI boot now selected (shim-systemd) [DEBUG] cbm (../src/bootman/bootman.c:L829): Non regular file: ///etc/kernel/initrd.d/.., skipping. Segmentation fault (gdb) bt #0 0x0000555555396218 in __strlen_evex () from /usr/lib64/libc.so.6 #1 0x000055555555b9cc in _boot_manager_enumerate_initrds_freestanding () at ../src/bootman/bootman.c:889 #2 0x000055555555d570 in boot_manager_enumerate_initrds_freestanding () at ../src/bootman/bootman.c:918 #3 0x000055555555b170 in cbm_command_update_do () at ../src/cli/ops/update.c:82 #4 0x000055555555b2ac in cbm_command_update () at ../src/cli/ops/update.c:44 #5 0x000055555555990b in main () at ../src/cli/main.c:296
clr-boot-manager
clr-boot-manager exists to enable the correct maintenance of vendor kernels and appropriate garbage collection tactics over the course of upgrades. The implementation provides the means to enable correct cohabitation on a shared boot directory, such as the EFI System Partition for UEFI-booting operating systems.
Special care is taken to ensure the boot partition is handled gracefully, and in the instance that it is not already mounted, then clr-boot-manager will automatically discover and mount it, and automatically unmount the boot partition again when it is complete.
Most importantly, clr-boot-manager provides a simple mechanism to provide kernel updates, with the ability for users to rollback to an older kernel should the new update be problematic. This is achieved through the use of strict namespace policies, permanent source paths, and clr-boot-manager's own internal logic, without the need for "meta packages" or undue complexity on the distribution side.
Requirements
clr-boot-manager is primarily designed to install the bootloader, kernel, initrd and accompanying metadata files for GPT disks using UEFI, however it does contain fallback support for legacy bootloaders such as GRUB2 to allow all users to benefit from automated kernel management when MBR partition tables are used.
clr-boot-manager should be the only tool responsible within the OS for generating boot entries, and will automatically incorporate the correct root= portions.
Kernel Integration
The way that a kernel is packaged changes significantly with clr-boot-manager. First and foremost, no files shall be shipped in /boot. The distribution should choose a namespace to identify their system in dual-boot situations, i.e:
org.someproject
All paths known to CBM must have follow a specific format and encoding, whereby the version, release number, and type are encoded:
/usr/lib/kernel
-> config-4.9.17-9.lts
-> org.someproject.lts.4.9.17-9
-> System.map-4.9.17-9.lts
-> cmdline-4.9.17-9.lts
-> initrd-org.someproject.lts.4.9.17-9 (Optional)
/usr/src/linux-headers-4.9.17-9.lts
/usr/lib/modules/4.9.17-9.lts
The directories can be altered via the ./configure options. See ./configure --help for further details.
Additionally, each kernel shall be compiled with the versioning information built in, which can be achieved by doing something similar to this in the build spec:
extraVersion="-${release}.lts"
sed -e "s/EXTRAVERSION =.*/EXTRAVERSION = $extraVersion/" -i Makefile
This results in an easily identifiable uname which CBM can use to manage kernels:
$ uname -a
Linux some-host 4.9.17-9.lts #1 SMP Wed Mar 22 16:02:52 UTC 2017 x86_64 GNU/Linux
The initrd file should be shipped with the kernel package itself, built for a generic target. This minimises the errors that can happen when having a non reproducible command. Users may override the initrd by providing the same filename within /etc/kernel.
All of the above paths should be marked as resident/permanent in the software deployment mechanism as they will be automatically destroyed when clr-boot-manager performs the garbage collection cycle. Note that each "type" of kernel is up to the distribution to define, however it should be alphabetical only with no dots or hyphens.
The next "default" kernel (i.e. tip for a given series) is defined with the symlink-$(type) notation, and allows clr-boot-manager to know that a kernel is not yet up to date. No version comparison is performed, ensuring that the symlink is always the source of information:
/usr/lib/kernel/default-lts: symbolic link to org.someproject.lts.4.9.17-9
The "post install" step for a kernel shall call clr-boot-manager update to push the new configuration & updates to disk. This can be called multiple times, as clr-boot-manager will only update exactly what needs to be updated, saving unnecessary writes to the ESP or /boot partition.
Supported Filesystems/Partition Table
The clr-boot-manager supports the following filesystems combination:
| UEFI | Filesystem | Backend |
|---|---|---|
| no | ext[2-4] | extlinux |
| no | vfat | syslinux |
| yes | vfat | systemd-boot |
License
LGPL-2.1
Copyright © 2016-2020 Intel Corporation