Why does grub2-mkconfig take

I’ve searched for this here and with Ixquick and haven’t found anything. The issue is that:

# grub2-mkconfig -o /boot/grub2/grub.cfg

Takes a very long time. Today I just measured it at 4 minutes 13 seconds to achieve this:

# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.7.10-1.16-desktop
Found initrd image: /boot/initrd-3.7.10-1.16-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.11-desktop
Found initrd image: /boot/initrd-3.7.10-1.11-desktop
  /dev/sdd: open failed: No medium found
  No volume groups found
Found OpenMandriva LX 2013.0 alpha (2013.0) on /dev/sda11
Found Fedora release 19 (Schrödinger’s Cat) on /dev/sda13
Found Mandriva Linux 2010.1 (2010.1) on /dev/sda7
Found OpenMandriva LX 2013.0 alpha (2013.0) on /dev/sda9
done

In other distros it’s well under 1 minute. Is there any way to speed this up in openSuSE?

Well, I know about one potential problem:
It may try to probe the floppy disk drive for an installed operating system.
If you don’t have one, this can take some time until it times out. In this case, try to disable it in the BIOS.

Also in your output there is a problem with /dev/sdd not found. Maybe that one is in /boot/grub2/device.map by mistake?

And have a look here:
https://forums.opensuse.org/english/get-technical-help-here/pre-release-beta/478454-how-fix-grub2-mkconfig-yast2-boot-loader-running-too-long-12-2-a.html

This display seems normal, but I don’t know what /dev/sdd is. I have four such missing media errors and all come from a single USB connected 4x memory card reader.

Is the display just blank for four minutes then works or where in that list does it stall? Here is my listing:

Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.12.0-rc4-1.16-desktop
Found initrd image: /boot/initrd-3.12.0-rc4-1.16-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.16-desktop
Found initrd image: /boot/initrd-3.7.10-1.16-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.1-desktop
Found initrd image: /boot/initrd-3.7.10-1.1-desktop
  /dev/sdf: open failed: No medium found
  /dev/sdg: open failed: No medium found
  /dev/sdh: open failed: No medium found
  /dev/sdi: open failed: No medium found
  No volume groups found
Found Windows 8 (loader) on /dev/sdc1
done

This comes up in just a few seconds for me with new such long delay.

Thank You,

It stalls after this:

# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.10-17-desktop
Found initrd image: /boot/initrd-3.11.10-17-desktop
Found linux image: /boot/vmlinuz-3.11.10-17-debug
Found initrd image: /boot/initrd-3.11.10-17-debug

ie. when it is starting to probe for other OS’s. And this is a multiple (up to 8 at one time) OS system. There is no fd0 in device.map there is only one drive a 128GB SSD thought there are also two 1TB HD’s as well. As far as device.map is concerned it doesn’t matter if I have only the one drive listed or all 3 it still takes nearly 5 minutes. Why is my system so different? I’m assuming that other openSuSE users aren’t experiencing this. To more thoroughly answer jdmcdaniel3 it just sits there with no further output for nearly 5 minutes.

The full output today is thus:

# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.10-17-desktop
Found initrd image: /boot/initrd-3.11.10-17-desktop
Found linux image: /boot/vmlinuz-3.11.10-17-debug
Found initrd image: /boot/initrd-3.11.10-17-debug
  No volume groups found
Found Fedora release 20 (Heisenbug) on /dev/sda13
Found OpenMandriva Lx 2014.0 (2014.0) on /dev/sda7
done

so the /dev/whatever issue is not relevant.

Why do you have the debug kernel installed? And which one are you using?
I don’t think the debug kernel would be the greatest one in terms of speed. But then, probing for OSes shouldn’t take 4 minutes either I guess.

There is no fd0 in device.map

Ok, but I would still take a look in the BIOS settings and try to disable floppy drives altogether.
Or try booting with the “brokenmodules=floppy” boot option to see if it makes a difference.

“grub2-mkconfig” definitely accesses the floppy drive here (I do have one), even when there’s no mention of it in the device.map.

I’m assuming that other openSuSE users aren’t experiencing this.

No, I never experienced anything like this.
But then, I don’t have 8 OSes installed either.
I only have openSUSE here and Windows, with a total of 3 partitions (one /, one swap and one Windows) spread over two hard disks.

OTOH, it did take quite long here now (haven’t measured it, but about 2 minutes I suppose), when I had a bad floppy in the drive.

so the /dev/whatever issue is not relevant.

Ok, most probably that’s your CD/DVD drive.
That shouldn’t cause the long delay.
I get such errors for my two CD/DVD drives and 4 card reader slots, and don’t see a delay.

Try to disable the “Probe foreign OS” option in YaST->System->Boot Loader->Boot Loader Option or set GRUB_DISABLE_OS_PROBER=true in /etc/default/grub.
Does the delay disappear then?

