Best way to get custom.cfg to appear before the normal grub.cfg entries?

Continuing the discussion from [Stable Update] 2018-10-08 - Kernels, Gnome 3.30, Cinnamon, Deepin, Pamac, SPL/ZFS:

Requoting my first post in the update thread:

Not a serious problem for me, but I think grub has changed a little how it does things.

Update went fine but terminal text indicated that it couldn’t find the /etc/grub.d/41_custom script. That’s because a few months ago I did a


command to move 41_custom to 09_custom, so that my custom grub entries in custom.cfg would show up before the normal grub.cfg entries.

Anyway, when I rebooted my PC, I found my custom.cfg now appeared twice, once before the grub.cfg stuff and once after. This had never happened before in the upgrades the last few months since I moved 41_custom. So I logged in again and checked /etc/grub.d folder. Turns out grub recreated a 41_custom script for me, which is why I had duplicate custom.cfg entries.

Anyway, I removed 41_custom, but if grub replaces it again the next update, I’ll try removing the actual script content but leave the file there.

@gohlip, you said:

It will begin afresh, meaning without the old manual entry you put into it.
That’s why it is better to have manual entries in /boot/grub/custom.cfg.
Those entries will not be nuked, and can never change without user manual input and even if wrong will not disrupt your grub.

As to your old entries in 41_custom, note we had copied over to /etc/grub.d.old.
So if you still want it, it will be there. Copy back to your new grub.d/41_custom or as said, better in /boot/grub/custom.cfg

There are no manual entries in 41_custom. By default, 41_custom contains a script that looks for the custom.cfg file (which is where all my manual entries are), and if present, it loads it.

See this link,

which says of the custom.cfg file:

The /etc/grub.d/41_custom script will reference [the custom.cfg] file to be read in at boot time if it exists. This file [custom.cfg] provides a place to add additional entries or commands and does not require regeneration of the main grub.cfg file.

So #41 is the actual reason that we are able to add manual entries in a custom.cfg file and have it appear in grub menu without an update-grub.

Problem is that #41 will load custom.cfg AFTER the normal grub entries because “41” is a later number than the ones for the standard entries. By moving the script to “09”, I make custom.cfg appear BEFORE my normal grub menu.

One only needs to update-grub once for “09” to be incorporated. After that, I can do all my normal changes to custom.cfg and have them appear without updating grub.

The point is I don’t need both #09 and #41 doing the same thing, that’s what’s creating the double entries. Previously update-grub (or mkconfig) did not make grub recreate the missing #41, but this recent update of Manjaro, grub behaved differently when regenerating grub.cfg.

BTW, #41 is different from #40 script.

Yes. You are correct. I was confused between 40_custom and 41_custom.
The main point being , any manual entries should be put into /boot/grub/custom.cfg

And yes, you are also correct, by renaming 41_custom to 09_custom, it will move up these custom.cfg entries to the top as 09 is before 10, the OS linux entries.

Good that you clarify this confusion.
Thanks and cheers.

ps: now go nuke those grub and move 41_custom to 09_custom. :grin:

Until the next Manjaro update when mkconfig recreates 41_custom again and gives me double entries of my custom.cfg file? Troublesome. I’ll think about getting rid of the script within #41.

If you look at /boot/grub/grub.cfg, there is somewhere at the bottom, these…

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
### END /etc/grub.d/41_custom ###

Normally by just having entries in custom.cfg, these entries will appear at the bottom of the grub menu.

I understand you want these custom entries on top.
So you have tried to make a 09_custom in /etc/grub.d
As you know, I haven’t tried this (making 09_custom) or making custom entries on top.
(I use my own grub and this is moot (for me))

Without removing 41_custom and having 09_custom, these custom entries appear twice as you reported (once on top and once at the bottom (and which I am not aware because I don’t use it))

I can think of one way to make this on top.
Manually move the above ‘stanza’s’ to the top of grub.cfg.
(in kde nannying OS, we must use ‘SUDO_EDITOR=kate sudoedit /boot/grub/grub.cfg’ )

However note that whenever we do a new update-grub, it will revert to the bottom again.
I also think that with a new grub-install, your 09_custom will disappear as well.

Looks like either way, there is no permanent method to make the custom entries remain on top after update-grub or grub-install (and without double entries).

But if you choose to remove 41_custom, I recommend you keep a copy of these entries elsewhere.
And if you find a way to make it permanent regardless of grub-install or update-grub (and without double entries), please let me know. I will if something hits me.

Also, this may be a good time to share again with you how I do my grub without worrying which OS is in the bootborder. I think you have lots more OS’s than I, and it may be useful.

Cheers, wongs.

[EDIT] - To hide all other OS’s that is generated by os-prober, so that only the 10_linux appears (and together with custom.cfg). add this line to /etc/default/grub


You are mixing things IMHO. update-grub does not create files in /etc/grub.d/

the file 41_custom is part of grub package, so when grub PACKAGE is updated during system update, will not find the missing file and will re-create it. That’s normal.
I think you have overcomplicated things…

  • You can use a custom grub option, either in /etc/grub.d/, or in /boot/grub/
    • In /etc/grub.d/, use a custom cfg as `09_mymenu with your proper menu entry.

      *In /boot/grub/ use custom.cfg , copy /etc/grub.d/41_custom to 09_custom and edit 41_custom to disable the contents (commend out “#”). After each grub package update, there will be an 41_custom.pacnew (I guess…) you should merge, as with all pac.. files.

wongs, I missed this part.
petsam is right.
note any entry in custom.cfg will not be shown in ‘update-grub’ or in ‘grub-mkconfig’ or os-prober.
The entries will just appear when we boot up computer as the stanza’a in grub.cfg will pull in the custom.cfg entries. And that is why any wrong entry in custom.cfg will not foul up grub.

Thanks petsam for my missing piece.

1 Like

About my advised options, there is a downside/upside on 1st/2nd ways, IMHO. It’s the pacsave creation (if I am not wrong that they ''ll be created). If/when something trivial is changed in grub code, we will(not) be notified about a possible change, so we can accustom our custom.cfg.

That was my thought as well. Probably the most appropriate approach. Thanks.

And also thanks, gohlip for your usual helpful input.


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

Forum kindly sponsored by Bytemark