Skip to content

feat(roles/bootloader): add role - #331

Open
markuslf wants to merge 1 commit into
mainfrom
feat/bootloader-role
Open

feat(roles/bootloader): add role#331
markuslf wants to merge 1 commit into
mainfrom
feat/bootloader-role

Conversation

@markuslf

Copy link
Copy Markdown
Member

Manages the kernel command line, for parameters that only take effect at boot time such as psi=1. Triggered by icinga-demo, which needs psi=1 for the psi-cpu / psi-io / psi-irq / psi-memory checks.

What it does

  • Red Hat family: writes the boot entries with grubby --update-kernel=ALL. Nothing in grub.cfg is touched; grubby keeps GRUB_CMDLINE_LINUX in /etc/default/grub in sync by itself.
  • Debian family: deploys /etc/default/grub.d/z00-lfops.cfg and runs update-grub. grub-mkconfig sources that directory after /etc/default/grub, so the packaged file is never edited.
  • An option counts as present only when every boot entry carries it, and it is escaped before it goes into the comparison.
  • A changed command line requests a reboot via schedule_reboot instead of rebooting right away.
  • --check touches nothing and reports what it would change.

Why not fedora.linux_system_roles.bootloader

It was the first implementation, and a --check --diff against a real host showed why it cannot stay:

  • bootloader_settings declares supports_check_mode=True but never reads module.check_mode, so a dry run rewrites the boot entries for real.
  • The role forces GRUB_TIMEOUT on every run, overwriting a value the host set on purpose.
  • Its replace on grub.cfg matches set timeout=.* everywhere, so set timeout="${menu_show_once_timeout}" becomes a literal and the fastboot and recordfail timeouts are flattened.

Dropping it also removes the dependency on the Linux System Roles collection.

Verification

Run on Rocky 8, Rocky 9, Rocky 10, Fedora 44 and Debian 13, two of them with a GRUB_TIMEOUT differing from the default:

step result
--check --diff every file checksum and boot entry byte-identical afterwards
first run option on all boot entries, grub.cfg untouched on the Red Hat family
second run changed=0
state: 'absent' plus rerun original state restored, changed=0 on the rerun

Idempotency and the check run were additionally confirmed against icinga-demo.

COMPATIBILITY.md marks Debian 13, RHEL 8, 9, 10 and Fedora 44 as proven; Debian 12 and the Ubuntu releases stay (x), where only the container and source-level checks exist.

Manages the kernel command line, for parameters that only take effect at
boot time such as psi=1.

On the Red Hat family the boot entries are written with grubby, on Debian
and Ubuntu through a drop-in in /etc/default/grub.d/ followed by
update-grub, so the packaged configuration files stay untouched. An option
counts as present only when every boot entry carries it, and it is escaped
before it goes into the comparison. A changed command line requests a
reboot through schedule_reboot instead of rebooting right away, and a
--check run reports what it would change without touching the host.

The role deliberately does not use fedora.linux_system_roles.bootloader:
that role rewrites GRUB_TIMEOUT in /etc/default/grub and every
`set timeout=` in grub.cfg on each run, including the ones of the
menu_auto_hide and menu_show_once blocks, and its bootloader_settings
module declares supports_check_mode without ever reading
module.check_mode, so a --check run rewrites the boot entries for real.

Verified on Rocky 8, Rocky 9, Rocky 10, Fedora 44 and Debian 13: the check
run leaves every file and boot entry byte-identical, the first run applies
the options to all boot entries, the second reports no change, and
removing them restores the original state.
@markuslf
markuslf requested a review from NavidSassan August 28, 2026 12:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant