Grub install (grub-mount) stuck for several minutes (with Antergos dual boot)

I’m running latest Manjaro (unstable). I installed Antergos to another disk/partition for dual boot.
Now every time Manjaro gets an updated kernel, the grub install in pamac takes a very long time (about 5-10 minutes) to finish (but it eventually gets there, fortunately).
Htop shows that grub-mount takes nearly 100% of CPU time and there the installer is stuck.

I’ve installed some other distros as dual boot, but none of them ever created this problem.

Any ideas what is going on? Any ideas how to fix or work around this (besides removing Antergos)?

EDIT: Gohlip found that /etc/lsb-release was missing from Antergos. It is not installed by default in Antergos. So if you install lsb-release package in Antergos, the long delay in Manjaro’s update-grub is history. See more in post #31.

since the latest GRUB2 update ( some months ago …) I also have the same problem.
Recently had several “issues” with Grub2 but at the end I still have not solved the problem that It takes about 10 minutes to make the correct menu list.
At the end I am getting used to this time …

I have pinpointed the issue with the “Os-probe” grub script, processing full CPU for about 8 minutes.
But I have to ask:
Is your “Antergos” main Menu Entry being shown simply as Arch ?
With the “Antergos” Sub menu options with the correct names ?

Does your system have any HDD with GPT mode ?
Does GRub installed in the MBR or in a dedicated parttition / filesystem ?

What is is your “sudo fdisk -l” command result ?

In grub menu, Antergos main and sub menus appear with name Antergos, not Arch.
All disks are in msdos mode, not gpt.
Grub (of Manjaro) is installed in /dev/sda.
And I see nothing out of ordinary in fdisk -l output.

And htop show that the following process
grub-mount /dev/sdc1 /var/lib/os-prober/mount
is sitting there about 10 minutes with 100% of CPU resources.

@manaaja Even if you think it appears alright, provide

sudo parted -l
ls /etc/grub.d

Also do not modify any output or leave out anything from the commands.

parted -l:

Model: ATA SAMSUNG MMCRE28G (scsi)
Disk /dev/sda: 64,0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  1574MB  1573MB  primary  ntfs         diag
 2      1574MB  1679MB  105MB   primary  ntfs         boot
 3      1679MB  63,5GB  61,8GB  primary  ntfs
 4      63,5GB  64,0GB  537MB   primary  ntfs         diag

Model: ATA SAMSUNG MMCRE28G (scsi)
Disk /dev/sdb: 64,0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  21,1GB  21,1GB  primary  ntfs
 2      21,1GB  60,7GB  39,6GB  primary  ext4
 3      60,7GB  64,0GB  3348MB  primary  ext4

Model: ATA SAMSUNG MMCRE28G (scsi)
Disk /dev/sdc: 64,0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  64,0GB  64,0GB  primary  ext4

Model: ATA SAMSUNG MMCRE28G (scsi)
Disk /dev/sdd: 64,0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  64,0GB  64,0GB  primary  ext4



Disks: sda contains windows, sdb contains just data, sdc contains Antergos and sdd contains Manjaro.
/etc/grub.d/40_custom_my contains manually added grub entries just for ease of use.

So can you see something wrong in them?

I also noticed this, but only with distros that have their own, separate boot partitions, like Antergos or Fedora. It seems that for some reson it takes grub a lot of time to mount these partitions when looking for other OS-es.

Yes. Remove 40_custom_my from /etc/grub.d and put entries in /boot/grub/custom.cfg
Don’t forget to update-grub (because you modified /etc/grub.d, not because you created custom.cfg).

And why is 40_custom_my wrong? It has worked for me always with many other distros (including Windows), Antergos being the only exception. I think 40_custom_my has nothing to do with the problem. But for safety’s sake I’ll move it to /boot/grub/custom.cfg and try.

As I thought, moving /etc/grub.d/40_custom_my to /boot/grub/custom.cfg didn’t help.
The update-grub command is still stuck for about 10 minutes.

o install again grub, grub-install and update-grub

sudo pacman -S grub
sudo grub-install /dev/sda
sudo update-grub

