clearlinux / clr-boot-manager

Kernel & Boot Loader Management

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

clr-boot-manager's Issues

Cleanup vmlinux files when linux-dev was installed

Bundle linux-dev pulls in linux-extras, which includes a vmlinux file in /usr/lib/kernel. This file is not cleaned up when an old kernel is removed. It should likely follow the same cleanup logic as System.map-, config-, etc.

Typo in error message when kernel files are missing

After swupd deleted my current kernel's files from /usr/lib/kernel, cbm emitted this error message, with typo:

[ERROR] cbm (src/bootman/update.c:L270): Cannot dermine the currently running kernel

clr-boot-manager/src/bootman/update.c

Line 270 in 9bdd68d

LOG_ERROR("Cannot dermine the currently running kernel");

Track boot status

Curating /boot kernel files requires knowing of potentially 3 kernels:

• Latest OS-provided kernel for the given type, i.e. $kerneldir/default-$type
• Currently running kernel
• The last known booting kernel

To track the last known booted kernel we must track this with a kbooted-$short file to allow mapping this to the kernel availability set, to exclude it from removals.

This can simply be achieved by adding a systemd unit and a tiny binary to run on boot.

Finalize cbm-next with kernel update policy

We've changed the policy to always attempt kernel installation.
To close off this release we need to ensure to only update things when they change, including:

• syslinux cfg
• systemd-class *.conf and loader.conf files
• kernel blob itself

Type Analysis Inflexible

Currently we enum the kernel types which limits future expansion.

Instead, we should simply group by type into an NcHashmap of NcArray,
and then enable garbage collection through each series, vs a total set.

Running kernel detection can fail

Sometimes the running kernel detection can fail, resulting in a chain of errors.
The running kernel should never be removed:

Running kernel: : 4.6.3-238.native

/usr/lib/kernel post update:

cmdline-4.6.3-235.native  config-4.6.3-244.native
cmdline-4.6.3-239.native  default-native (-> org.clearlinux.native.4.6.3-244)
cmdline-4.6.3-242.native  install.d
cmdline-4.6.3-244.native  org.clearlinux.native.4.6.3-235
config-4.6.3-235.native   org.clearlinux.native.4.6.3-239
config-4.6.3-239.native   org.clearlinux.native.4.6.3-242
config-4.6.3-242.native   org.clearlinux.native.4.6.3-244

ESP (curated list showing only CBM specifics)

/boot
|-- EFI
|   |-- Boot
|   |   |-- BOOTX64.EFI
|   `-- systemd
|       |-- systemd-bootx64.efi
|-- loader
|   |-- entries
|   |   |-- Clear-linux-native-4.6.0-221.conf~
|   |   |-- Clear-linux-native-4.6.2-232.conf~
|   |   `-- Clear-linux-native-4.6.3-238.conf
|   |-- loader.conf
|   `-- loader.conf~
`-- org.clearlinux.native.4.6.3-238

It would appear CBM failed to perform any appropriate actions

cannot see or set kernel using LegacyBIOS

Hi,

I have been using LegacyBIOS with the kvm-kernel and noticed that clr-boot-manager

• does not indicate which listed kernel is selected (missing asterisk)
• throws an error when I attempt to update

Perhaps this is fixed in #129 but wanted to file just in case. I assume legacyBIOS is the problem because clr-boot-manager works for me in instances where its not enabled.

GRUB2 ordering is unreliable

On certain systems we're seeing GRUB2 menus default to selecting index 0.
On a system with an existing kernel and an upgrade, an unattended reboot leads to booting the old
kernel.

In terms of usability, for some users they may never end up on the new kernel without explicitly selecting it.
Thus, we should alter GRUB2 to emit a single /etc/grub.d file, nuke old files, and use submenus for the "alternative boot entries".

This ensures that our default kernel, idx 0, is always selected first, and we stuff older/other entries under a different submenu structure.

Codewise, we'll make the GRUB2 implementation similar to the syslinux implementation.

Hugely increase mocking of tests

TL;DR Get coverage up to 85%

Implement full syslinux support

syslinux support is to be used to enable MBR/BIOS loading in clr-boot-manager

Subtasks:

• Move to a set_kernels API called to enable extlinux config writing
• Add functions to pull lead 440 bytes for hash comparison from GPT disk
• Stick it all together and support syslinux..
• Add unit tests for all the above

Support to create images bootable via SBL

