Enabling kernel parameters on GRUB for all entries

Hi all,

I am currently using EndeavourOS’s GRUB to boot into another partition, being a Gentoo install. I need to enable the kernel parameter nvidia_drm.modeset=1 in order to enable PRIME Synchronization on my monitor.

According to the article on the Arch wiki, I can do this by editing the GRUB_CMDLINE_LINUX_DEFAULT variable in /etc/default/grub, adding the nvidia_drm.modeset=1 to the string and re-generating the grub.cfg file.

However, when I boot into my Gentoo install and enable PRIME Synchronization with xrandr, it does not work (no error output, it simply doesn’t enable it), meaning the kernel parameter nvidia_drm.modeset=1 is not set properly.

If I were to set nvidia_drm.modeset=1 manually within grub, by pressing e and editing, it works properly. However I’d have to do this every single time I boot into Gentoo, which is not ideal.

It’s been a long day and I’m running out of ideas. Anyone know what I’m doing wrong? Help would be super appreciated!

This is not something I have tested but it might work.

You could try to make grub to chainload (launch) the grub.cfg of your Gentoo install.

First, add the kernel parameter you want in Gentoo (adding it in /etc/default/grub and regenerating the grub.cfg).

Then in EnOS, in /etc/grub.d/40_custom, add something like the following:

menuentry "Gentoo grub.cfg" {
set root = 'hdM,gptN'
configfile  /path/to/grub.cfg/in/Gentoo
}

Adjust the values of M (starting from 0 for the drive) and N (for the partition) and path (for the real path where grub.cfg is located in Gentoo).

Now regenerate your EnOS’ grub.cfg.

As said before, I have not tested this but perhaps you want to look into it and “polish” it up to work.

Edit: I did test the above on a dualboot system. I don’t seem to get it right. Either the idea is wrong or its execution. Or both :blush:

1 Like

Don’t know if the typo is only in this forum but it should be nvidia_drm.modeset=1 with an underscore.

1 Like

@pebcak I’m not skilled enough to see where it goes wrong, but the effort is still appreciated! :smiley:

@Svartis You were totally right in saying this, my bad. I’ll go ahead and correct my post.

So, I took a look inside grub.cfg and sure enough, the nvidia_drm.modeset=1 parameter was only being set for the two EndeavourOS entries (EndeavourOS and EndeavourOS fallback initramfs), but not the third Gentoo entry. So… I simply added the parameter there myself.

I’m not sure if this is something I should be doing but hey, it works. I’m convinced it’ll be overwritten next time I regenerate my grub.cfg, so I guess I’ll have to remember to re-add it manually.

I’m not sure if I just messed up my GRUB by doing this, or in case someone knows a better method, so I won’t mark this as the solution just yet. Cheers!

Another option which may work would be the following:

In Gentoo, set the kernel boot parameter and regenerate its grub.cfg.

Make Gentoo’s Grub bootloader primary , that is give it the first boot priority.

Make a custom.cfg in /boot/grub (or is it /boot/grub2 in Gentoo?) and copy over the two entries from EnOS’s grub.cfg with the right boot parameters.

This should give you boot entries for EnOS in Gentoo’s grub boot menu and won’t be overwritten by future updates to the Grub.

If yours is a UEFI system, changing bootorder is as easy as going into firmware/bios settings and set Gentoo’s bootloader first. This can be done from within Gentoo as well using the CLI tool efibootmgr.

If you are hesitant about anything or have further questions, feel free to post about it.

1 Like

Sorry my intention was not to blame you for a typo :grinning:, I thought the typo could have been the cause for your described problem.

1 Like

Well I think I have to apologize.

I’ve just noticed, that the only source mentioning nvidia_drm.modeset=1 is the official Arch Wiki (https://wiki.archlinux.org/title/NVIDIA#DRM_kernel_mode_setting)

But every other source I’ve found mentions nvidia-drm.modeset=1 as the correct entry.

I’m confused myself now. :thinking:

I think both are OK.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.