This change is designed to make it simpler to maintain clr-boot-manager
by switching to the much easier meson build system. Care is taken to
preserve the original functionality, but this will allow us to avoid
repeated issues of "failed distcheck", etc.
Additionally, a new test entry point is now included for Travis, to ensure
all relevant codepaths are properly tested. This now enables us to trivially
merge multiple runs into a single coverage report so that we can test the
code base in various "deployments".
To alleviate the issue of distributing without a `make distcheck` target,
this change vendors the `git-archive-all.sh` script into `scripts/` and
provides a port of the `budgie-desktop` `mkrelease.sh` script to quickly
and easily create a signed distribution tarball straight from git, along
with the submodules (i.e. nica).
Lastly, we'll only build the bootvar support + systemd-shim when we've
actually selected this bootloader, to ensure the project can still be built
without needing gnu-efi/efivar.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
kernel.c no longer creates any layout, but systemd-class was not
creating/ensuring kernel target directory either. This fixes the issue.
Also, tests are fixed to use proper ESP standard names throughout.
clang-format changes its output too much between versions to block
commits so go back to users being on their own for format following
the style rules.
This change allows the installation of a shim when using systemd-boot as
the bootloader. It also enables the management of EFI variables to
manage the default boot device.
The shim will eventually become a required piece for secure-boot enabled
booting.
This fixes a segfault occuring within clr-boot-manager's usage of the
`blkid_partlist_numof_partitions` function that will now segfault when
passed a NULL blkid_partlist, as of util-linux 2.30.x series.
This change will ensure all consumers of the cbm_blkid API will continue to
function as before, but safe guard against the util-linux internal changes
that broke the counter function to determine how many partitions are present.
Note that this behaviour only manifested on LVM installations, which have
a more advanced probing scheme within clr-boot-manager.
Solus Issue: https://dev.solus-project.com/T4763
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
This change introduces support for vendor kernel configuration fragments,
which typically live within the /usr/share/kernel/cmdline.d directory.
These are useful to vendors and OEMs to pre-enable some hardware quirks
such as acpi_os, i8042 tweaks, etc.
These files take a higher precedence than the /etc/ files, however to
ensure we abide by a proper stateless policy we allow the concept of masking
and disabling in the style of systemd. The files in the "vendor config"
directory are considered masked when a file with the same base name lives
within the "system config" (/etc/kernel/cmdline.d) tree. The vendor file
will be skipped regardless of system config validity in this instance.
To allow disabling entirely of the vendor config file, the local system
administrator may follow the masking approach as described as above, but
instead of creating a override, symlink this file to /dev/null. This will
cause the file to be removed entirely from any kind of parsing. This link
logic is only valid within the context of the system config directory.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
Using automake default modifiers ('cru') makes ar warn about
meaningless 'u':
/usr/bin/ar: `u' modifier ignored since `D' is the default (see `U')
Instead of using the defaults, specify all the modifiers explicitly:
'crD'.
The first and most important change is to ensure that we never try to
grab the host ESP when we're operating in image mode. This alone causes
issues when producing images using "--path", i.e. VHD imagery.
Secondly, we ensure that we *always* set image mode *before* we set the
prefix, as this prefix is only ever set once. This is the part where we
inspect the root of the system we're looking at, and determine whether
we're dealing with legacy or UEFI, or legacy+gpt (i.e. Azure images).
Lastly, we make sure that update_image follows the lead of update_native
by re-initialising the bootloader prior to using it, with the current
root + boot directory settings, ensuring we're always using fresh
values and world view.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
The lack of kernel modules during install isn't necessarily fatal, and
some kernel configurations might be without modules entirely. Notably,
given that kernel modules are to be marked as resident on disk, even if
we have multiple packages compromising a kernel and separate modules, those
old modules will be removed at the time of the kernel change, and at no
other time, ensuring an atomic update.
This resolves#67.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
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>
William Douglas