Grub takes very long (several minutes) to open Menu

You haven’t posted actual info on your setup, but nevertheless…

Quick/short answer:

  • Boot to Manjaro
  • Install Grub to the drive Manjaro is installed and update-grub
  • Set this drive in BIOS as 1st boot
  • Don’t use other drives’ Grub for booting

You may do more things “playing” with other installations, but always update-grub from Manjaro after any relevant changes on other installations and always use Manjaro Grub for booting.

It’s another distro issue, so even if we can make a search an assesment on this, it is not fair for other distros support. They need to make a living too… :laughing:

2 Likes

Then you have to forget about

For now all i have seen is Linux Mint …

1 Like

All you have seen is Mint, because this is where I’m coming from. But Mint does not support KDE anymore, so I am in the process of shifting to Manjaro.

You suggest:

I did all this and it lead to the situation, where I had to wait for about 2 minutes for Manjaros Grub to open its menu.

And the file I posted with the 10000 lines of repetition … it is Manjaros file.

1 Like

Provide

lsblk -f

You can answer this later.
To 00000000-0000-0000-0000-000000000001?
And why? Why do you feel the need to change UUID?
Changed fstab (in LM) after that?

2 Likes

Thank you for taking the time!

sdb                                                                        
├─sdb4 ext4    Daten_SSD              11111111-1111-1111-1111-111111111114 /media/Daten_SSD
├─sdb2 swap                           11111111-1111-1111-1111-111111111112 [SWAP]
├─sdb3 ext4                           11111111-1111-1111-1111-111111111113 
└─sdb1 ext4    SSD_System_I           11111111-1111-1111-1111-111111111111 /
sr0    iso9660 Boot-Repair-Disk 64bit 2017-10-29-00-56-18-00               
sda                                                                        
├─sda4 ext4    HDD_System_II          00000000-0000-0000-0000-000000000004 
├─sda2 ext4    Daten_HDD              00000000-0000-0000-0000-000000000002 
├─sda3 swap    Swap                   00000000-0000-0000-0000-000000000003 
└─sda1 ext4    HDD_System_I           00000000-0000-0000-0000-000000000001

And to your questions:

And why? Why do you feel the need to change UUID?

Because doing a lot of cloning with different methods etc … and sda vs. sdb always switching … I just couln’t remember those UUID’s until now.

Changed fstab (in LM) after that?

I forgot a couple of times … but in the end I did.

Ah… I asked a good question and good thing you replied.

Theres’ more when you do cloning than just changing uuid’s.
Theres’ a need to change host and hostname and perhaps a few other things if the clone and cloned remain in the system. {Installing a new OS (to me) is much faster, cleaner and less hassles}
But since I do not do much cloning (for these reasons), I may not be the best person to help out.
Good luck.

ps: remember to change fstab in Manjaro too, since you change the uuid as well.

{edit} - swap uuid - check /etc/default/grub as well. do update-grub after that.
And you just need one swap.

1 Like
  • How many entries are there for each installation in Manjaro Grub menu?
  • Which entry(ies) do you choose, when you have the delay?
  • Is the delay after grub selection, or before grub menu appears?
  • What is the delay, if you boot another time of the same grub and installation, if you leave the system work for some time (>10 min)?

Check for errors and info

inxi -SMCDPIxz
grub-editenv list
systemd-analyze blame
journalctl -b -p3
1 Like

Ah… good point. Our ‘new’ grub, that may pose a problem with cloning too.
:+1:

2 Likes

Thank you gohlip!
And thank you petsam for your time too!

Unfortunately I need to leave now and will provide the outputs tomorrow.

Just a quick reply to your questions:

How many entries are there for each installation in Manjaro Grub menu?

Two … one normal and one for advanced options.

Which entry(ies) do you choose, when you have the delay?

The delay is before the menu opens!

What is the delay, if you boot another time of the same grub and installation, if you leave the system work for some time (>10 min)?

The delay seems to stay stable all the time … except: The only thing which seems to increase it, is installing and updating grub anew. And it feels like an exponential increase, i. e. 2, 4, 8, 16 times longer each time I installed and updated grub. It never got shorter.

I have the suspicion that when grub updates, it somehow copies and pastes the grub.cfg’s of the other installations and therefore these thousands of repeating lines.

And yes, I did not change the host/hostname.

Since you need to leave now, it’s okay to reply later. I’m just writing ahead.
To fix grub (our new grub with all its paraphernalia) see somewhere here to clear up your grubenv and don’t forget to do ‘grub-install’. You must do this.
Good luck.

Just checking … you don’t have grub-customizer in either your clone or cloned? Or anywhere? Or in the past?

2 Likes

Hey guys …

I followed my gut-suspicion and it turned out that I was right.

The problem were the huge grub.cfg files. A normal one should have about 800 lines of code in a 4-OS-System. Mine had 42000 lines in the end. … and my system was almost not bootable anymore.

The solution (workaround) was to purge grub from all 4 Distros. Reinstalling is not enough, as it does not delete the grub.cfg’s. Deleting them manually and then reinstall grub also works.

The trick is, to purge them from all systems AT ONCE (!!!) before running update-grub on one of them. Otherwise it will copy the corrupted file from the other systems again.

