FS#41538 - [grub] grub-mkconfig takes too long

Attached to Project: Arch Linux
Opened by José Ribeiro (JKostaRibeiro) - Tuesday, 12 August 2014, 12:17 GMT
Last edited by Christian Hesse (eworm) - Tuesday, 02 August 2016, 07:44 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Ronald van Haren (pressh)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

On my arch box it takes too long to run "grub-mkconfig -o /boot/grub/grub.cfg". I have other linux systems where it takes MUCH less time.

Arch Linux:

# time grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/initramfs-linux.img
Found fallback initramfs image: /boot/initramfs-linux-fallback.img
/dev/cdrom: open failed: No medium found
/dev/sdc: open failed: No medium found
/dev/sdd: open failed: No medium found
/dev/sde: open failed: No medium found
/dev/sdf: open failed: No medium found
No volume groups found
Found Gentoo Base System release 2.2 on /dev/sda2
Found Fedora release 20 (Heisenbug) on /dev/sda5
Found Slackware Linux (Slackware 14.1) on /dev/sda7
done

real 4m43.755s
user 0m4.823s
sys 0m2.360s


It takes several minutes between "No volume groups found" and "Found Gentoo Base System release 2.2 on /dev/sda2".


Fedora:

# time grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found background: /boot/grub2/themes/system/paradise_beach-1920x1080.jpg
Found linux image: /boot/vmlinuz-3.15.6-200.fc20.x86_64
Found initrd image: /boot/initramfs-3.15.6-200.fc20.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-ba6ac4966b774ff59873503f8eae5b8b
Found initrd image: /boot/initramfs-0-rescue-ba6ac4966b774ff59873503f8eae5b8b.img
Found Gentoo Base System release 2.2 on /dev/sda2
Found Arch on /dev/sda6
Found Slackware Linux (Slackware 14.1) on /dev/sda7
done

real 0m19.456s
user 0m1.180s
sys 0m0.757s

Slackware:

# time grub-mkconfig -o /boot/grub/grub.cfg
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-huge-3.14.13
Found linux image: /boot/vmlinuz-generic-3.14.13
No volume groups found
Found Gentoo Base System release 2.2 on /dev/sda2
Found Fedora release 20 (Heisenbug) on /dev/sda5
Found Arch on /dev/sda6

done

real 0m17.396s
user 0m3.440s
sys 0m1.065s

Gentoo:

# time grub2-mkconfig -o /boot/grub/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub/themes/dark_squares/theme.txt
Found linux image: /boot/kernel-genkernel-x86_64-3.15.6-gentoo
Found initrd image: /boot/initramfs-genkernel-x86_64-3.15.6-gentoo
No volume groups found
Found Fedora release 20 (Heisenbug) on /dev/sda5
Found Arch on /dev/sda6
Found Slackware Linux (Slackware 14.1) on /dev/sda7
done

real 0m10.903s
user 0m1.198s
sys 0m1.166s

Additional info:

Packages installed which seem to be problematic:
grub 1:2.02.beta2-4
os-prober 1.58-1


Steps to reproduce:
Run grub-mkconfig on Arch Linux.

Is there any way to speed up this thing in Arch Linux?
   output (45.7 KiB)
This task depends upon

Closed by  Christian Hesse (eworm)
Tuesday, 02 August 2016, 07:44 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in whatever version.
Comment by Tobias Powalowski (tpowa) - Tuesday, 12 August 2014, 14:46 GMT
Better ask this on grub mailinglist. We cannot do anything here.
Comment by José Ribeiro (JKostaRibeiro) - Tuesday, 12 August 2014, 15:44 GMT
I already asked on https://savannah.gnu.org/bugs/.

You cannot do anything here???

