Adding options to the kernel command line is a common task when debugging or experimenting with the kernel. The upcoming Fedora 30 release made a change to use Bootloader Spec (BLS). Depending on how you are used to modifying kernel command line options, your workflow may now change. Read on for more information.
To determine if your system is running with BLS or the older layout, look in the file
If you only want to modify a single kernel entry (for example, to temporarily work around a display problem) you can use a grubby command
$ grubby --update-kernel /boot/vmlinuz-5.0.1-300.fc30.x86_64 --args="amdgpu.dc=0"
To remove a kernel argument, you can use the
argument to grubby
$ grubby --update-kernel /boot/vmlinuz-5.0.1-300.fc30.x86_64 --remove-args="amdgpu.dc=0"
If there is an option that should be added to every kernel command line (for example, you always want to disable the use of the rdrand instruction for random number generation) you can run a grubby command:
$ grubby --update-kernel=ALL --args="nordrand"
This will update the command line of all kernel entries and save the option to the saved kernel command line for future entries.
If you later want to remove the option from all kernels, you can again use
$ grubby --update-kernel=ALL --remove-args="nordrand"
Thanks for the article. Nice to know about BLS.
Thanks for the tip. I would like to not change my habits about the sensitive kernel commands to avoid waste of time and big risks. Should I set GRUB_ENABLE_BLSCFG to false to work as usual?
FWIW this only applies to traditional Fedora Server/Workstation etc. today – for rpm-ostree based systems like Fedora CoreOS and Silverblue, you need to use
because kernel commandline changes are part of the general OSTree transaction system. At some point we’ll likely wrap
to tell you to do this instead.
(Ultimately this ends up writing a BLS fragment though)
When ever kernel update is involved, i invariably get the error “failed to start load kernel modules………..” at boot time and i had to resort to dracut after boot up. With the recent kernel 5 update even dracut is not working as i get the alert permanently. Any help from kernel wizards?
In the early BLS-day’s I manually edited grubenv to append kernel options because grub2-mkconfig was not doing it. This was later addressed. I kept getting environment blocks too big and too small messages on kernel updates. This blog post inspired me to look into this.
It turns out the the environment block messages were due to me editing grubenv manually. I set out to fix this and ran into a bugzilla. There it was suggested one run grub2-editenv clear. I did this. Then i ran grubby –update-kernel=ALL –args=”mykernelopt” and i rebooted. I selected one of my kernel entries from the grub menu and the boot process hung. I then tried again and edited the kernel entry in the grub menu to get it to boot. Turned out it has left out some important bits and pieces.
Once i was able to boot into the system I ran grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg. This fixed things. I found it somewhat ironic that I had to use grub2-mkconfig to fix my grub entries.
Why on earth do they want to complicate things? Just a text file or two was working fine. Now is a new “tool” to modify a bunch of files with instructions we cant understand, making this difficult to diagnose.
As far as I know this is based on working with systemd’s boot commands (which is a pure EFI bootloader). The “pure” systemd approach is pretty minimal and easy, but for some reason Fedora had to make it complicated by using grub as well… I’m confused as well, but I’m sure Fedora devs have their reasons.
Yazan Al Monshed
Great Article. Big Thanks
It would have been good to cover the ‘why?’ this new way has been implemented.
The why is covered pretty extensively in the BLS link provided in the article. Specifically WRT systemd “TL;DR: Currently there’s no common boot scheme across architectures and platforms for open-source operating systems. There’s also little cooperation between multiple distributions in dual-boot (or triple, … multi-boot) setups. We’d like to improve this situation by getting everybody to commit to a single boot configuration format that is based on drop-in files, and thus is robust, simple, works without rewriting configuration files and is free of namespace clashes.”
Justin W. Flory
Thanks for the simple explanation! I was wondering the same thing.
So how would someone boot to single user mode from the grub menu using this new “BLS” configuration?
That’s still the same just add an s to get to single user mode.
Justin W. Flory
It is unclear to me how
is used. Is this from the grub CLI or from a logged-in user’s Bash shell? I was wondering how someone, for example, battling graphics drivers might debug their system if they are unable to log into their system to change kernel boot parameters.
What if I want to just add something quick to the kernel line before boot or after an install…
For example, I have an ASUS laptop with integrated Intel and Nvidia, so I have to add nouveau.modeset=0 and acpi_osi=Linux to handle some drivers correctly and it doesnt boot to a black screen cause the OS doesnt know what GPU to use.
Can we just add this to the kernel command still and boot or is this process changing too?
Grubby is being used at the command line in a terminal likely using bash for the shell. If you follow the link above, then further to this page https://systemd.io/BOOT_LOADER_SPECIFICATION you can get the whole scope pretty much.