Addressing the new grub delay

grub

#1

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%
#2

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.


#3

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.


#4

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…


#5

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).


#6

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.


#7

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


#8

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.


#9

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.


#10

same error lvmetad in archlinux forum and an explanation and fix ? in other subject https://bbs.archlinux.org/viewtopic.php?pid=1820949#p1820949


#11

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
https://unix.stackexchange.com/question … 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%
#12

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


#13

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.


#14

What about following the above method?


#15

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


#16

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…


#17

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.