Making sure you do not have 40_custom_my
You can leave the custom.cfg as is.

Didn’t help. update-grub is now again stuck with grub-mount.

Please tell me why you think /etc/grub.d/40_custom_my is bad.

  1. 40_custom_my is the same prefix as 40_custom
    their priority is the same and grub will not know what to perform first
  2. 40_custom_my will also need the appropriate headers as 40_custom that should not be removed otherwise there will be errors or delays in the operation
  3. /etc/grub.d should not be user modified as operations may be affected.
    And that’s why grub-customizer and grub-repair often results in defective operations.
  4. Any menu entry in 40_custom (or any user made custom dir) if defective or in error will cause unbootable grub menu
  5. More… but we can stop here now, right?
  6. Users should only modify /etc/default/grub, nothing else.


  1. custom.cfg on the other hand does not does not affect grub operations at all.
    It just gets pulled in by grub.cfg.

  2. And even if menuentry in custom.cfg is wrong or defective, it does nothing to grub operations or affect the boot in other entries in grub menu.


Now back to your delay.
Manjaro grub os-prober has been modified (to check for other distro’s intel-ucode) and in your case you’ve quite a few disks as well.

You can try to remove os-prober (and put back later) and see if “update-grub” has improved vastly. If it improves only marginally and delay is still pronounced, let us know. Something is still wrong.
If the delay is no longer there, then it could be Manjaro os-prober and there’s nothing we the users can do anything about it.

To remove os-prober, at /etc/default/grub, add this line


at terminal 'update-grub’
comment it out when you want to enable it and ‘update-grub’

ps: I need to say this as I may give the wrong impression (on Manjaro os-prober) if I don’t -
I disable os-prober but that’s because I’ve my own grub. But I can easily test any OS grub and its os-prober itself. I’ve no (big) problem with manjaro os-prober and I’ve lots of disks and lots of OS’s. But I don’t have Arch, Antergos or other Arch type OS’s that uses intel-ucode.

[edit] - please always double check that 40_custom_my is removed

Well, I have never had any problems with 40_custom_my, but I’ve no problem removing it. I didn’t know about custom.cfg, and that indeed seems to be a better place for my custom entries.

I removed os-prober and since it is no longer searching for other OSes, update-grub takes only 2 seconds. In comparison, with os-prober update-grub took 12 minutes.

By the way, Antergos is not using intel-ucode (not by default and not in my system either). So that is not the reason for this problem.

I googled this a little and it seems that there have been similar problems with grub-mount in other distros as well.
So it may be a general grub problem instead of a problem specific to Manjaro.

There is one right here and that’s because the whole disk is one big extended partition (no primary).
But since your grub works well without os-prober, we can conclude it’s something to do with os-prober; whether it’s the way manjaro os-prober is modified, we don’t know.

So let’s leave it here. At least custom.cfg works (fast) for you.
Take care.

Yup, os-prober seems to contain the problem.
The custom.cfg works as fast and well as /etc/grub.d/40_custom_my did, but seems to have some other advantages.

Thanks for your time and help!

1 Like

I just looked at os-prober source code and made some ad hoc experiments.

More or less accidentally I found out that if the Antergos partition is mounted before update-grub is executed, then the 12 minute delay problem doesn’t exist!

So the problem in os-prober must be somehow related to mount handling, it is not done properly. I didn’t look at it further, but left it as an exercise to someone interested and properly initiated. :wink:
I just made a simple script to work around the problem.

Hopefully this proves to be a useful observation to someone struggling with this problem.

Good! Then I suppose we have to find out why it took Manjaro update-grub such a long time to mount Antergos for the process. Perhaps there is something in Antergos system (not in Manjaro) that is the issue?

But good you found out.

My guess is that os-prober is somehow flawed, and the flaw is not specific to Manjaro nor Antergos. However, Antergos seems to use some features that the os-prober just doesn’t handle the right way.
The developers of os-prober (Debian people?) would be the right persons to study this further and solve it.
Anyway, currently I don’t have enough time to investigate it any further. Maybe later when I have more time. :slight_smile: