Help adding a MenuEntry in grub


Need to add a GRUB menu entry with all exactly the same as default but just with some different Kernel parameter settings, i.e.

... rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1
and another with
... rd.driver.blacklist=nvidia,nvidia_drm,nvidia_modeset modprobe.blacklist=nvidia,nvidia_drm,nvidia_modeset

What’s the most efficient way to achieve this? I’d like it also to stay up-to-date when a new kernel version comes up.


Good reading

Q:  “Where is my grub.cfg menuentry’ now !?”
A (Дядя Лёня’s):  Boot Loader Specification (

Idea.  In Fedora, there should (already) be some “hooks” (“installation helpers”) for packages being installed by DNF (package manager).  Kernel’s package (.rpm) included.
Edit. Found it! Just like we got it in Arch-ie: DNF: post-transaction actions.
An example of dnf-“hooks” (below).

So, by configuring the “hook” for the Kernel package, this should be possible to create (at least just create, but rather also delete obsolete ones) a file in /boot/loader/entries/ every time the kernel get updated.

This file should be just a modified copy of most recent existing one, or a such.

# maxcpus=1 used as example below.
cat /boot/loader/entries/test.conf 

title Fedora (TEST) 31 (Thirty One)
version 5.4.10-200.fc31.x86_64
linux /vmlinuz-5.4.10-200.fc31.x86_64
initrd /initramfs-5.4.10-200.fc31.x86_64.img
options $kernelopts maxcpus=1
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel

So, no re-configuration with grub-mkconfig is needed.

BTW: A human readable version of Kernel’s docs in html, comrades (courtesy of Arch Linux).

I’m not sure how to get the existing facility to create two menu entries automatically per kernel installation.

There might be a way to store an additional variable in grubenv, so that you can more easily manage two sets of boot params. Right now grubenv is only 1KiB. Not much. But it might be just enough.

Also, it’ll be a bit klunky because the current design has a new way of things but also with some backward compatible behavior. It’s really easy to get confused with myriad interfaces.

Before getting into that, can you post:
cat /etc/fstab
cat /etc/default/grub
cat /proc/cmdline
grub2-editenv list
efibootmgr -v

Basically I wanna know how things are currently arranged.

Also, if you have a swap partition, do you use hibernation? The resume command takes up space, so I’m pre-plotting getting rid of it if you don’t need it. :slight_smile:

The Idea, I got it from: Howto/Optimus - RPM Fusion

Proprietary/FLOSS switch

At this time, this can be done by manually editing "rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1" from the grub2 cmdline. 
And replace by "rd.driver.blacklist=nvidia,nvidia_drm,nvidia_modeset modprobe.blacklist=nvidia,nvidia_drm,nvidia_modeset" 
The plan is to have a grub2 menu to have the choice. 
Please see Bugzilla [RFE] Switcher for Xorg nvidia/FOSS config

So based on that link at the end:

But I don’t think those bugs are implemented

Grub menuentry’ are bad: They are legacy.

Please, see this (Changes: BLS by default), and examine /boot/loader/entries/.
See also a FedoraMagazine’s article (Setting a Kernel command line arguments with F30).

🛸️ optional joke

No! Please, dont do this!!! NOOO!

1 Like

Thanks, but I can’t find a way to add a new entry with Grubby right?

: ( No, i did not researched anything about grubby.  I’m did:

# it seems to no longer be a part of `dnf-plugins-core` package
dnf install python3-dnf-plugin-post-transaction-actions

I’d read the man 8 dnf-post-transaction-actions, and keep reading;  I’m try to achieve things done automatically at every kernel.* install and upgrade.  I’ll post when done.  Your can try to do it too, as me neither smart nor fast.

PS:  We’ll need clean-up script too.

OK (Happy testing i’m tested it. :stuck_out_tongue:) :

Step 1: install plugin for DNF

dnf install python3-dnf-plugin-post-transaction-actions

Step 2: copy / create script
(it's useless as stand-alone)

Fill cmd_line with your desired options…


#! /bin/sh
# after kernel installation / upgrade, etc...
# this script will be started by dnf plugin "post-transaction-actions"
# script will create a new file in /boot/loader/entries

# should be replaced with option(s) of your choice.

# Name, Epoch, Version, Release, Arch.
# There  we take Version, Release, and Arch
# They will be passed to this script by dnf plugin in step 3

# It distinguishes our entries from distro-provided

# sed have good manuals all over the Web.
# shortly, we have 3 expressions (grouped between \( \) pairs):
# 1) anything occured between 0 and any times, ended with "
# 2) anything occured between 0 and any times, in the middle
# 3) anything occured between 0 and any times, started with "
# we take the resulting whole and strip 1 and 3 out.
# from:   PRETTY_NAME="Fedora 31 (Workstation Edition)"
# we get: Fedora 31 (Workstation Edition)
# to insert in our entry's title
	cat /etc/os-release |\
	grep -i pretty_name |\
	sed 's@\(.*"\)\(.*\)\(".*\)@\2@'`;

# this is used for some reason with distro-provided entries.
machine_id=`cat /etc/machine-id`

# this is a name for a file that will be created
# in /boot/loader/entries to store our settings

# this is a cleanup part; When we'll delete an kernel.* package,
# the file matching this kernel will be deleted from /boot/loader/entries
# dnf plugin will pass -del argument to this script at every kernel deletion / downgrade
[[ ${1} == "-del" ]]\
	&& { rm /boot/loader/entries/${file_BLS_name}; exit; }

# our entry contents; double quotes in bash and alike allow us to use variables
s="title ${os_pretty_name} (${our_feature}-${our_NEVRA})\n"

# += means "append" here; \n can be converted to newline char
s+="version ${our_NEVRA}\n"
s+="linux /vmlinuz-${our_NEVRA}\n"
s+="initrd /initramfs-${our_NEVRA}.img\n"

# \$ -- backslash prevents interpretation of $ sign as variable sign.
# we need to leave it as it is in BLS entry file
s+="options \$kernelopts ${cmd_line}\n"
s+="grub_users \$grub_users\n"

# was in distro-provided file
s+="grub_arg --unrestricted\n"
s+="grub_class kernel"

# -e flag converts \n to newline characters.
# > overwrites file (or creates one) with new contents.
echo -e ${s} > /boot/loader/entries/${file_BLS_name}
# grant this file rights to be executed
chmod u+x /boot/loader/entries/

Step 3: create an .action file

Warning: each statement should be on 1 (one) line! No \ (mirror) or such!

kernel.*:in:v=${ver} r=${rel} a=${arch} /boot/loader/entries/
kernel.*:out:v=${ver} r=${rel} a=${arch} /boot/loader/entries/ -del

I think that you should do add a new menu entry in the file /etc/grub.d/40_custom you can copy the original entry from the file /boot/efi/EFI/fedora/grub.cfg you can use simply cat /boot/efi/EFI/fedora/grub.cfg > ~/my_grub.txt and you can copy your entry into the file 40_custom where you would change only the boots parameters and you should after regenerate the grub. with grub2-mkconfing like indicated in wiki fedora.

Your problem is how your parameter are expressed because they are referenced to a blacklist file what should be generate as i.e. etc/modprobe.d/blacklist.conf but when you will try regenerate your initramfs both nouveau and nvidia will be place in the blacklist. I think you should in place use directly as parameter nvidia.modeset=0 nvidia-drm.modeset=0 and so On and it should be the same to nouveau using the modeset=1 or 0

The explain about create menu entries and all that i did comment can be find here:

You don’t should try it directly first try it in a virtual machine because there sure is something in your boot parameters that is not going to work exactly like you think because the motive of the initramfs and the reference to a blacklist.conf, you should check fix the modeset=1 or 0 to the module.


Hello @revolucion09,
Have you reviewed this manual (the F31 Sys Admin guide) which details how to do just that with Grubby and Grub2.

I’m sorry: How TS can ensure with this manual that every time the Kernel get updated, there will be 2 options-clones, automatically added ones, which difference will be only cmdline args?

Not even mentioning the fact, that BLS is the modern default in Fedora.  The GRUB entries are legacy.

BLS is merely a specification, not a boot loader. On a UEFI system, personally I would be looking at using systemd-boot instead of Grub2, since BLS on UEFI is much simpler than BLS on SMB BIOS. As for automatically updating, the update will keep current system arg’s/karg’s, that is of the currently booted kernel, in order to keep the second option menu entry, the number of grub menu entries retained needs to be changed in /etc/grub.d/‘appropriate script’, as well it should be set to be default always. On your Fedora install there is also a very detailed Grub2 manual (file:///usr/share/doc/grub2-common/). AFAIK, if you want to keep custom settings, and this seems to be NVidia related in this case, make them to your default boot selection so at update time, the settings remain intact.
In any case, reading the related documentation cannot hurt, and will likely help. Grub2 is here for awhile I am sure, so embrace it.

Look… post #8.

How to achieve the same with this manual?  Show it off, please.

The needed result (configured once, and automatically achieved forever):

menu A: `linux vm-5.4.14_or_any_other def-options`
menu B: `linux vm-5.4.14_or_any_other def-options + additional_ones`

PS:  In any case: take a note how me was able to achieve the desired result with a modern tools (without touching the grub), while i’m unable (incapable, not so smart, blah…) even to read up the manual your’d pointed me to (it’s to boring)!

RE: grubby since Fedora 30 is not the real grubby, which is now the grubby-deprecated package. The new grubby is a somewhat limited script intended to provide a familiar grubby interface for people who know grubby, but with all the new BLS support. Since I only very rarely used grubby(-deprecated) or the new grubby, I can’t really speak to whether it’s useful for this use case.

What i can tell you use the relationship between some of the parts.
grub2-mkconfig reads /etc/default/grub for some variables to use when creating, grub.cfg. It will also reset the $kernelopts variable. That variable is used by each drop in snippet found in /boot/loader/entries, rather than each entry containing those options - this is a Fedora specific behavior, it’s not found in either upstream GRUB (which still doesn’t use BLS), nor in the upstream boot loader spec.

So yeah, it’s more than a bit confusing. Do you want to do things the GRUB upstream way, or the BLS upstream way, or the Fedora way, and now you have to become reasonably familiar with all of them in order to answer that simple question, making it not that simple.

One possible idea:

  1. Edit /etc/default/grub GRUB_CMDLINE_LINUX= to contain your “primary” boot parameters.
  2. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg (I’m assuming UEFI)
  3. grub2-editenv list should show the kernelopts= variable, pretty much matching what you have in /etc/default/grub.
  4. Copy that kernelopts variable, modified with your “secondary” boot parameters
  5. Paste it into this command
    `grub2-editenv - set kernelopts2=“pasted parameters in quotes”
    Yes that is a minus symbol, it’s a reference to the default grubenv path.
  6. Duplicate each of your /boot/loader/entries drop in scripts, and in the duplicate for each one, modify the line such that:
    s/options $kernelopts/options $kernelopts2

So now you have two bls drop in scripts per kernel. One references $kernelopts, the other references $kernelopts2.

A variation on that idea:
If the two sets of boot parameters have a lot in common, you can make the “primary” boot parameters in /etc/default/grub contain what’s in common; thus grubenv $kernelopts contains what’s in common. And now you can add extra values to the drop in bls snippets, e.g.

`options $kernelopts systemd.loglevel_debug

NOTE: Since grub2-mkconfig will step on grubenv, your kernelopts2= variable might also get stepped on, I’m not sure because I haven’t tested whether the entire grubenv is replaced, or if just the kernelopts= line is modified.

NOTE2: These days I pretty much don’t modify /etc/default/grub and don’t run grub2-mkconfig anymore. I just directly modify the /boot/loader/entries if necessary; or change the defaults (the variables) in grubenv by using grub2-editenv - set variable="blahblah"
And that also includes changing the default kernel if I need to do that for some reason.

1 Like

Glad my question spawned a discussion :slight_smile: However I am such a newbie at this level I think I’m gonna pass attempting this. Thank you however all

I never inferred, nor assumed any thing of the sort regarding your intelligence. Reading manuals, being technical topics and all, are boring often times since the content is so full of facts.

Sometimes the docs so full of facts that i’m yet not saw any sane step-by-step instruction on GRUB.  Ideas are present in this topic, but no solution (except my from post 8, which i’d tested).

Regards :slight_smile:

joke: post #14: “grubby since Fedora 30 is not the real grubby, …”
— Breaking news!!!

Well, that is no revelation to say the least. Grubby was relegated to a script after adoption of BLS by Fedora, although that road didn’t begin with BLS. Boot loaders have always been problematic in the Distro realm. It was largely the drive of non other than Torvolds and Co. who wanted to have a unified approach to booting the linux kernel, that was distribution agnostic, which ushered in the Spec we now know as Boot Loader Specification. In any case, you are free to choose how your machine loads the various bits and pieces to get to a usable state, that is entirely an expression of the point of “Freedom First” in Fedora.

Boot Loader Spec comes from systemd-boot, which was once gummiboot.

Fedora has a varation on BLS, that brings in variables from GRUB. It’s more reliable than grubby, which by the way has no relationship with GRUB. But there’s still room for improvement.

Yes I understand Grubby had no relation to Grub, I lived with LILO in the early days. And I thought it was from like it states here. In any case, I am jealous that I still have a BIOS machine and cannot use it effectively.