mirror of
https://github.com/clearlinux/clr-boot-manager.git
synced 2026-10-03 23:38:21 +00:00
Ikey Doherty
aa6251a495
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>