Grub conflicts with grub-customizer

The duplication of entries is actually caused by GC itself, if you use it regularly, and possibly from different instances of GC installed in different distros.

It adds more and more os_prober entries in the grub that GC uses, so your update grub command repeats itself and generates duplicate entries.

This has been the case for a long time as far as I can recall. I was using GC around 2013 but after I understood the problems and that I was using GC to remove duplicates it itself was making, I stopped using GC around 2016.

4 Likes

Oh, if that’s true that means I’ve been doing stupid things for months.

I do have multiple OSs but only one has GC. I’m going to reinstall that particular OS because of multiple problems, and as I can’t, I also won’t install GC. If the entry duplication still persists I’ll update.

Yes, I understand that, but I’m not the only one having the entry duplication issue. If it’s GC’s fault I’ll dump it, since is the only reason I keep it. But if it’s not GC’s fault, GC it’s a way the problem could be fixed, so if the problem still exists in grub (which i doubt right now) it wouldn’t make sense to put GC as incompatible unless the issue is fixed, that’s the point I intended to make.

If you install grub-vanilla and grub-customizer, launching GC says you have to configure I-don't-know-right-now-what-variables, while launching GC with grub it used to just launch and be ready.

It’s about $DEITY-damn time.

yes.

Sorry to cut to the quick on this…

But it doesnt matter how much you stamp your feet about wishing grub-customizer didnt conflict with grub.
The fact is it does … it always has, at least in the sense of whether its compatible or dependable … it just wasnt literally listed as a conflicting package until sometime recently.
If you were to look around at old blog posts or the previous forum you will find all the data you need.

grub-cusomizer is crap software. dont use it. it doesnt work well. it breaks things.

if you must use it … then use it with some other grub … however you do it … you are on your own.

(PS - not seen a duplicate grub entry from manjaro in all the years I have used it…)

1 Like

@cscs This is what I got today after running regular update via Octopi (for some reason, Pamac didn’t show any updates, but that’s another problem):

Previously I had to use grub-customizer to fix this. I guess I’ll have to learn how to deal with grub.cfg (and lots of other files like 10-linux, 20-os_prober etc.) manually now.

2 Likes

Did we not already establish this is a symptom of grub-customizer ?

To be fair I dont know for sure … but from my view the correlation seems strong …

(and yes … now that you have used it … your grub is basically ‘broken’ and you have to ‘undo’ GC)

2 Likes

This - and to learn why these double entries could occur. :wink:

1 Like

Yeah, I’ve used grub-customiser before, but after today update I’ve got a lot of new useless boot options.
Grub-customiser was auto deleted, and now I can’t change boot initrd to add patch to repair broken suspend mode on by Ryzen 4500, niceeee.

did you read anything else here?
or are you just throwing in your hat to be counted
“me too! I also messed up my grub and made duplicate entries by using grub-customizer!” ?

niceeee.


are you sure?

grub-customizer lets you add ‘patches’? in what way?

how ? why ?

by ‘patch’ are you referring to a boot flag or something ?

1 Like

yeah I did
I’ve got that “it was my fault to use gui to make it easier” )

yeah, patching ACPI tablie (nns.ee/blog/2020/10/18/acpi-patching.html)

Do I understand correctly that now I need to edit /boot/grub/grub.cfg manually?

Many users in old forum reported having duplicate entries in GRUB, which AFAIK always related to use of grub-customizer
These comments are from 2016:

Grub-customizer - possible caveats
Grub customizer can cause a lot of issues because it’s editing the /boot/grub/grub.cfg directly, which is not recommended. Just edit /etc/default/grub and do sudo update-grub

