In some cases (legacy in particular) /proc/self/mounts contains
/dev/root as the device the root path ('/') resolves to. This isn't
a valid device and so fall back to using stat in cases where
cbm_system_get_device_for_mountpoint doesn't return a device path.
Signed-off-by: William Douglas <william.r.douglas@gmail.com>
Calling stat() on some filesystems, like Btrfs,
results in a dev_t with no relation to the backing device(s),
and subsequent failure to detect the root fs.
Add support such filesystems by retrieving the block device from
`/proc/self/mounts` and working on from there.
Resolves#61, #182 and #193.
Improve the internal filesystem detection, with these changes we
can reuse this code elsewhere and be more efficient - other areas
needing the filesystem knowledge can use this mapping strategies
adding a more precise and centralized code to that.
This patch also makes sure to keep tests and filesystem checks more
consistent.
When mounting we were assuming the /boot filesystem to always be
vfat, with this code now we can have /boot partitions with whatever
filesystem we support (for now: vfat, ext[2-4]).
Signed-off-by: Leandro Dorileo <leandro.maciel.dorileo@intel.com>
We should not rely on these being present on the filesystem and
the space we use is minimal. On top of that, we need at a later stage
dynamically choose gpt or non-gpt MBR blocks depending on the device,
so we need both available no matter what.
Punch a hole so the bootloader can easily get the wanted_boot_mask
and decide whether the GPT or non-GPT mbr.bin is needed.
Without a FS type set, all tests will fail because none of the
bootloaders are compatible. We change the tests to simulate the
appropriate FS type so that these tests succeed as expected.
`syslinux` is a bootloader for `FAT` filesystems. `extlinux` is a bootloader
for `ext` filesystems. The name therefore is entirely incorrect, since the
code clearly is using `extlinux` and we may want to support `syslinux` at
some point in the future.
This is a mostly mechanical rename/replace.
Previously the only removal that would be processed was extra
configuration and not the default kernel commandline that is shipped
with the kernel. This change moves processing the removal until after
the extra configuration and the default commandline have been merged.
Add the cli command list-kernels which will display the currently
available kernels that can be booted on the system and highlight the
kernel which will be used for the next boot.
Also add the cli command set-kernel which will set the given kernel as
the default to be used for booting (until the next update or
set-kernel is run).
Add the ability for clr-boot-manager to handle removing content from
the kernel commandline. The removal configuration files are formatted
exactly the same as the add configuration files. The matches are done
line-by-line so that:
"option-a option-b"
in a removal file would only delete exactly that string unlike:
"option-a
option-b"
in a removal file which would try to remove "option-a" and "option-b"
separately.
gummiboot hasn't been supported upstream or by Clear Linux for an age,
and due to format bumps no compatibility is required with it, thus it
can be completely removed from source.
goofiboot, the fork of gummiboot, was initially created to address concerns
in systemd-boot in their tooling. However, the concerns were mitigated by
opting to entirely bypass their tooling, and clr-boot-manager absorbed all
safety and distribution support that was part of libnica and goofiboot.
At this point, both of the legacy bootloaders are safe to be nuked from
orbit and are no longer used in CBM-using distributions.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
Validate that update fails and kernels aren't installed when a
freestanding initrd is missing. This test ensures that an invalid boot
menu entry (due to it listing initrd files that do not exist) are not
installed when update fails.
add suport for freestanding initrd in /usr/lib/initrd.d
for systemd-boot, grub2 and syslinux
Signed-off-by: Josue David Hernandez <josue.d.hernandez.gutierrez@intel.com>
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.
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 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
This test enables us to mock the upgrade process going from a non CBM
managed system to a CBM managed one, for the first update. Importantly,
it ensures that the kernel transition itself works fine.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This test checks the basic kernel install functionality in native mode
for both legacy & UEFI boot systems. It is not a comprehensive policy
test.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This mimics the check-legacy test almost identically, but taking the
inverse road in certain areas to cater specifically for UEFI. Notably,
it also ensures that Legacy Boot is not detected.
This change will allow us to begin fleshing the main test suites out
in parallel to ensure they do not drift.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This allows humans to look at the generate files during test suite
creation and actually understand what is happening, instead of dealing
with arbitrary version numbers.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This test adds very basic coverage for doing a basic image installation,
using the syslinux legacy path.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Brett T. Warden