Intel is providing the Slim Bootloader as a fast and lightweight open-source reference boot loader. This is commonly used in IOT devices like e.g. infotainment systems in the car.
I would like to see the clr-installer directly supporting the creation of images that are bootable via SBL.

Does not work on Btrfs

Running clr-boot-manager in Solus installed on a Btrfs filesystem results in the following:

# CBM_DEBUG=1 clr-boot-manager update
[INFO] cbm (src/bootman/bootman.c:L437): Current running kernel: 4.9.18-10.lts
[ERROR] cbm (src/lib/files.c:L164): Invalid block device: /
[ERROR] cbm (src/lib/system_stub.c:L30): Invalid block device: 0:34
Out of memory[DEBUG] cbm (src/bootman/bootman.c:L124): UEFI boot now selected (goofiboot)
[INFO] cbm (src/bootman/update.c:L75): Checking for mounted boot dir
[INFO] cbm (src/bootman/update.c:L78): boot_dir is already mounted: /boot
[DEBUG] cbm (src/bootman/update.c:L237): Now beginning update_native
[DEBUG] cbm (src/bootman/update.c:L246): update_native: 1 available kernels
[DEBUG] cbm (src/bootman/update.c:L266): update_native: Running kernel is (lts) ///usr/lib/kernel/com.solus-project.lts.4.9.18-10
[FATAL] cbm (src/bootman/sysconfig.c:L126): sysconfig insane: Missing root device
[FATAL] cbm (src/bootman/update.c:L455): Failed to update bootloader

Notes:

• It doesn't matter if the / filesystem is in the top-level subvolume (subvol=/) or another subvolume (eg: subvol=solus).
• The block device 0:34 doesn't exist.

Enable general-purpose usage of clr-boot-manager

For usage outside of the cut-and-dry UEFI + basic rootfs, clr-boot-manager requires far more support in the core. Additionally, the support required makes the project reusable in other projects too.