How can that is possible? The bug is on Arch Linux, all my other systems run "grub-mkconfig" in less than 20 seconds...
Comment by Tobias Powalowski (tpowa) - Wednesday, 13 August 2014, 06:42 GMT
Perhaps it takes longer because arch checks more devices look at your info and you see arch reports more devices than the other distros.
Comment by Dave Reisner (falconindy) - Wednesday, 13 August 2014, 14:29 GMT
Arch patches grub-mkconfig and provides their own 10_archlinux. Can we rule these out before we shove the bug off to upstream? If you want that power, you can't keep intensive site-local changes to the package. There's been numerous bugs in the past surrounding our modifications (which in some cases aren't even used by the author of said modifications -- a major annoyance with me).
Comment by José Ribeiro (JKostaRibeiro) - Wednesday, 13 August 2014, 22:57 GMT
tpowa,

Can I prevent arch from check those additional devices?
Comment by jb (jb.1234abcd) - Friday, 15 August 2014, 18:20 GMT
This is a serious bug.

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 37.3G 0 disk
├─sda1 8:1 0 20G 0 part
├─sda2 8:2 0 1.5G 0 part [SWAP]
├─sda3 8:3 0 13.4G 0 part /
├─sda4 8:4 0 1K 0 part
└─sda5 8:5 0 2.4G 0 part
sr0 11:0 1 1024M 0 rom
$

core/grub 1:2.02.beta2-4

# grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-linux-lts
Found initrd image: /boot/initramfs-linux-lts.img
Found fallback initramfs image: /boot/initramfs-linux-lts-fallback.img
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/initramfs-linux.img
Found fallback initramfs image: /boot/initramfs-linux-fallback.img
/dev/cdrom: open failed: No medium found
No volume groups found
< here it took 4 min to detect a distro on another partition >
Found <a distro> on /dev/sda1
< here it took 4 min to finish its job >
done

$ top
...
Tasks: 113 total, 1 running, 112 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 0.0 sy, 0.0 ni, 0.0 id, 99.7 wa, 0.0 hi, 0.0 si, 0.0 st
...
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2624 root 20 0 10216 4844 396 D 0.3 0.6 0:00.05 grub-mount
...

Note CPU's "id" and "wa" values. Also, process status (pid# 2624) is "D"; 'info grub-mount'.

$ ps -ef |grep grub
...
root 1896 503 0 20:46 pts/1 00:00:00 /bin/sh /usr/bin/grub-mkconfig -o /boot/grub/grub.cfg
root 2536 1896 0 20:46 pts/1 00:00:00 /bin/sh /etc/grub.d/30_os-prober
root 2542 2536 0 20:46 pts/1 00:00:00 /bin/sh /etc/grub.d/30_os-prober
root 2624 1 0 20:46 ? 00:00:00 grub-mount /dev/sda1 /var/lib/os-prober/mount
$

$ dmesg -T
...
[Fri Aug 15 20:49:17 2014] EXT4-fs (sda4): unable to read superblock
[Fri Aug 15 20:49:17 2014] EXT4-fs (sda4): unable to read superblock
[Fri Aug 15 20:49:17 2014] EXT4-fs (sda4): unable to read superblock
[Fri Aug 15 20:49:17 2014] REISERFS warning (device sda4): sh-2006 read_super_block: bread failed (dev sda4, block 8, size 1024)
[Fri Aug 15 20:49:17 2014] REISERFS warning (device sda4): sh-2006 read_super_block: bread failed (dev sda4, block 64, size 1024)
[Fri Aug 15 20:49:17 2014] REISERFS warning (device sda4): sh-2021 reiserfs_fill_super: can not find reiserfs on sda4
[Fri Aug 15 20:49:17 2014] XFS (sda4): Invalid superblock magic number
[Fri Aug 15 20:49:17 2014] FAT-fs (sda4): bogus number of reserved sectors
[Fri Aug 15 20:49:17 2014] FAT-fs (sda4): Can't find a valid FAT filesystem
[Fri Aug 15 20:49:17 2014] FAT-fs (sda4): bogus number of reserved sectors
[Fri Aug 15 20:49:17 2014] FAT-fs (sda4): Can't find a valid FAT filesystem
[Fri Aug 15 20:49:17 2014] MINIX-fs: unable to read superblock
[Fri Aug 15 20:49:17 2014] attempt to access beyond end of device
[Fri Aug 15 20:49:17 2014] sda4: rw=16, want=3, limit=2
[Fri Aug 15 20:49:17 2014] hfsplus: unable to find HFS+ superblock
[Fri Aug 15 20:49:17 2014] You didn't specify the type of your ufs filesystem

mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...

>>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
[Fri Aug 15 20:49:17 2014] hfs: can't find a HFS filesystem on dev sda4
$

Note: sda4 is a primary partition, and also an extended partition. Could probing it be avoided/improved ?
The partition tables (the one in the MBR, and the ones for extended partitions) contain one byte per partition that identifies the type of that partition.

Also, the system responsiveness to xterm entries was low.

Addendum (08/16/2014):
Today (next day) there is no delay.
The only thing changed was that I rebooted and installed another distro (see below), and then came back and
regenerated grub config file 'grub-mkconfig -o /boot/grub/grub.cfg':

...
No volume groups found
< here it took 4 min to detect a distro on another partition >
Found <a distro> on /dev/sda1
< here it took 4 min to finish its job >
done

In the above troubled probing sequence I replaced the distro on /dev/sda1 (Fedora 16, with GRUB v.1x installed in
that partition), after reformatting, with another distro (with GRUB v.2 installed in that partition).
There were no relevant software updates in between.
So, the cause could be that, or some random instability of grub2.

I also remember seeing these messages randomly:
/proc/devices: No entry for device-mapper found
It looks like it was reported in  FS#38059 .

As of Sep 11, 2014 it works for me again.

Comment by Christian Hesse (eworm) - Monday, 01 August 2016, 21:22 GMT
Any remaining issue here with latest version?
Comment by jb (jb.1234abcd) - Tuesday, 02 August 2016, 07:32 GMT
grub 1:2.02.beta3-1
No issues.

Loading...