Addressing the new grub delay



Since we have adopted grub as overlay package, two issues have come up:

  1. Grub-install and especially update-grub have gained a massive delay when used in chroot. In my tests it has been about 5-6 minutes, but other manjaro-architect users report Grub-install hanging for up to 20 minutes. Since grub is our default bootloader, this seems rather unfortunate issue.
  2. Grub in the repos doesn’t support zstd-compression, even though mainline grub already does.

Number 1 is more pressing of the issues. I haven’t seen any calamares reports about this, so it might not have hit the isos yet. Or, calamares might use some other type of grub installation process.

I opened an issue about this, but I’m not sure if it is the right place for it. @guinux and @philm, how can we get this fixed and how can I contribute?

Manjaro freezes during installation at 89%

The issue seems more related with os-prober than grub itself.
I personally experienced this every time it ran when I had a dual boot with Fedora.


The ISOs are spun up less frequently then the packages are updated. If the ISOs are not experiencing this behavior, I would wait to release 18.0.3.


Yes, 80% of the delay seems to come from os-prober. However, the delay has increased at least by 800% since last September. It was always bad with lvm+luks, now its bad even without them and much worse with them.

Well, os-prober is in bash, so I can take a look at that…


It might be worth testing with an unpatched/non-Manjaro GRUB to make sure it’s something we’re doing, then bisecting the various patches (e.g. removing the grub-quiet stuff).


I experienced the same delay with the arch iso, specifically the 01-01-2019 version. Upon executing a grub-mkconfig command in a chroot environment, it cycles through all the partitions TWICE and echoes a warning after each partition (can’t remember the exact wording). Thus, the more partitions/drives one has, the longer the delay.


it will be very difficult to try to solve this for os-prober
because all grub scripts in each DE are different ,

even in the case of more DE Manjaro , time are increased to determine and check type of any filefs for each partition

see this topic


Oh, that’s excellent news. So if we are lucky, we might get away with just updating the package. And if not, we can check how arch did it and follow them.

Thanks, I know how complicated os-prober is and am not looking forward to patching it with any degree of enthusiasm. But if someone needs to do it, it might as well be me.


I did some partial troubleshooting on the os-prober issue here:

The TLDR version is that the whole delay comes from this statement:

VM_SUPPRESS_FD_WARNINGS=1 log_output lvs --noheadings --separator : -o vg_name,lv_name 2>/dev/null | sed "s|-|--|g;s|^[[:space:]]*\(.*\):\(.*\)$|/dev/mapper/\1-\2|"

It is worth noting that my install did not include any lvm partitions.


same error lvmetad in archlinux forum and an explanation and fix ? in other subject


Particularly good is this :

Despite the upstream change, there’s a way to fix it during installation. That is provide /run/lvm access to chroot environment. See this post … n-lvm-disk

Also can limit access to only /run/lvm:

mkdir /mnt/hostlvm
mount --bind /run/lvm /mnt/hostlvm
arch-chroot /mnt
ln -s /hostlvm /run/lvm

I think it’s better to be added in arch-chroot script.

Manjaro freezes during installation at 89%

Seems like the likely culprit. So, best fixed in manjaro-chroot. Thanks!


Sorry about the misinformation. I made a mistake on my test and didn’t install os-prober before running grub-mkconfig.

Anyway, I went back and checked my test vm. There is still a delay in the newest arch iso. The warning message is:

Failed to connect to lvmetad. Falling back to device scanning.
Device /dev/loop0 not initialized in udev database even after waiting for 10000000 microseconds.
Device /dev/sda  not initialized in udev database even after waiting for 10000000 microseconds.
Device /dev/sda1 not initialized in udev database even after waiting for 10000000 microseconds.
Device /dev/loop0 not initialized in udev database even after waiting for 10000000 microseconds.
Device /dev/sda1 not initialized in udev database even after waiting for 10000000 microseconds.

This is on a test vm with only 1 drive /dev/sda and only 1 partition /dev/sda1. No swap partition.


What about following the above method?


I can confirm that it works on the test arch vm.


I started coding for a solution. I seems that problem is being compounded by grub-mkconfig running multiple times. At first, basestrap installs grub, and installation hangs for 4 minutes in Generating grub.cfg.example config file...

Then, it runs again on grub install.

I found out that it might not be very straight forward to implement the fix in manjaro-chroot, so I’ll see if I can do it easier in manjaro-architect first…


Okay, my current solution managed to bring down grub installation time from 8 minutes to 3. And that includes a mknitcpio call to remove the fsck hook if grub is used.

Grub was always slow, but now it seems on bearable levels. Uploaded the fix to gitlab. Rebuilding manjaro-architect-dev later for testing.

EDIT: now uploaded to unstable repos.