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>
Prefix source and destination for install/update using boot root
returned by boot_manager_get_boot_dir() as opposed to BOOT_DIRECTORY.
Both work, but boot_manager_get_boot_dir() allows for testing.
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>
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>
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>
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>
Arzhan Kinzhalin