Frozen boot entries silently make /etc/default/grub edits inert (no warning in Config Editor)

[jetomev]

Found live on the KognogOS testbed, 2026-08-10 — cost about an hour of misdiagnosis, so it earns a good write-up.

What happened

Setting up Plymouth required splash on the kernel command line. In grubForge's Config Editor I set:

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet splash"

grubForge saved it and said so. But after grub-mkconfig and a reboot, /proc/cmdline still read loglevel=3 quiet — no splash. Plymouth started with no framebuffer signal and fell back to its details view, which prints more boot text than before. The user's conclusion was reasonable: "Plymouth doesn't work." The truth was that the setting never reached the boot menu.

Root cause

The machine is in grubForge's frozen-entries mode: generated entries were snapshotted into /etc/grub.d/40_custom and the generators disabled (permissions preserved in the sibling files):

-rw-r--r-- 10_linux
-rw-r--r-- 10_linux.grubforge_perms
-rw-r--r-- 30_os-prober
-rw-r--r-- 30_os-prober.grubforge_perms
-rw-r--r-- 30_uefi-firmware
-rw-r--r-- 30_uefi-firmware.grubforge_perms
-rwxr-xr-x 40_custom

Static entries in 40_custom carry their own hardcoded linux … lines, so GRUB_CMDLINE_LINUX_DEFAULT and GRUB_DISTRIBUTOR cannot affect them. Both were edited; neither had any effect. GRUB_DISTRIBUTOR="KognogOS" likewise left every entry reading "Arch Linux".

Two grubForge features are individually correct and mutually contradictory, with nothing in the UI connecting them.

Asks

1. Detect the state and say so. When generators are disabled / *.grubforge_perms files exist, the Config Editor should show a persistent banner on the affected keys:

   ⚠ Boot entries are frozen — GRUB_CMDLINE_LINUX_DEFAULT and GRUB_DISTRIBUTOR will not affect them. Edit the entries directly, or unfreeze first.

2. Offer the right action from that banner: apply this change to the frozen entries too, or unfreeze and let GRUB generate again.
3. Related, smaller: saving in the Config Editor does not run grub-mkconfig (that's a separate Ctrl+R), while the Theme Browser regenerates on apply. Inconsistent between two screens of the same app — a save that needs a second, undiscoverable step reads as "done" when it isn't. Either regenerate on save, or show a "boot menu is stale" indicator until it happens.

Fix used in the field

Edited the frozen entries directly, then regenerated:

sudo sed -i '/vmlinuz-linux/s/quiet/quiet splash nvidia_drm.modeset=1 nvidia_drm.fbdev=1/' /etc/grub.d/40_custom
sudo sed -i 's/Arch Linux/KognogOS/g' /etc/grub.d/40_custom
sudo grub-mkconfig -o /boot/grub/grub.cfg

Queued for the forgekit migration cycle (Javier's call, 2026-08-10) — the redesign is the natural moment to fix the UX gap rather than bolt a warning onto the old layout.

🤖 Generated with Claude Code