As of glibc 2.25, warnings will be emitted at compile time to state
that you must explicitly include the header now, due to libraries
tending to have their own definitions.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Prior to this change, the kernel and initrd paths were not using the
namespace directory during kernel removal, leading to assets being left
on the disk and filling up the ESP with junk that could not be reclaimed.
This change introduces the simple fix, as well as the UEFI specific test
to ensure that the files are being removed.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Since we switched to legacy vs UEFI namespacing, we only removed the target
path for the internal kernel removal code. This means that non UEFI systems
are being left with old blobs, unmanaged, on the boot partition.
This change ensures we always remove excess blobs for legacy booting systems
and not wasting space in that boot partition/dir.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Due to our repair vs 1:1 "is installed" method changes, it is possible that
a kernel may be asked to be installed more than one time. As such we modify
the syslinux implementation to match that of GRUB2, and ensure that the
kernels being added to the list are all unique.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Now that we no longer write out separate GRUB2 entry files, we have a simple
test to ensure that the old GRUB2 files get removed, and that only the new
one is used.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This change will ensure that the newly selected default kernel is always
the first in the menu, which will also ensure that by default it is the
selected boot entry in GRUB2.
Any other "non default" kernels fall under a submenu structure after the
default kernel, allowing the user to manually select them with keyboard
navigation.
Lastly, to mitigate any potential upgrade issues with dual boot situations,
whereby another distro owns the GRUB2 in use, we select a default kernel
from the list if there is only one kernel, making sure we always have a
/vmlinuz shortcut to satisfy dual boot needs.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Given the nature of a GPT system, it is permitted to have a legacy boot
partition, *and* an EFI System Partition. Thus, prior to this commit, a
chroot repair of a system would only ever find the legacy boot partition
and not the UEFI partition.
Likewise, in a booted system, we would run into the same problem, leading
to bricked systems on update. Now, we'll only try to determine a legacy
boot device if we're definitely not running in native UEFI mode, that is
to say, !image_mode, and /sys/firmware/efi exists. This allows us to skip
an unusable partition in favour of our ESP.
This commit fixes#58.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
With a GPT disk, in native mode, we should ensure that we only use syslinux
if the native system isn't actually UEFI. This test will account for that,
in preparation for issue #58.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
In accordance with issue #53, we must only use the PartUUID for root=
entries when we *know* that the partition definitely resides on a GPT
disk.
Whilst an EFI System Partition must live on a GPT disk to be considered
a valid ESP, there is no such constraint on the rootfs itself. Cases
emerged during testing of an MBR rootfs partition, with a GPT disk used
to house the ESP itself.
This change ensures we only ever write a root=PARTUUID if we're fully
certain of the topology, otherwise all bootloaders will automatically
fall back to root=UUID entries.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Previously the modify_bootloader invocation would attempt to reinit itself
with the abs_bootdir. However, in the instance of a native image, we've
had no reason to set a new boot_dir, thus this value is now NULL, leading
to set_boot_dir to fail for the first time.
Once this is set here, i.e. because we're looking at a real root, we
fire off the reinspection and everything "just works".
This change helps, in part, issue #54.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
In the event that the boot dir exists, we can realpath it to collapse our
returned path to remove any double slashes which in turn would've stopped
the lookup function working for cbm_is_mounted, when determining if the ESP
is already mounted or not.
This helps, in part, issue #54.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
The logic is now changed per issue #54 to properly isolate each image
configuration, and to make the previously added selection test suite,
actually pass.
When we can get_legacy_boot_device, we know we have GPT|UEFI, and hand
off immediately with this device. Likewise, when we can locate the ESP
readily (booted native) with get_boot_device, we can hand off immediately
with this device too.
When we do NOT have a boot device, things get a bit trickier. Previously
we would incorrectly fallback to GRUB2. Now, we check whether we're in image
mode or not, which allows us to directly inspect our host system for further
hints. When in native (!image) mode, we can determine immediately whether it
is a UEFI or Legacy Boot system, by checking for the presence of the vfs
path /sys/firmware/efi.
If we've got this far, and haven't been able to isolate native UEFI/Legacy,
or find them on the GPT disk, we throw caution to the wind and assume we
must be dealing with a UEFI device.
In terms of restrictions, this change mandates that the user only try to
repair and interact with their system via clr-boot-manager using the *same*
boot method as they used to install it, i.e. if it is a UEFI installation
you must also be booted using UEFI.
This is not an insane restriction, as we'll be adding EFI variables support
in future, which will *mandate* the existence of /sys/firmware/efi/efivars
to be able to register.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This test exposes bugs within the core cbm_inspect_root function, by
validating exactly *which* bootloader we select depending on the system
topology.
The tests show that the majority of cases are handled properly, however
when encountering a UEFI system, and we have not been able to explicitly
find the ESP (which is allowed to be mounted already), we fail to select
the UEFI capability, and *very* incorrectly fallback to GRUB2.
Obviously this is highly broken but the test suite is required to develop
the correct functionality, whilst being able to validate changes for *all*
of the possible configurations.
This test is required for issue #54.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
The README now indicates that the project isn't UEFI-specific anymore,
and shows (briefly) how a vendor would integrate clr-boot-manager into
their OS/distro.
Notably we actually now talk about the kernel management benefits, which
are actually far more interesting than the bootloader management parts.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Many distributions permit building out of tree modules against the headers
for each kernel. To allow this to happen in a safely managed fashion, CBM
must be able to remove these paths from disk and allow the software
deployment mechanism to mark these paths as resident.
The net effect is that one can roll back to an older kernel, and still have
the correct headers available for kernel module compilation.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
These are "permanent" paths in the existing implementations of CBM
compatible distros, so they should be removed from the /usr/lib/kernel
tree when removing any of the managed kernels.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This mechanism is used as a fallback when all other methods are unavailable,
i.e. a non GPT non UEFI disk. The basic workflow is as follows:
- Create /etc/grub.d/10_* files containing our wanted boot configuration
- Add necessary shell script glue for grub-mkconfig environment
- Remove any default /vmlinuz /initrd.img symlinks for "default" detection
- Invoke "grub-mkconfig" to cause the grub.d files to be executed
- Restore default /vmlinuz /initrd.img symlinks for dual boot compatibility
The separate namespacing ensures GRUB can never *natively* detect the CBM
managed kernels, and we're free to integrate in this fashion. Due to a number
of severe limitations in the GRUB2 machinery & tooling, we do NOT manage the
actual bootloader itself, rather, the entries for boot.
The GRUB2 bootloader should be installed by the operating system installer and
managed outside the domain of CBM. In the world of UEFI we're able to provide
automatic bootloader updates due to enforced sanity in the protocols and
specifications available to us. In the legacy world, we'd have to consider
a plethora of locations for, and versions of, GRUB2, to provide the binary
management. Thus, it is considered out of scope.
Another key limitation to this approach is that CBM should really be invoked
in "native" mode, that is to say, with chroot from installer or on the native
host. This is due to grub-mkconfig hardcoding the locations of the script
assets to host-side only. An OS installer should chroot into the environment
before invoking "clr-boot-manager update".
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
The primary difference between our "core" bootloaders and the upcoming GRUB2
support, is that in terms of legacy, syslinux is only used to support a GPT
disk.
As such our inspection of the root checks if one of the boot-grab methods
actually succeeded, and if so, enforce the GPT mask. This is because both
of the probe methods are GPT-specific, with the legacy method erroring out
in the absence of a proper PTUUID, and our UEFI method checking the XDG
bootloader protocol, before using /dev/disk/by-partuuid. This is only
supported on GPT.
This change unlocks the addition of a simplistic GRUB2 implementation because
it will have the LEGACY flags but not the GPT flags, thus the syslinux loader
will never be selected, as long as the GRUB loader is placed *first* in the
array. Likewise, the GRUB loader will never be able to be loaded for the
other configurations because it will never have the GPT flag set.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
In order to meet full UEFI compliance, and to enable secure boot, we must
now install our kernel/initrd assets within the /EFI directory on the ESP.
Additionally, we must maintain our unique namespace within this tree to
avoid collisions and allow sane dual boot strategies.
This change moves kernels + initrds to /EFI/$NAMESPACE, i.e.
/EFI/org.clearlinux. To ensure a sane upgrade experiene, we'll now attempt
to non-fatally remove the *old* kernel bits once we've successfully
installed or removed a given kernel.
To better match the use of the 'initrd-' prefix, the new kernels are
prefixed with 'kernel-' but retain much of the name structure. A full test
is also introduced for this UEFI-specific change, which first performs a
simulated install to the legacy paths, and then attempts an upgrade to the
new namespace, while ensuring retention policies. Care is taken within the
test to ensure old files *are* removed.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This completely broke the condition to effectively return true == true.
Luckily our *current* tests still pass with this change, however it was
discovered when introducing namespacing.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
We now use a new target anonymous struct within the kernel to define the
final basename paths, to avoid each use of them having to reconstruct the
paths.
Additionally, the initrd logic was fixed to use the *current* kernel, not
the *default kernel* initrd path. As this code was hard to follow due to
the naming of the variables, the code was clarified to distinguish the
default_kernel from the current kernel (k).
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This change introduces some namespacing within the Kernel struct itself
so that members are now accessed by "->source." and "->meta." to keep them
organised. This makes it far simpler to see *what* is being manipulated as
well as the intent.
This will be followed up with some more changes to include the target fields
as an anonymous struct too, which will help in reducing the duplication in
the various basename/copy/ approaches seen throughout the codebase.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Though we init with built-in defaults, later in our lifetime we may be
presented with a different looking ESP. This change addresses the test
suite failures I introduced in the last commit, by forcing clr-boot-manager
to re-evaluate the ESP immediately prior to commit operations.
To achieve this, we reinit with either the new ESP mountpoint tree, or with
our existing tree, which will in turn make the specific bootloader recompute
the target paths. As an example, the systemd-class bootloaders will now
be able to cope with "/efi/BOOT" and correctly build the case path for it
on a newly mounted ESP, when internally we expect "/EFI/Boot".
This change is critical in allowing clr-boot-manager to fully respect the
ESP and cope in all dual boot scenarios (i.e dated/lazy installs with the
old "/EFI/BOOT" or "/efi/boot" directories.). In short, this results in a
more robust CBM.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
We may, in certain dual boot scenarios, encounter paths on the ESP that
we don't expect. Previously the use of nc_build_case_correct_path was
relied upon for this, to ensure that even if a directory "EFI" is called
"efi" on the FAT32 ESP, we use the "efi" name, to satisfy both the FAT32
case ignorance, and Linux case sensitive, requirements.
However testing shows that we only actually init the paths *before* mounting
any ESP, meaning we are case sensitive. This test suite change then forces
deliberately case-incorrect paths, and forces clr-boot-manager to compensate
by building the case correct paths.
The next change will change clr-boot-manager to correctly reinit the bootloader
with the newly available paths post-mount stages to ensure we fix this newly
introduced test failure.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Our log levels are an unsigned enum, so mixing those lead to redundant
checks, i.e. <= 0 when it could never be less than 0. This change forces
a more obvious use of unsigned numbers so we know it's never less than 0.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
The signedness issue was found when compiling with clang, by forcing the
unsigned enum. Also notable was the lack of absolute mask check with the
flags, which is also now corrected.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Clang recently does support zero initialisation of structs, but even to this
day it continues to complain about them. Unfortunately that makes the code
very ugly and non-obvious. Thus, we silence this warning entirely and rely
on good C initialisation.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This issue was flagged by clang as GCC seems to be skipping the more obvious
compilation warnings.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
We now make the bootloader management somewhat more intelligent by
selecting them based on a boot *mask*. Instead of limiting conditionals
to one or two more branching conditions, we build a mask from what we
need from a bootloader, to dynamically locate the *most appropriate*
bootloader.
This will help to simplify further bootloader additions (such as GRUB2)
by finetuning the difference between the legacy implementations.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This is used to describe in an obvious sense the purpose and application
for a given bootloader implementation. For now we'll use this to determine
whether a selected bootloader is being used in UEFI mode or not, and in the
future we can expand on this to dynamically select the correct bootloader
based on the system topology.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This will help in recovering the coverage numbers that have been lost to
untestable malloc-failure codepaths, by continuing to do exactly the same
thing as before: if malloc-fail, abort().
This also makes the code far simpler and more pleasant to navigate and
removes a huge number of the abort calls from the codebase. Some still
exist but they are both minimal and obvious.
This small, seemingly trivial change, restores almost 2% coverage in the
codebase testing.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This function will, from the perspective of the client code, *always*
return something. There is no need to check for returns, because if for
any reason clr-boot-manager cannot allocate the memory, it will abort on
the spot.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This is a very large function and shouldn't be rlined at all, reduce the
overall weight of the os-release parser by making this a shared function.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This change unblocks distcheck again by adding the new gptmbr faux file
to the EXTRA_DIST set.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Due to some design enhancements along the way and a shedding of unnecessary
weight, these functions are no longer referenced anywhere in the codebase.
Drop them, as they negatively impact coverage for no good reason.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
We now just leverage the existing defines at build time due to our
new-lack of architecture-size specific support, making the codebase
significantly less complicated.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This has failed to appear in any version of systemd-boot or derivatives,
and is uncommon enough for CBM's target to not warrant holding onto the
code within our codebase, as it's completely useless without support
being added at the bootloader level for the EFI handover protocol.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
To ensure that new tests are less complex, and that there are no unknown
parameters in the test system, we move all initial bootloader setup to
the test harness.
Additionally, we now ensure we setup the bootloader based on whether the
UEFI configuration is selected, and fallback to syslinux propagation when
this isn't the case. Now all tests are tailored explicitly to use UEFI
or syslinux legacy, leaving less room for error/guesswork.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This test ensures that the UEFI-specific bootloader removal functionality
does as advertised, and truly does remove all of our "bits" from the
target system when requested.
This test is distinctly more messy than the current tests as it has to
know exactly which files should be gone due to the opaque bootloader
system.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
These tests verify the basic install & update functionality for the
bootloaders, not the kernels. It should be noted that in the case of
syslinux, we have a restricted feature-set. As such we *always* report
that syslinux needs an update when the source file changes, because
it's far cheaper than actually reading the block device itself.
This change also addresses the gptmbr bin file being 1 byte too long,
which was revealed during the development of this test.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
The new testing revealed that when updating from a non CBM managed system
to a CBM managed one, i.e. the running or default kernel is unknown, then
we previously assumed it was always set. This small fix addresses the crash
and unbreaks initrd bits in syslinux.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Ikey Doherty