Grub Update Hangs - Takes 10+min To Generate

Whenever there is a kernel update or if I manually update Grub via “sudo update-grub” or via “grub-mkconfig -o /boot/grub/grub.cfg”, the update hangs on this line: Found initrd fallback image: /boot/initramfs-4.9-x86_64-fallback.img
System is UEFI, with Windows, Arch, and Manjaro installed. Arch’s Grub updates fine, only Manjaro’s hangs. I had a problem before and reinstalled Grub on Manjaro, and this has been the result ever since the re-installation. Everything works fine, it just hangs on that one area. The end result is this after about 10min:Generating grub configuration file ... Found background: /usr/share/grub/background.png Found linux image: /boot/vmlinuz-4.9-x86_64 Found initrd image: /boot/initramfs-4.9-x86_64.img Found initrd fallback image: /boot/initramfs-4.9-x86_64-fallback.img Found Windows Boot Manager on /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi Found Arch on /dev/sda5 done
I verified that OS-Prober is installed and that efi-tools are installed. Grub has a config file. Not sure why it is hanging on that one area.

Well … are you using the same kernel for arch and manjaro ?
I mean are they both using their own versions of 4.9 and/or do you have a single 4.9 they both use ?
The first one could be causing oddities … the second one should not be the case at all.
(we dont use stock kernels direct from arch… they are not ‘mixable’ in a stable way)

Individual Kernel for each distro, both are 4.9 LTS. Arch is located in /boot. While Manjaro is in /boot/efi.

Here’s the way it looks. First is /boot (arch) second is /boot/efi (manjaro):

seems you’re using systemd for arch and manjaro uses grub

systemd works with either AFAIR - not that I know how to fix it - but I could be a starting point

I have the same problem on mbr. Grub update used to take over 7 minutes to finish, while in fedora and ubuntu it took only a few seconds. After I completely removed my windows partition then the update-grub time is about 3 minutes. So, if you remove windows partition the time will be significantly less. Who needs windows anyway? :stuck_out_tongue:

Grub update is slow on arch too, but I think it’s worse on manjaro. It seems like something is slowing it down.

I use Arch’s Grub, I wonder if I can just remove Manjaro’s Grub and only use Arch’s and/or Refind. Would that solve the slow upgrade on Manjaro’s end? Again, this all worked fine until I messed around and had to reinstall Manjaro’s Grub.

I really don’t know but @gohlip knows a lot about it.

Sorry, I don’t know enough about rEFInd especially when Annoyingduck had (maybe earlier) set rEFInd as default bootloader for all OS including for windows which is not installed with rEFInd either.

To have Manjaro grub now becoming the default bootloader after all these ‘processes’, I’m not sure how that’ will turn out especially if we don’t know what’s in each OS’s fstab, mounted /boot/efi or /boot or windows @sda2 entry. Sorry.

ps: and yes, Manjaro’s os-prober is slower than others but not 10 minutes.

1 Like

On my single-install machine with 2 kernels available it takes less than 8 seconds to complete a ‘sudo update-grub’

It was the same on this machine. My Arch Grub takes a few seconds to update, Manjaro used to be the same way. Now it’s not. It all happened after I reinstalled Grub in Manjaro. And again from the first post, it only hangs on the fallback image line. My other machines that have Arch/Manjaro are all working fine, both use the same lts kernel series, so it’s not a conflict of interest with the kernel. There must be some config, or file that is not in the right location causing this update-grub action to hang in Manjaro.

You could make a comparison of /boot on the working vs. the non working - then you might find the answer.

I’m guessing that Annoyingduck uses (or used) rEFInd on Arch, did not install grub on Manjaro (maybe later on install back) and redid his Windows boot. I guess that because he had a refind.conf, probably no manjaro directory in that /boot/efi/EFI/ and a presence of bootmgr while booting in uefi. But since we don’t know and with little to go on, it is difficult to proceed. We will need what his manjaro’s and arch’s findmnt /boot or /boot/efi, etc/fstab and what his windows is actually booted on. The setup is bizarre unless we know what is going on.

[edit] - If I were to mix $esp as /boot (say refind) and $esp as /boot/efi (say grub2), I’ll have separate $esp’s; which I have for bootctl and for grub. I won’t have the same $esp as both for /boot and for /boot/efi.

1 Like


have you seen this? Grub install (grub-mount) stuck for several minutes (with Antergos dual boot)

I had a similar problem and found a workaround: mount Antergos (or Arch in your case) partition before running update-grub.
It is not a true solution (that’s up to the devs), but it takes away the 12 minute extra wait in my machine. Hopefully it helps.



That solved the issue…thanks for the link. So yeah, guess it’s an issue with os-prober. It’s strange how that it works fine on Arch without mounting Manjaro, but on Manjaro I have to mount Arch.

That is not strange at all

  • your Arch boot files is not located at the same level as Manjaro

Which is why Manjaro don’t see your Arch boot files.

You could probably solve it by moving your boot files to the same level as Manjaro and of course modify your boot instruction files accordingly.

There are more news in that other link, please take a look there:

So, as with Antergos, maybe installing the lsb-release package into Arch could help, and no pre-mounting workaround would be necessary. Hopefully this helps!



I can confirm that installing lsb-release within Arch solved the issue with updating Grub. Thanks again for the find. I’m actually wondering if this is something that should be linked in the Wiki as general info for multi-boot Manjaro installations.

1 Like

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

Forum kindly sponsored by Bytemark