Setting kernel command line arguments with Fedora 30

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

/etc/default/grub
If you see
GRUB_ENABLE_BLSCFG=true
in there, you are running with the BLS setup and you may need to change how you set kernel command line arguments.

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

--remove-args

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

--remove-args
with
--update-kernel=ALL

$ grubby --update-kernel=ALL --remove-args="nordrand"

Fedora Project community

16 Comments

  1. Thanks for the article. Nice to know about BLS.

  2. gnu

    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?

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

    rpm-ostree kargs

    because kernel commandline changes are part of the general OSTree transaction system. At some point we’ll likely wrap

    grubby

    to tell you to do this instead.

    (Ultimately this ends up writing a BLS fragment though)

  4. svsv sarma

    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?

  5. dac.override

    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.

  6. A Seda

    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.

    • Sebastiaan Franken

      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.

  7. Yazan Al Monshed

    Great Article. Big Thanks

  8. Sebastiaan

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

  9. So how would someone boot to single user mode from the grub menu using this new “BLS” configuration?

  10. Ben

    That’s still the same just add an s to get to single user mode.

  11. It is unclear to me how

    grubby

    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.

    • Joe Giles

      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?

      Joe

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

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions