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).