Manage GRUB 2 Kernel Boot Entries with grubby

On RHEL 10, GRUB 2 provides the boot menu and grubby manages kernel entries and their arguments. Boot Loader Specification (BLS) files identify each installed kernel. These tools replace the old LILO workflow; there is no LILO sector map to regenerate after changing a kernel entry.

This lesson assumes an x86-64 RHEL 10 VM using conventional kernel and initramfs files. Complete the artifact checks in Lesson 10 first. Unified kernel images and other boot managers require their own procedures.

Choose the tool for the job

• Inspect entries, change kernel arguments, or select a default: use grubby.
• Change GRUB menu settings: edit the appropriate settings in /etc/default/grub, then generate /boot/grub2/grub.cfg.
• Repair bootloader installation: follow the firmware-specific recovery procedure. Installing a kernel does not normally require reinstalling GRUB.

RHEL stores BLS entries under /boot/loader/entries/. Each describes a kernel, initramfs, and command line. Package installation normally maintains them. For the source-build lab, verify what the installation hooks actually created; a successful compilation alone does not create a usable menu entry.

1. Inspect and record the existing configuration

uname -r
sudo grubby --info=ALL
sudo grubby --default-kernel
sudo ls /boot/loader/entries/

The running release and the configured default can differ. Record the known-good kernel's complete filename and entry details in your lab notes before changing anything. Use filenames to identify targets because numerical menu indexes can move when kernels are added or removed.

Compare the target entry with the files verified in Lesson 10. Confirm its initramfs, root-device and storage arguments, and required console settings. An entry does not establish that Secure Boot trusts the kernel or its modules.

2. Test the target through the console

Keep the known-good kernel as the default for the first test. Use the VM console to select the target from GRUB. If you need a temporary diagnostic change, press e, edit the kernel command line, and press Ctrl+x to boot. For example, removing existing rhgb and quiet arguments exposes more startup messages. This menu edit applies to that boot only.

uname -r
cat /proc/cmdline

After startup, confirm the intended release and effective arguments, then check storage, networking, logs, and your workload. If startup fails, return to the known-good entry through the console and investigate the target's files and logs.

3. Select a verified default

After a successful boot test, substitute the exact verified release below. The entry and kernel image must already exist.

target_release='REPLACE_WITH_VERIFIED_KERNEL_RELEASE'
kernel_image="/boot/vmlinuz-$target_release"
sudo grubby --info="$kernel_image"
sudo grubby --set-default "$kernel_image"
sudo grubby --default-kernel

Confirm that the reported default matches your target. Setting a default affects later boots; it neither replaces the running kernel nor repairs missing artifacts. To restore the previous default, use grubby --set-default with the known-good filename recorded in your notes.

4. Change one entry's arguments

For a persistent diagnostic change, remove quiet only from the selected target. First inspect and record its arguments. In a new shell, define target_release and kernel_image again as above.

sudo grubby --info="$kernel_image"
sudo grubby --update-kernel="$kernel_image" --remove-args="quiet"
sudo grubby --info="$kernel_image"

After booting that target, inspect /proc/cmdline. Restore quiet with the following command only if it was present before your change:

sudo grubby --update-kernel="$kernel_image" --args="quiet"
sudo grubby --info="$kernel_image"

--update-kernel=ALL changes every entry, including the fallback; use it only for an intentional system-wide policy. Ordinary grubby changes do not require a separate GRUB configuration rebuild.

When configuration regeneration is appropriate

For a deliberate menu-setting change, such as GRUB_TIMEOUT in /etc/default/grub, first back up the configuration and review the change. Then regenerate the main configuration:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

On RHEL 10 this destination applies to both BIOS and UEFI. The UEFI file /boot/efi/EFI/redhat/grub.cfg is a forwarding stub: do not overwrite it with generated configuration.

Kernel arguments managed by grubby are distinct from the defaults in /etc/default/grub. The additional --update-bls-cmdline option intentionally replaces BLS arguments from GRUB_CMDLINE_LINUX; it can erase per-entry differences. It is not needed for this lesson's targeted changes.

Bootloader repair and recovery

grub2-install writes bootloader components and is a separate repair operation. On BIOS, the target must be the verified boot disk; copying an example naming /dev/sda may select the wrong device. On x86-64 UEFI, Red Hat documents reinstalling the GRUB EFI and shim packages instead. Follow the linked repair procedure for the actual firmware, architecture, and mounted filesystems.

Retain the known-good kernel, modules, initramfs, and entry, and confirm console access before rebooting. Keep the vendor kernel available throughout the custom-kernel lab. Proceed to the module conclusion once the selected entry and recovery path are verified.

References

• RHEL 10: Kernel command-line parameters and boot entries
• RHEL 10: Reinstalling GRUB and configuration paths