update grub2_with_bls.md

This commit is contained in:
tengel 2024-03-20 11:40:22 -05:00
parent ec1290c3b6
commit 8a1f38d024

View file

@ -1,5 +1,16 @@
# GRUB2 with BLS
- [BLS Overview](#bls-overview)
- [Design Overview](#design-overview)
- [Changing Kernel Parameters](#changing-kernel-parameters)
- [Operational Use](#operational-use)
- [Boot Time Editing](#boot-time-editing)
- [BLS Kernel Configuration File](#bls-kernel-configuration-file)
- [File Locations](#file-locations)
- [Plugin Directories](#plugin-directories)
- [Vendor Provided Scripts](#vendor-provided-scripts)
- [References](#references)
## BLS Overview
Starting with EL8/OL8 (RHEL, CentOS, OracleLinux) the GRUB2 boot design is using BootLoaderSpec (BLS):
@ -14,7 +25,7 @@ This article goes over the design and usage of the BLS environment as delivered
The EL8 BootLoaderSpec design takes the traditional single-file GRUB2 approach and extracts each kernel's configuration to it's own unique file per kernel, located in `/boot/loader/entries`.
* The master file `/etc/default/grub` is still used to change the kernel parameters via **GRUB_CMDLINE_LINUX**
* The `/etc/default/grub` file introduces a new setting ***GRUB_ENABLE_BLSCFG=true** (default)
* The `/etc/default/grub` file introduces a new setting **GRUB_ENABLE_BLSCFG=true** (default)
* Running `grub2-mkconfig` will now update `/boot/grub2/grubenv` even if your output is temporary file! See the new `--no-grubenv-update` option to `grub2-mkconfig`
* The operational problem with `grubby` and `grub2-mkconfig` generating different text strings for the kernels should be gone
@ -152,14 +163,9 @@ A general list of the critical files and their use as drop-in scripts from a def
| File | Package | Purpose and Usage |
| ---------------------- | -------------- | ----------------- |
| `/bin/kernel-install` | `systemd-udev` | Called at the end of a kernel RPM install/upgrade, like so: `/bin/kernel-install add 4.18.0-80.el8.x86_64 /lib/modules/4.18.0-80.el8.x86_64/vmlinuz` Internally, after gathering the scripts available it runs each script below in order, like so: `"$f" add "$KERNEL_VERSION" "$BOOT_DIR_ABS" "$KERNEL_IMAGE"` ...where `BOOT_DIR_ABS` is an internal working directory it has calculated dynamically. This script has a built in special behaviour - if any one of the below scripts exits with the magic exit code `77`, it will abort running any other scripts. |
| `/etc/grub.d/10_linux` | `grub2-tools` | The traditional menu builder script has been updated to trigger an internal GRUB2 module for reading BLS, instead of building the kernel menus itself. The script now writes:
```
insmod blscfg
blscfg
```
...to `/boot/grub2/grub.conf` where the kernel menu entries used to reside. |
| `/etc/grub.d/10_linux` | `grub2-tools` | The traditional menu builder script has been updated to trigger an internal GRUB2 module for reading BLS, instead of building the kernel menus itself. The script now writes `insmod blscfg; blscfg` ...to `/boot/grub2/grub.conf` where the kernel menu entries used to reside. |
**/usr/lib/kernel/install.d/**
**Path: /usr/lib/kernel/install.d/**
| File | Package | Purpose and Usage |
| -------------------------- | ---------------------- | ----------------- |
@ -172,7 +178,7 @@ blscfg
| `92-tuned.install` | `tuned` | Updates the values of any custom tuned-provided values to the BLS entries; examining the BLS configuration you will notice the variable $tuned_params on the "options" line, right after the variable for the `$kernelopts`. This is not stored in the GRUB boot block! (grubenv) – it's an inline sed of the BLS config file directly. |
| `99-grub-mkconfig.install` | `grub2-common` | This script is only used on PP64 based hardware, it's purpose is generally that of `20-grub.install` but trivially designed for non-BLS configurations. It will short-circuit itself if not running on PP64 based hardware and exit. |
**/etc/kernel/install.d/**
**Path: /etc/kernel/install.d/**
| File | Package | Purpose and Usage |
| ------------------------ | -------------- | ----------------- |