How should we know? os-prober (and scripts it starts) are logging into syslog, so you have /var/log/messages with messages during os-prober run with time stamps. Post them, it may give some further hints.

On 2014-08-08 08:26, wolfi323 wrote:
>> > I’m assuming that other openSuSE users aren’t experiencing this.
> No, I never experienced anything like this.

I have.

I saw it trying to mount the extended partition on several disks. Mind,
the extended: I’m not talking of primary or logical partitions. I tried
to mount the extended partition, and then probing every known filesytem
on it.

And failing.

And taking an awful long time about it.

Yes, it is reported in some bugzilla, AFAIR.


Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

observation

when ‘Probe Foreign OS’ is selected or cmd sudo grub2-mkconfig -o /boot/grub2/grub.cfg
is run when any foreign os is on a mounted partition, the process can take a long time
to complete

suggestion

make sure only the primary os is mounted before starting the process

On 2014-08-08 22:26, keellambert wrote:

> make sure only the primary os is mounted before starting the process

It really does not matter what is mounted. os-prober tries to mount
everything in sight, even if impossible, as with extended partitions.
It does so in order to find out if there is any operating system anywhere.


Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

First thanks everyone for the replies.

I’m using kernel-desktop. kernel-debug has been removed,

Floppy is disabled but I notice in BIOS under >Boot>Removeable Drives it list 1. Floppy drive. I don’t know why as there are no removable storage devices of any kind attached. And to make things more interesting BIOS will not let me remove this entry.

I only have 3 OS’s installed OpenMandriva, openSuSE, and Fedora. The rest are for testing .iso’s for OpenMandriva QA-Team.

[QUOTE=wolfi323;2658325]Ok, most probably that’s your CD/DVD drive.

It’s (/dev/sdd) actually a USB printer which Linux systems see as a storage device if it is turned on.

[QUOTE=wolfi323;2658325]Try to disable the “Probe foreign OS” option in YaST->System->Boot Loader->Boot Loader Option or set GRUB_DISABLE_OS_PROBER=true in /etc/default/grub.
Does the delay disappear then?

Yes, that’s it. So running with that enabled and looking at /var/log/messages should tell me something.

Whats mounted are:

  1. /
  2. /home
  3. /swap
  4. /data1
  5. /data2

/, /home, and /swap are all on a 128GBSSD. /data1 and /data2 are each 2 seperate 1TB HDD. But none of this slows down grub2-mkconfig in other OS’s.

I have /var/log/messages from grub2-mkconfig with os-prober enabled and in a .gz file (it’s to long to post here as code).

http://www.datafilehost.com/d/1f216694

At least I hope I did.

You could simply record last timestamp in /var/log/messages, run os-prober and upload everything since recorded timestamp. It would also make it easier by providing precise information about start and end of os-prober run.

Anyway - at least one obvious delay is here:

2014-08-08T17:20:03.536421-05:00 linux-giqf os-prober: debug: running /usr/lib/os-probes/50mounted-tests on /dev/sda13
2014-08-08T17:20:03.802676-05:00 linux-giqf 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/90linux-distro
2014-08-08T17:25:08.534291-05:00 linux-giqf 90linux-distro: result: /dev/sda13:Fedora release 20 (Heisenbug):Fedora:linux

So it takes 5 minutes to detect Fedora.

Could you please do the following - mount partition manually using grub2-mount and running the same command as script does:

mkdir /tmp/test
grub2-mount /dev/sda13 /tmp/test
time sh -c 'ls /tmp/test/lib/ld*so*'
time sh -c 'ls /tmp/test/usr/lib/ld*so*'

Quick test on openSUSE partition is not lightning fast, but is not that slow either

opensuse:/home/bor/src/grub # time sh -c 'ls /tmp/x/lib/ld*so*'
-r--r--r-- 0 root root 152418 Dec 10  2013 /tmp/x/lib/ld-2.18.so
-r--r--r-- 0 root root 152418 Dec 16  2013 /tmp/x/lib/ld-linux.so.2

real    0m1.819s
user    0m0.004s
sys    0m0.005s
opensuse:/home/bor/src/grub # time sh -c 'ls /tmp/x/usr/lib/ld*so*'
ls: cannot access /tmp/x/usr/lib/ld*so*: No such file or directory

real    0m20.823s
user    0m0.005s
sys    0m0.005s

I guess I know why … Fedore moved /lib into /usr/lib, so second command has much more to do … anyway, let’s see.

observation

also long delays occur with grub cmd when used from the none prime os
and having the ‘Probe Foreign OS’ selected

another suggestion

make sure ‘Probe Foreign OS’ is deselected on the secondary os before
running the grub cmd
then run the grub cmd on the prime os (booting partition) with the ‘Probe Foreign OS’ selected

hth