• Remove hard-coding of Clear Linux names and paths
• Support os-release files for OS information
• Support initial ramdisk configurations
• Support automatic LVM on LUKS detection for encrypted rootfs (limited to dracut at present)
• Support configuration of the bootloader timeout
• Support configuration of kernel cmdline (/etc/kernel/cmdline and /etc/kernel/cmdline.d/*.conf)
• Add extended testing for very high code coverage
• Support GRUB2 bootloader

This issue supersedes issue #25

Abstract the UEFI vs BIOS code up a bit

Right now we're relying on interleaving of functions for differing operations.
ESP is always a case of /boot != /, whereas BIOS means /boot ~= /,
changing the concept of can_mount to should_mount and never_mount.

As such we need to rework set_prefix to initially inspect devices along the parent tree,
and build a strategy for going forward.

[FATAL] cbm: (../src/bootman/update.c:L471): Failed to install bootloader

Environment: Bare metal installation of Clear
Last working Clear Linux version: 23690
Current Clear Linux version installed: 23950

Trying to set timeout for systemd-boot menu and perform clr-boot-manager update.

$ sudo clr-boot-manager update
[FATAL] cbm: (../src/lib/bootvar.c:L411): efi_generate_file_device_path_from_esp() failed: Function not implemented
[FATAL] cbm: (../src/lib/bootvar.c:L411): efi_generate_file_device_path_from_esp() failed: Function not implemented
[FATAL] cbm: (../src/bootloader/shim-systemd.c:L283): Cannot create EFI variable (boot entry)
[FATAL] cbm: (../src/bootman/update.c:L471): Failed to install bootloader

The timeout is set by system did not receive the update hence the boot menu does not show up when system reboot.

Only use PartUUID on a GPT rootfs

Scenario:

• UEFI system
• GPT disk contains ESP
• MBR disk contains /

Problem:

• cbm detects PartUUID & UUID for GPT converted to MBR
• cbm writes root=PARTUUID= with an unsupported PartUUID

Currently, if we find an ESP, we niavely assume GPT. The probe code must be modified to determine if the root device is GPT or not. If it is GPT, we should write the PartUUID, otherwise free and NULL the PartUUID and write only the UUID.

Support chroot rescue

clr-boot-manager should be able to rescue a bricked install by rebuilding the ESP content,
and repopulating with the bootloader files, etc.

Multiple Kernel Versions at Goofiboot

With the update of the clr-boot-manager, the goofiboot is now showing multiple kernel versions as possible boot options. I have ran the clr-boot-manager report-booted and update but the current and previous options remain. I would like to remove the previous option and old kernel data stored but cannot find information on how to do so under the manpages for clr-boot-manager. Suggestions?

Check missing files on initialisation

Right now updates can seemingly go without issue due to missing required files

Unclear Requirements in Readme.md

From Readme.md

clr-boot-manager is primarily designed 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.

for me this reads like clr-boot-manager can be the bootloader on GPT disks using UEFI and for legacy (BIOS, MBR, ...) GRUB2 can be configured. But the post on Reddit indicates that clr-boot-manager is no bootloader itself but is a manager ('orchestration layer') that uses bootloaders

Remove old kernel modules

Currently (at least on Solus), the old kernel modules are left in /lib/modules. After a year, the disk usage of this folder is 5.6Gb on my machine.
It would be nice to foresee a mechanism in clr-boot-manager to purge the old kernel modules.

Improving testing for cleanups of the /usr/lib/kernel and /usr/lib/modules directories

Currently tests for uninstallation only look at the EFI dir, improve tests to account for the rootfs as well.

FTB with `-Wl,--as-needed`

Linking issues when using -Wl,--as-needed or equivalent.

Resolve immediately

wanted features

Main ticket items:

• Support full XDG bootloader specification (machine-id version fields, etc)
• Further refine ESP namespacing by encoding the machine-id into the filenames too
• Add migration paths and testing for this
• Drop $ESP/$bootloader compatibility paths from tools like bootctl
• Instead use $ESP/EFI/$NEEDLE/bootloader$SUBARCH.efi, i.e. \EFI\org.clearlinux\bootloaderx64.efi
• Add EFI variable management and a register subcommand for installers to register the bootloader
• Untie CBM from a specific bootloader implementation through fixed, managed paths

Cleanup kernels in target which don't have a source

Make another cleanup step in clr-boot-manager which will look at all the names in the target and try to find those files' matching sources. If the matching sources of those files do not exist and the kernel isn't being used (either as default or as a fallback), then cleanup all the target files.

Sets Clear Linux as the only bootable OS

Copied from clearlinux/distribution#142

I do have several distributions in my system, and all boot through EFI, now ClearLinux thinks, it is the only OS to be in the system and fiddle with the boot section.

Do not write or mess with the boot section...at least ask the end user, that you want to update it or want to do it in a proper way??

Sound naive?? Sound stupid?? can't help. That is what bugs me. I tried to bypass it and it is still bugging.

I am sure, I am certainly missing some arcane details to get on.

Revert monolithic architecture

We need to enable tests for every single operation, the tool should hook into library code and set context, it should not be performing the logic itself

clr-boot-manager can't remove entries like intel_iommu=igfx_off

The default clear linux boot options has intel_iommu=igfx_off which can't be overridden with intel_iommu=on. Using the standard method of placing a conf file in /etc/kernel/cmdline.d and running clr-boot-manager update to add the intel_iommu=on setting does add the setting but that setting does not override the igfx_off setting. Therefore clr-boot-manager needs a way to remove kernel entries and/or overwrite them.

Need to integrate firmware capsule updates

In Solus we're trying to ensure all aspects of the users system is up to date, to that extent we:

• Early-load microcode updates for the CPU
• Ship recent firmware and kernels
• Provide rolling stack updates for critical software

However we currently DO NOT have firmware updates. clr-boot-manager is the obvious integration
point in the deployment chain, and should be able to manage fwupd or similar to enable the deployment
of FW capsule updates for our UEFI users.

It also makes sense to integrate the points here as CBM is responsible for boot items, and could easily change the "NextBoot" to ensure we reboot to the firmware update screen.

..Discuss? :)

Retain `loader.conf` settings

It should be possible to retain settings other than default and timeout in the loader.conf. Specifically, the 4 following options should be retained at all times:

• editor
• auto-entries
• auto-firmware
• console-mode

right now these are wiped every time clr-boot-manager runs.

Enhance the system detection for chroots

Scenario:

• chrooting into a new rootfs
• System was installed as a UEFI system
• Booting from a temporary ESP in the eltorito alt boot section of an ISO.

Problem:

• get_boot_device fails to determine the ESP. Assumes LEGACY capability
• Selects the grub2 bootloader instead of a systemd-class bootloader

Solution:

• In image mode, assume !legacy && gpt == uefi
• In "native" mode, query presence of /sys/firmware/efi to weight the decision by adding the UEFI capability in bootloader selection.
• NULL boot device is OK. Assuming chroot situation, we expect to find that /boot is mounted within the environment and will skip mounting it.

Testing:

• Assert we can reliably detect UEFI configurations when unable to get_boot_device, on both MBR and GPT rootfs (see issue #53)

Would like ability install Clear through KVM-over-IP

Would like an installer that can work on IP-based KVMs.

Add detection of legacy BIOS partition

A small refactor will be needed inside the bootman implementation to enable the detection of either a Legacy BIOS boot partition or the EFI System Partition.

Consequently scope is locked to GPT disks only.

Make module check during update non-fatal

When running an update, if the kernel being installed does not have a corresponding module directory the update is aborted. In some cases modules may not be needed nor present so this behavior limits valid use cases.

Cleanup obsolete kernel build support directories

Kernel build support directories will be created with paths matching /usr/src/linux-$(uname -r), if the linux-dev pundle is installed. They should be removed when the corresponding kernels are removed.

Legacy codepath detected in UEFI system

Currently we probe for get_legacy_boot_device first, however..
A report shows that a system with BOTH a legacy boot device, and an ESP, will fail to take the appropriate action for the UEFI booted system.

Proposed change:

• If we determine we have a legacy boot device, NULL this if we then determine we're in !self->image_mode and host UEFI is available.

Format of cmdline.d/*.conf should be specified

clr-boot-manager/man/clr-boot-manager.1.in

Line 101 in 50cc4ea

\fB@KERNEL_CONF_DIRECTORY@/cmdline.d/*.conf\fR

We should specify that the contents of any cmdline.d/*.conf must be simple text to be appended directly to the kernel command line.

We should also mention that contents from /usr/lib/kernel/cmdline* and /usr/lib/kernel/cmdline.d/*.conf are used in generation of the command line.

Feature request: enable selection of kernels in next boot on command line

I am a Solus user which uses clr-boot-manager for boot management. The user is expected to select the linux kernel to boot up during start up by spamming the space key (on UEFI hardware).

I have a laptop with UEFI setup. However, I cannot select the boot kernels by the above approach. My problem is that, the laptop becomes unresponsive once I hit the space key during startup and enter the page for selection of kernels. I can see which kernels are available but I cannot select any of them. Even worse, the laptop would freeze there with no response to any keystroke. It boots fine if I let it boot regularly to the log in page.

Because of this issue, I cannot switch the kernels on this laptop. I am proposing to add a command line option to clr-boot-manager so that I can choose what kernel to use in the next bootup. If it works fine, then I still can use clr-boot-manager report-booted to keep this option. Otherwise the option would not be saved and in future startups the machine will use the original kernel it used. In addition, there can an option to list all available kernels.

One example of such a feature could be:

clr-boot-manager list-kernels -- list all kernels installed on the machine
clr-boot-manager select-kernel XXX -- select a kernel for next boot

Add a symlink for the current initrd?

Relevant: https://solus-project.com/forums/viewtopic.php?f=4&t=7211&start=20#p21727

Just a symlink to the current initrd, just like it exists for default-lts.

Possible?

Thanks.

Not seeing strafe rgb

I recently installed Solus Linux. Their software center has CKB-Next in it. The program itself runs just fine, but for some reason it is not seeing my strafe rgb. I can only see the program settings in which it says: "No devices connected".

add a "clean all" command

To delete every kernel that not the one being used (or not the default of a given type).

Add missing compat .sh launchers

Enable easier transition through format bump by providing .sh shims

EFI data installs to non-EFI partition mounted at /boot

If the system being updated has /boot mounted as a non EFI partition and clr-boot-manager is configured for an EFI bootloader, /boot will still be populated with EFI content.

Likely need to try and find an EFI partition or just not install content. @ikeydoherty Any thoughts on this?

Enhance ESP detection

Currently ESP detection is based on the freedesktop bootloader specification.

In order to facilitate #11 we need to have advanced detection for cases in which we didn't use the
same ESP. As such we should enumerate partitions on the same parent disk as the root (/) partition, and find the ESP there. This will emulate the same functionality as get_legacy_boot_device

Scope Solus support

Solus requires a solid promise in terms of kernel updates.

..CBM.

Currently we employ two bootloaders, depending on UEFI availability:

• GRUB2 (MBR/BIOS)
• goofiboot (UEFI, already implemented in CBM)

In addition, we boot with an initramfs, as Solus has to support mad setups like LVM2/encryption (thankfully handled by the internal initramfs cruft, dracut)

Ideally Solus will be switching to CBM before the next ISO snapshot, making use of the namespace feature in CBM.

N.B: "systemd-class" UEFI, and use of GRUB, are common on many distros in conjunction with an initramfs. It would seem that in implementing this for Solus, I should ensure its relatively agnostic so that others can begin to adopt this too, especially in terms of ESP management.

`Out of memory[ERROR] cbm (../src/bootman/update.c:L250): No kernels discovered in ///usr/lib/kernel, bailing`

First lines of the Dockerfile:
   # Build container based on Clearlinux
   FROM clearlinux:base

   RUN swupd bundle-add os-clr-on-clr python3-basic
   RUN swupd update
   <snip>

When

$ sudo docker build -t clearlinux -f Dockerfile.clearlinux .
Sending build context to Docker daemon 177.7 kB
Step 1/8 : FROM clearlinux:base
 ---> cfe5f13b90b0
Step 2/8 : RUN swupd bundle-add os-clr-on-clr python3-basic
 ---> Using cache
 ---> 7bd1d6391ac4
Step 3/8 : RUN swupd update
 ---> Running in d271ffc27912

swupd-client software update 3.15.0
   Copyright (C) 2012-2018 Intel Corporation

Update started.
Attempting to download version string to memory
Preparing to update from 21150 to 21520
Downloading packs...
.
Extracting go-basic pack for version 21420

Extracting koji pack for version 21500

Extracting kvm-host pack for version 21500

Extracting libX11client pack for version 21500
.
Extracting openssh-server pack for version 21330
.
Extracting package-utils pack for version 21320

Extracting perl-basic pack for version 21450

Extracting perl-basic-dev pack for version 21510

Extracting python2-basic pack for version 21510

Extracting python3-basic pack for version 21360

Extracting storage-utils pack for version 21360
.
Extracting web-server-basic pack for version 21450


Statistics for going from version 21150 to version 21520:

    changed bundles   : 30
    new bundles       : 0
    deleted bundles   : 0

    changed files     : 3410
    new files         : 5329
    deleted files     : 1658

Starting download of remaining update content. This may take a while...

File /usr/bin/FileCheck was not in a pack
........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Finishing download of update content...

Staging file content
File staging failed: /usr/include/clang/CrossTU
Calling post-update helper scripts.
none
[ERROR] cbm (../src/lib/files.c:L165): Invalid block device: /
[ERROR] cbm (../src/lib/system_stub.c:L31): Invalid block device: 0:75
Out of memory[ERROR] cbm (../src/bootman/update.c:L250): No kernels discovered in ///usr/lib/kernel, bailing
Update took 279.9 seconds
4981 files were not in a pack
The command '/bin/sh -c swupd update' returned a non-zero code: 18

Ensure compliance with freedesktop bootloader specification

Main ticket items:

• Write the version string for systemd-boot
• Write the machine-id string for systemd-boot
• Encode machine-id into target filenames on all systems

For natively booted systems, utilise the machine-id to ensure unique paths. This will ensure that CBM managed OSs can dual-boot with themselves (Dev/Production split)

For image mode builds, continue to use the current paths. This ensures that the first time CBM is run natively, it will perform a migration to the now-available machine-id filenames.

Changing screen resolution on bare metal

I apologize if this is the wrong place to post, I figure the solution is in the boot manager 🤔.

I was wondering if there's a way to modify the monitor resolution for Clear Linux when it's installed on bare metal (and there's no GUI). Would this be possible by modifying /proc/cmdline?

TL;DR the resolution is too good on my Intel NUC and monitor via HDMI, and I'd like to make the font size a little bit bigger.

Tracking: Make Solus happy again

Tracking some issues here as I'll need to follow up with some PRs to restore git master functionality.

Currently tests will fail UNLESS --with-bootloader=shim-systemd-boot. In Travis this passes only because the auto mode will fallback to shim-systemd-boot. All other options will fail on check_uefi.

There is also the issue of files having moved into kernel/ subdirectory, so I'll need to track migration paths.

AR ikey:

• Make --with-bootloader=goofiboot work again (and for all sd class.)
• Prep Travis PR to build in multiple configurations (shim and systemd-class)
• Add migration path for kernel/ tree moving

General:

• distcheck is broken on master (William found this) - cmdline tests no longer pass. LIkely related to the above issue.
• Need to update documentation around new shim system
• Configure doesn't check for gnu-efi-devel and efivar-devel (Solus names but yknow the dudes I mean)

Support managed UEFI variables

clr-boot-manager should retain and maintain the UEFI variables (nvvars) for it's own entry, during boot and upgrades. Specifically a policy must be introduced to allow UEFI variables to be configured from an installation process (i.e. swupd from the Clear Linux installer)