Grub-customizer has a lot of quirks. It is probably less bother to just learn how to edit the grub default files than it is to learn what not to do in grub-customizer`

1 Like

That link is decently advanced … but everything in there is by hand … they dont mention grub-customizer.

Yes… but its already walked through in that tutorial.
You add initrd /dsdt_patch before any of the *initramfs*.img
(or more specifically probably something more like just /boot/dsdt_patch on the same line but right before /boot/amd-ucode.img)

The mem_sleep_default=deep part goes in the normal CMDLINE options in /etc/default/grub

And of course you need to regenerate things using sudo update-grub.

(this can also be automated using scripting and such … see GRUB - ArchWiki)

PS.

This has nothing to do with GUI or anything like that.
Its simple - grub-customizer sucks. it should be considered broken and dangerous.

5 Likes

Ok, thanks, going to read archwiki to factory reset grub)

For some dummy like me, how I recovered grub after grub-customizer:

  1. remove all files from /etc/grub.d (backup them before)
  2. grub-mkconfig -o /boot/grub/grub.cfg
  3. to change (if you need that) initrd string in grub use GRUB_EARLY_INITRD_LINUX_STOCK (better GRUB_EARLY_INITRD_LINUX_CUSTOM) variable in /etc/default/grub and update-grub after changes
3 Likes

Why don’t you use

GRUB_EARLY_INITRD_LINUX_CUSTOM

Reference:
GNU GRUB Manual 2.04: Simple configuration

3 Likes

If you use UEFI you can use “efibootmgr” in a terminal.

This is the help

usage: efibootmgr [options]
	-a | --active         sets bootnum active
	-A | --inactive       sets bootnum inactive
	-b | --bootnum XXXX   modify BootXXXX (hex)
	-B | --delete-bootnum delete bootnum
	-c | --create         create new variable bootnum and add to bootorder
	-C | --create-only	create new variable bootnum and do not add to bootorder
	-D | --remove-dups	remove duplicate values from BootOrder
	-d | --disk disk       (defaults to /dev/sda) containing loader
	-r | --driver         Operate on Driver variables, not Boot Variables.
	-e | --edd [1|3|-1]   force EDD 1.0 or 3.0 creation variables, or guess
	-E | --device num      EDD 1.0 device number (defaults to 0x80)
	-g | --gpt            force disk with invalid PMBR to be treated as GPT
	-i | --iface name     create a netboot entry for the named interface
	-l | --loader name     (defaults to "\EFI\arch\grub.efi")
	-L | --label label     Boot manager display label (defaults to "Linux")
	-m | --mirror-below-4G t|f mirror memory below 4GB
	-M | --mirror-above-4G X percentage memory to mirror above 4GB
	-n | --bootnext XXXX   set BootNext to XXXX (hex)
	-N | --delete-bootnext delete BootNext
	-o | --bootorder XXXX,YYYY,ZZZZ,...     explicitly set BootOrder (hex)
	-O | --delete-bootorder delete BootOrder
	-p | --part part        partition containing loader (defaults to 1 on partitioned devices)
	-q | --quiet            be quiet
	-t | --timeout seconds  set boot manager timeout waiting for user input.
	-T | --delete-timeout   delete Timeout.
	-u | --unicode | --UCS-2  handle extra args as UCS-2 (default is ASCII)
	-v | --verbose          print additional information
	-V | --version          return version and exit
	-w | --write-signature  write unique sig to MBR if needed
	-y | --sysprep          Operate on SysPrep variables, not Boot Variables.
	-@ | --append-binary-args file  append extra args from file (use "-" for stdin)
	-h | --help             show help/usage
2 Likes

Removing all files from /etc/grub.d and running your second command gives this:

Generating grub configuration file ...
Script `/boot/grub/grub.cfg.new' contains no commands and will do nothing
Syntax errors are detected in generated GRUB config file.
Ensure that there are no errors in /etc/default/grub
and /etc/grub.d/* files or please file a bug report with
/boot/grub/grub.cfg.new file attached.

I’m still unsure what to do about duplicate entries without grub-customizer. Any official info how to fix it, so it would be agreeable with Manjaro grub?

I have doubts. My grub is customized to use a certain background to be consistent with the plymouth and it works well, and I don’t intend to change it. Removing all files from this location probably will remove all customizations.

How to to edit grub entries manually without nuking the existing configs? I also am unsure if I should follow Arch wiki because Manjaro doesn’t ship with the default grub, so we are left with the non standard grub and no clear documentation how to deal with it.
Grub customizer was always the best way for me and it never broke my system which has been installed over 4 years ago. I only had this duplicated entries which were not a problem with grub-customizer. Now that it is gone, I have no idea how to fix it the way I want it.

Again, since Manjaro ships with non-standard grub, it should have GRUB CUSTOMIZATION docs on Manjaro wiki.

So in my case, this is how my /etc/grub.d looks like.

Which files are safe to remove, which aren’t? Which I can edit, which I rather not? Or maybe I shouldn’t change them manually at all? Which configs were problematic for Manjaro GRUB so it created duplicates during update? And so on. I have many questions and no clear answers.

I do see various tips in this topic, but… they are useless for average users as me. For example, info about using efibootmgr… I simply don’t understand it at all.

The question seems to be simple. How to remove duplicate entries? It could be temporal solution like in grub-customizer or permanent one (the way it is supposed to be done on Manjaro super confusing, super different for no clear reason GRUB).

At the moment, removing compatibility with grub-customizer gave more issues than before.

Also, as far I remember, the duplicate entries were happening without grub-customizer and this was the first reason why I seek and installed grub-customizer in the first place. Maybe that changed and the fix became the problem but from a user perspective, this issue existed and exists since over 5 years I’m using Manjaro and it was never properly addressed. It was only said “not to use grub-customizer” but never gave any documentation and answer how to fix it easily without it.

Manjaro is aimed for not overly technical users that still want to have control so it’s natural we try to use easy, user-friendly programs as grub-customizer. If you find it to be problematic, the solution is not to block such software, but provide the alternative on the same level that would work with Manjaro GRUB correctly. Or maybe get rid of the customized grub on Manjaro, because it seems to be the source of the issue. Why Manjaro has customized grub in the first place? What does it change?

2 Likes

You can copy/back up those folder / files into …/grub.d.old instead of deleting them.

The grub background can be set by editing as root the text file in /etc/default/grub.

You should see one of the lines as
GRUB_BACKGROUND = “path to file”

Change the path to the correct location , keep the quotation marks.

After you remove GC, you can do a sudo update-grub.

Unfortunately I can’t confirm what are the exact steps for removal of GC besides uninstalling the program and removing (with backup) the grub.d folder. You probably need to reinstall grub in order to get a fresh set of grub.d scripts unchanged by GC.

Note: if you reinstall grub package, I suspect that /etc/default/grub will be replaced as well, so make a backup first, and do your editing of said file after you have reinstalled grub package.

3 Likes

You’re an ‘old-timer’ from the old forums. You don’t remember/didn’t read the multiple threads about this very issue?