Skip to content
Kernel & Boot Loader Management
C Shell Meson C++ Other
Branch: master
Clone or download
dorileo cli: add flags to the usage output
Add usage info wherever the flags -p and -i are relevant.

Signed-off-by: Leandro Dorileo <>
Latest commit dd2e383 Oct 8, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
docker Update copyright year Nov 20, 2018
man Correct man page's vendor kernel configuration directory Jan 17, 2019
src cli: add flags to the usage output Nov 1, 2019
tests bootman: improve filesystem detection Sep 17, 2019
.clang-format Add clang-format files May 25, 2016
.gitignore Convert build system to meson Nov 1, 2017
.gitmodules Update gitmodules to point to the correct libnica origin Nov 17, 2017
.travis.yml clr-boot-manager: update meson and ninja Mar 27, 2018
LICENSE.LGPL2.1 Initial commit Mar 16, 2016 readme: add filesystem support table Nov 1, 2019
VERSION v3.2.0 release Sep 18, 2019 Update copyright year Nov 20, 2018 Initial commit Mar 16, 2016 efi: add a entry_label argument Oct 5, 2019
meson_options.txt efi: add a entry_label argument Oct 5, 2019
sgcheck.suppressions Initial commit Mar 16, 2016 update_format: Never modify libnica files Jan 11, 2017


Build Status

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.


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:


All paths known to CBM must have follow a specific format and encoding, whereby the version, release number, and type are encoded:

 -> config-4.9.17-9.lts
 -> org.someproject.lts.4.9.17-9
 -> cmdline-4.9.17-9.lts
 -> initrd-org.someproject.lts.4.9.17-9 (Optional)

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:

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



Copyright © 2016-2018 Intel Corporation

You can’t perform that action at this time.