Up until now the quiet option in /etc/default/grub performed just that: keep my console quiet on startup, with just the right amount of information.
I just installed Rocky Linux 9 on my new workstation, and even though I specified quiet in /etc/default/grub and updated GRUB, I still get a tsunami of messages.
I gave the loglevel=3 option a try, which works perfectly under Void Linux, but unfortunately it seems to do nothing here.
Boot menu entries are by default separate files and cmdline options are in each of them.
one can peek what the entries have: grep options /boot/loader/entries/*.conf
Since el9_3 update of cmdline via mkconfig requires extra option, which “overwrite BLS cmdline args with default args”:
Alternatively, grubby --update-kernel=ALL with the options that need tuning. See man grubby
It should update GRUB_CMDLINE_LINUX in /etc/default/grub too …
If your “updated GRUB” did already use one of these (i.e. the entries do have your options), then I don’t know goes wrong. Personally, I prefer verbose.
Although I’ve been a Linux user for the last couple decades, this is the kind of thing that makes me feel that you have to belong to some special secret club to get this kind of information.
Who invents these things? Who decides in the middle of a minor release that from now on grub2-mkconfig won’t work as it did before? I’m just asking because I just wondered for the best part of the day why the kernel options I added manually in /etc/default/grub weren’t working apparently.
Wow, Google says that there are no good matches for that word.
The ‘grub.cfg’ used to be one file. Every kernel install, removal, and option change did require touching that monolith. Doable, but understandably not fun.
Someone got the Boot Loader Specification (BLS) idea – (almost) every boot entry as separate file that are included. No more unnecessary edits of the grub.cfg; the most common thing (dnf up) merely adds and removes entry files.
But how? And how was grub.cfg updated before? IIRC, I saw statements that ‘grubby’ is an ancient monolith, difficult to maintain. Yet, it is the grubby that Red Hat docs now market as “first choice”.
Not to mention the cmdline options.
Did you notice that in el8 each BLS entry dereferences a variable?
options $kernelopts $tuned_params
Where is kernelopts set? In grubenv and is thus same for every entry. “Just” update the grubenv …
Naturally, that must have had some side-effects, because el9 does not use ‘kernelopts’ variable.
Oh no, the grubby reads the options from /etc/kernel/cmdline
(The grub2-mkconfig --update-bls-cmdline does update the /etc/kernel/cmdline)
Now each entry can be made different from default.
Someone felt that something was broken, and now it involves more chefs than Guide Michelin.
PS. Why add --update-bls-cmdline in the 9.3? The thing before was apparently not the best brand of duct tape (i.e. something that beta for 9.0 did not catch).