Hey, petsam, I seem to be quite brilliant indeed, after all! :wink:

Ok, thank you guys for your time!

PS: Maybe this Problem has to do with what the GRUB Manual 2.02 says here:

Multi-boot manual config:

Currently autogenerating config files for multi-boot environments depends on os-prober and has several shortcomings. While fixing it is scheduled for the next release, meanwhile you can make use of the power of GRUB syntax and do it yourself.

you have not answered that, which is the most probable reason. Too many users multi-boot, though this problem does not exist to all, just to a few selected… :wink:

There is a simpler and easier way IMHO.

  • On each distro you boot, disable os-prober in grub settings
  • Copy one menu entry for each installation from /boot/grub/grub.cfg to /boot/grub/custom.cfg
  • Update-grub
  • After you repeat this for all installations, you may re-enable os-prober and remove custom.cfg

But… the same issue will show up, if you have grub-customizer and don’t know what you are doing (how things work for grub).

See you next time…:laughing:

1 Like
1 Like

Ah, @petsam, thank you very much for that! This looks like a much cleaner solution/workaround.

And, no, I’m 90% certain that I never had grub-customizer installed.

I am afraid, this will be sooner than you and I would like! :wink:

@SGS: … Wow … impressive!
And I am glad that I am not the only one with this exotic problem! :slight_smile: … Thank you very much!

@gohlip: … concerning Cloning: I think the hostname only needs to be changed, if the clone runs on a NEW host. Why else …?

And if you have a highly configured system, like I have, it saves many many hours of configuration-time to just:

  1. make a tar-ball
  2. throw the tar-ball
  3. modify the fstab
  4. modify the swap pointer (only if different)
  5. modify the hostname (only if different)
  6. modify grub

Altogether maybe 20 minutes for a completely configured and running Clone.

Oh, I forgot:

  1. Celebrate your victory over impermanence!

:balloon::balloon::balloon::sparkles::sparkles::sparkles::balloon::balloon::balloon:

Perhaps you’re right. hostname needs to be changed. I rarely clone but I changed host too when I do that. Maybe it wasn’t necessary, but I’m not sure.

Oh, can you tell us all the other OS’s you have?
To remove os-prober to speed things up seems ‘excessive’.
There were delays with manjaro os-prober (and update-grub) when there exists other OS’s like Arch and Antergos. And fixing them at their OS’s (lsb-release, os-release) will fix the problem. But I haven’t tested out with this ‘new’ grub we have.

But good that you have faster times from petsam’s solution.

1 Like

Not enough. Check for remaining files in /etc/grub.d

ls -l /etc/grub.d
2 Likes

@gohlip: In my case the other systems are 3 Mints.

And yes, I am very happy, that all works fine again. :slight_smile:

@petsam: Ok, here is the output:

$ ls -l /etc/grub.d
insgesamt 84
-rwxr-xr-x 1 root root  9791 Nov  5  2017 00_header
-rwxr-xr-x 1 root root  6258 Nov  5  2017 05_debian_theme
-rwxr-xr-x 1 root root  1180 Okt 25  2014 06_mint_theme
-rwxr-xr-x 1 root root 12552 Nov  5  2017 10_linux
-rwxr-xr-x 1 root root 11082 Nov  5  2017 20_linux_xen
-rwxr-xr-x 1 root root  1992 Jan 28  2016 20_memtest86+
-rwxr-xr-x 1 root root 11692 Nov  5  2017 30_os-prober
-rwxr-xr-x 1 root root  1418 Nov  5  2017 30_uefi-firmware
-rwxr-xr-x 1 root root   214 Nov  5  2017 40_custom
-rwxr-xr-x 1 root root   216 Nov  5  2017 41_custom
-rw-r--r-- 1 root root   483 Nov  5  2017 README

Your /etc/grub.d is not of Manjaro. :scream:
If that is from Manjaro, and you really want to fix to Manjaro.
remove this /etc/grub.d then reinstall grub package and grub-install and finally update-grub.
All in sequence and without shutdown/reboot while doing so.

If you can and don’t mind, can you tell us how you get to this grub?
My guess: you installed to manjaro from LM terminal by
grub-install --boot-directory=xxxx --bootloader-id=xxxx
And it is actually okay if Manjaro don’t mind. But trouble is while other OS don’t mind, Manjaro minds.

1 Like

Yes, gohlip, you are right, that was from Mint.

The one from Manjaro ist this:

$ ls -l
insgesamt 68                                                                              
-rwxr-xr-x 1 root root  8871 Nov  9 17:20 00_header                                       
-rwxr-xr-x 1 root root  1240 Nov  9 17:20 01_menu_auto_hide                               
-rwxr-xr-x 1 root root 12189 Nov  9 17:20 10_linux                                        
-rwxr-xr-x 1 root root 11467 Nov  9 17:20 20_linux_xen
-rwxr-xr-x 1 root root 11897 Nov  9 17:20 30_os-prober
-rwxr-xr-x 1 root root   214 Nov  9 17:20 40_custom
-rwxr-xr-x 1 root root   216 Nov  9 17:20 41_custom
-rwxr-xr-x 1 root root  1219 Nov  9 23:50 60_memtest86+
-rw-r--r-- 1 root root   483 Nov  9 17:20 README

1 Like

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