Grub conflicts with grub-customizer

Not really. All I recall that Manjaro had a customized GRUB without details of why. When I started using Manjaro, this has been that way.
Maybe there were threads discussing it but since the forum is too big to read everything, I maybe didn’t notice them.

1 Like

IIRC, the whole modified GRUB thing started because someone got a wild hair growing you know where, about making the quiet/silent boot…

Heh? Really? Isn’t this a part of the standard GRUB from a while now?

However, silent GRUB came probably 2 years ago, while GRUB on Manjaro was customized a way earlier and there wasn’t quiet GRUB for next few years so I’m not sure if that’s really a reason. All I recall was that the customized GRUB was something to watch out during multi Linux installations (Manjaro GRUB was handling also Ubuntu systems, but Ubuntu GRUB wasn’t detecting Manjaro, or maybe that was a version thing?).

1 Like

Might be (haven’t used GRUB for awhile now), but when this started for Manjaro it was not mainline/mainstream. Manjaro patched GRUB stuff from Fedora IIRC (it might’ve been Debian).

Doesn’t work :frowning:.
When doing sudo-update-grub I get the same error as someone from above:

and the /etc/grub.d/ is not populated with configs.

This is disappointing because there should be a huge announcement with info how to properly remove grub-customizer configs so it would all work well after the update. But:

  • there was no warning that this happens, just one day, we have to remove grub-customizer, and then you are left alone
  • no alternative software was presented
  • no documentation how to deal with after-grub-customizer systems.
  • no clear solution anywhere how to deal with duplicated entries

So the “SOLUTION” simply broke user space in order to fix it… Good job Manajro… :frowning:
However, it probably resulted from lack of imagination of what the consequences are for the users who used grub-customizer FOR YEARS! From my standpoint, it was fine before, now in order to fix an issue that was not-issue for me, I landed with an issue… It is possible that with some wild and massive GRUB customizations done by grub-customizer it had a potential to cause issues during updates, but most of us, grub-customizer users, did only minor changes, so it never conflicted with updates.

3 Likes

You have to reinstall grub package first, before editing the /etc/default/grub file. That will repopulate the /etc/grub.d folder.

Did you do that?

2 Likes

Ah, thanks! That did the trick. So the solution to clear install from grub-customizer and to get rid of duplicated entries:

  1. Rename:
    /etc/grub.d
    to
    /etc/grub.d.old
  2. Reinstall Grub 2
  3. sudo update-grub

In my case, customizations are in etc/default/grub config which stays, so nothing should change. I guess I will find out during a reboot, but after update-grub I can see that the duplicated entries are gone.

EDIT: All customizations stayed after the reboot. So all is good.

3 Likes

Errr… if you read the last sentence of my original post (added subsequently maybe an hour ago), I believe the /etc/default/grub file is also repopulated upon reinstallation of grub package. If the background doesn’t show up on your grub menu, just boot back in and edit the said file again. (then update grub)

For me the same config stayed.
Yeap, after the reboot I can confirm that my customizations stayed.

Excellent. :+1:

It’s a pity the old forum died and the saved contents were archived away. There were regular posts made advising against GC in the old forum. It’s not new info but users will use what they want to use, regardless. And with the old forum less convenient to access, the useful advice inside is usually not seen or part of people’s search process.

Yes, I seem to recall that that was what pushed me to installing grub-vanilla in place of grub package at that time.

Fedora’s grub since around F30 or 31 no longer automatically updated the grub.cfg whenever there was a new kernel, if you were on legacy MBR boot (which I am). At first I couldn’t even use the grub2-mkconfig command to manually update grub, until someone on the old Manjaro forum told me what setting in some root file (can’t recall which) to edit.

On my long-running Fedora install , I now have to manually use the grub2-mkconfig command after every update (which inevitably includes a new kernel), in order to update grub.

I remember being worried Manjaro would go down the same road, which is why I moved to grub-vanilla at that time. Now that I’ve shifted back to Manjaro’s grub package with the demise of grub-vanilla, let’s see. So far Manjaro hasn’t followed Fedora in that aspect yet. If one day it does, I’ll just get another distro to control grub instead.

I went the opposite route.

IgnorePkg = grub

And there it stayed until I decided to go with systemd-boot.

I first had double-entries from grub-customizer back in July 2016
long before silent boot, grub-vanilla or bootsplash

The developers on Launchpad do not respond very quickly to bug reports
These reports from Manjaro users still have no response
2020-04-30 - Bug #1876203 “Syntax error when saving on Manjaro 20” : Bugs : Grub Customizer
2020-10-02 - Bug #1898202 ""Failed saving grub configuration!"" : Bugs : Grub Customizer

the package is not even well supported for their upstream Debian
Bug #1612874 “Debian(pure) install throwing fit on higher versio...” : Bugs : Grub Customizer

At least in the last year all cases of double-entries in grub that I have seen in the forums have been caused by two things:

  1. Grub-customizer
  2. Kernel 4.19. For some reason Manjaro’s kernel 4.19 will make two entries for Manjaro.

IIRC, the problem with the duplicate entries caused by update-grub used to be fixable by simply re-running grub-customizer and re-saving the configuration. It might be necessary to add new/updated kernels to the menu before saving.

Grub-customizer requires extra manual maintenance whenever kernels are added or updated to any of the installed OS’s. (The extra steps are not necessary for Manjaro kernel maintenance releases, unless a kernel series is added or changed.)

The fix for “Failed saving grub configuration!” used to be to use the “reset” inside grub-customizer. Of course it is no fun to edit the menu again…

1 Like

I just wanted to thank you, been struggling with this for days since the last update, but this approach solved it!

My configuration seems to remain the same, after reinstalling and renaming the grub.d folder. Now I just wish there was a safe, CLI-friendly way to change the grub entries, should I ever need to customise them…

1 Like

How I would go about it:

  1. sudo cp /boot/grub/grub.cfg /boot/grub/grub.cfg.working

Make your changes:

  1. sudoedit /boot/grub/grub.cfg

If your changes seem to bork something, mount your boot partition from a live cd, then:

  1. sudo cp /boot/grub/grub.cfg.working /boot/grub/grub.cfg

Unmount, reboot and try again. :slight_smile:

2 Likes

if you want grub customizes, save yourself the hassle and just build it from source its a simple cmake . && make and a make install to do it, no need to ■■■■ around with grub vanilla. duplicate entries are just so much easier to deal with, using grub-customizer. especially when it’s not the cause of it.

1 Like

You’re free to do whatever you’d like.

However, doing so is unsupported and one does so at their own risk. Just a disclaimer for anyone reading.

is there any good alternative??

and can I change grub menu entry order?
and make it like, always the 1st entry boots