Lengthy Delay During Grub-update -- OS-Prober Issue?

I am on unstable, and after a recent update (last few days), I’ve discovered that updating grub takes about five minutes to complete while OS-Prober does its thing. I do have a multi-boot setup with two SSDs. This happens on my Dell Latitude E6540 laptop, but it does not happen on my Lenova ThinkCentre pc.

I understand from Phil that upstream grub and OS-Prober has been having issues – GRUB_DISABLE_OS_PROBER flag appears to be ignored in /etc/default/grub - #6 by philm – so perhaps this will be resolved in due time, but thought I’d report it before OS-Prober goes to stable.

I need to access the laptop so that I can provide some journalctl and .xsession-errors info – give me a few minutes to follow-up…

journalctl -b -p 3
Pastebin: $ journalctl -b -p 3-- Journal begins at Sun 2020-08-30 13:52:42 MDT, ends at - Pastebin.com

cat ~/.xsession-errors
Pastebin: $ cat ~/.xsession-errorsxrdb: "Xft.hinting" on line 9 overrides entry on line - Pastebin.com

/etc/default/grub
(Pastebin says the output is offensive and made it private, so here’s the full code):

GRUB_DEFAULT=saved
GRUB_TIMEOUT=17
GRUB_TIMEOUT_STYLE=menu
GRUB_DISTRIBUTOR="Manjaro"
GRUB_CMDLINE_LINUX_DEFAULT="quiet apparmor=1 security=apparmor udev.log_priority=3"
GRUB_CMDLINE_LINUX=""
GRUB_DISABLE_OS_PROBER=false

# If you want to enable the save default function, uncomment the following
# line, and set GRUB_DEFAULT to saved.
GRUB_SAVEDEFAULT=true

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to enable booting from LUKS encrypted devices
#GRUB_ENABLE_CRYPTODISK=y

# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console

# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command 'videoinfo'
GRUB_GFXMODE=auto

# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX=keep

# Uncomment if you want GRUB to pass to the Linux kernel the old parameter
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=true

# Uncomment and set to the desired menu colors.  Used by normal and wallpaper
# modes only.  Entries specified as foreground/background.
GRUB_COLOR_NORMAL="light-gray/black"
GRUB_COLOR_HIGHLIGHT="green/black"

# Uncomment one of them for the gfx desired, a image background or a gfxtheme
#GRUB_BACKGROUND="/usr/share/grub/background.png"
GRUB_THEME="/usr/share/grub/themes/manjaro/theme.txt"

# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"

# Uncomment to ensure that the root filesystem is mounted read-only so that
# systemd-fsck can run the check automatically. We use 'fsck' by default, which
# needs 'rw' as boot parameter, to avoid delay in boot-time. 'fsck' needs to be
# removed from 'mkinitcpio.conf' to make 'systemd-fsck' work.
# See also Arch-Wiki: https://wiki.archlinux.org/index.php/Fsck#Boot_time_checking
#GRUB_ROOT_FS_RO=true

I added the line for GRUB_DISABLE_OS_PROBER=false because OS-Prober failed to engage with update-grub – also resulting from a recent system update. OS-Prober was also taking forever to process once I got it to engage again.

OS prober has always taken a long time to detect all distros. On manjaro and arch based distros, it takes 20 mins to complete updating grub on my multiboot machine with 15 distros.

That’s why I’ve long ago disabled OS prober on all my distros, and depended on custom.cfg entries .

1 Like

Makes sense, although for me on this laptop, it went from about 30 seconds to several minutes after a single update. On my pc and a slower laptop, it still only takes 30 seconds for OS-Prober to detect two or three other systems.

@adreampuppet and @wongs Could you try installing lsb-release on all your distros. It made a huge difference for me.

Background: GRUB - ArchWiki

I just checked and lsb-release is installed on three Arch-based distros on this machine (two Manjaro, one Arch). I’ll need to check Fedora and Debian. The controlling Grub is on the Manjaro XFCE that I’m using now, and lsb-release is already installed.

@mparillo , thanks for your suggestion. However, it’s manjaro xfce that controls grub so it’s arch based grub that is in question, not other distros’ grub.

In any case, I’ve got my custom.cfg nailed down already. All distros only need to update its own grub.cfg without OS prober detecting others. My custom entries then boot straight into the grub.cfg of each of these distros.

@wongs – Is there a tutorial that you’d recommend for doing this? Or, what search terms should I try? Thanks in advance – I’d like to learn how to do this.

@adreampuppet

[sorry, corrected the filenames of the scripts]

I always point people to the great work of our former member gohlip, who was the undisputed grub guru here previously. It’s now in the archived forum:

For instance:

Read through the whole thread to examine the various examples of grub entries he provided. While I never bothered to make an os-independent bootloader in a separate partition, I based my entries in my /boot/grub/custom.cfg file on his examples.

The benefit of the custom.cfg file (you have to save it in your distro that’s controlling grub) is that it’s automatically read by the 41_custom script in /etc/grub.d folder and displayed whenever you boot up your machine.

Whenever you edit it, there is no need to run sudo update-grub, as this command merely re-generates grub.cfg, which is a separate file, read and displayed by the 10_linux script in /etc/grub.d folder.

To ensure that my custom.cfg entries are displayed in the boot menu before the grub.cfg entries, I run a

sudo mv /etc/grub.d/41_custom /etc/grub.d/09_custom

so that the custom.cfg script comes before 10_linux script and is read first. I have to redo this whenever there is a update to the grub package and they repopulate the scripts in /etc/grub.d/ [or rather, after the repopulation, I have to delete the extraneous 41_custom script since 09_custom already exists.]

1 Like

Excellent — many thanks! Gholip indeed helped me on several occasions “back in the day,” including the complete removal of Grub Customizer early in my Manjaro career. He had a gift, for sure. I will study his instructions here after work…