Hi.

I have installed neon alongside archlinux, - here is my partition layout

Arch (root) is installed on /dev/sda3, Arch (home) on /dev/sda4, neon on /dev/sda5. Issue seems to be os-prober related to my root arch partition (sda3)

Code: Select all

sda      8:0    0   1.8T  0 disk
├─sda4   8:4    0   530G  0 part
├─sda2   8:2    0     6G  0 part [SWAP]
├─sda5   8:5    0 353.9G  0 part /
├─sda3   8:3    0   140G  0 part
└─sda1   8:1    0   512M  0 part /boot/efi

When I update grub (which happens frequently during package updates..., i.e a kernel update ,etc) it takes 5 minutes each time... From syslog it seems to be

Code: Select all

Mar 28 21:16:00 host-MS-xxxx 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/90linux-distro

There is a 5 minute gap until the next line

Code: Select all

Mar 28 21:20:26 host-MS-xxxx 90linux-distro: result: /dev/sda3::Arch:linux

After then it completes the task in a second..

Looking at top I can see the top process during the 5 mins is

Code: Select all

grub-mount /dev/sda3 /var/lib/os-prober/mount

It does seem to complete, however how can I prevent this happening ? It didn't used to previously dual booting with other Linux OS's (i've reinstalled both recently).

I have included syslog messages for the entire time of launching sudo update-grub2 @ https://paste.ubuntu.com/24269932/

Any ideas how to troubleshoot this ?

yossarianuk wrote:Hi.
.
.
.
Looking at top I can see the top process during the 5 mins is

Code: Select all

grub-mount /dev/sda3 /var/lib/os-prober/mount

It does seem to complete, however how can I prevent this happening ?

At here, the working workaround is to mount the root partitions before the update-grub. That is - click the root partitions from the Dolphin before the update-grub.

The 'update-grub':

Code: Select all

#!/bin/sh
set -e
exec grub-mkconfig -o /boot/grub/grub.cfg "$@"

and

Code: Select all

$ grub-mkconfig --help
Usage: grub-mkconfig [OPTION]
Generate a grub config file

  -o, --output=FILE       output generated config to FILE [default=stdout]
  -h, --help              print this message and exit
  -v, --version           print the version information and exit

You had a 'cron'-job running in between (at 17 minutes past _X_ o'clock):

# /etc/crontab

#_m_h_dom_mon_dow_user_command
__17_*____*_____*_____*_root_cd / && run-parts --report /etc/cron.hourly

Did You run any high priority tasks there?

NoNameNoBlame wrote:You had a 'cron'-job running in between (at 17 minutes past _X_ o'clock):

Its not cron (or at, etc) related - it happens any time and is 100% reproducible

There's a possibility that You have lots of previously installed
kernel-versions and nvidia kernel-modules on Your system.

These are re-updated every time, too.
This takes time.

Therefore:

Try: 'apt autoremove'.

If no better solution comes up:

# Source:
$ info grub -n 'Simple configuration'

# In '/etc/default/grub':

'GRUB_DISABLE_OS_PROBER'
Normally, 'grub-mkconfig' will try to use the external 'os-prober'
program, if installed, to discover other operating systems
installed on the same system and generate appropriate menu entries
for them. Set this option to 'true' to disable this.

'GRUB_OS_PROBER_SKIP_LIST'
List of space-separated FS UUIDs of filesystems to be ignored from
os-prober output. For efi chainloaders it's <UUID>@<EFI FILE>

NoNameNoBlame wrote:There's a possibility that You have lots of previously installed
kernel-versions and nvidia kernel-modules on Your system.

These are re-updated every time, too.
This takes time.

Nope, I installed fresh neon 2 days ago - there are a total of 2 kernels.

I shall try omitting the UUID of the partition as you suggested and will report back... (will be tonight as its my home machine)

I have dual booted neon with 4 -5 other distros previously. (At present I only have arch + neon though)

NoNameNoBlame wrote:Try: 'apt autoremove'.

I did that and to get rid of the 2nd kernel I had, that also took 5 mins to remove.

NoNameNoBlame wrote:'GRUB_DISABLE_OS_PROBER'

Thanks for that,

I added to

Code: Select all

 /etc/default/gub

Code: Select all

GRUB_DISABLE_OS_PROBER=true

And update-grub skips the Arch partition and now the process finishes in seconds (i.e normal)

Would be good to work out why the issue is there however - shall I raise a bug report somewhere?

Well, You could try to file a bug report at

https://www.gnu.org/software/grub/grub-mailinglist.html

I'd recommend: Don't report the bug with KDE.
It will achieve nothing, waste your time, and
bring only frustration.


KDE's BugTracking system is not very effective/efficient, in general.

KDE's developers prefer new features.
They are well known for not repairing year-old, obvious bugs.
You have to get used to this, unfortunately.

But if Your expectations are low, then by any means do it:
Report it to KDE or KDE neon.

By the way:

Did You use some kind of volume management software or
a virtual machine?

Or did Your problems occur running on bare-metal partitions/volumes?

Did You use (U)EFI-firmware or BIOS-firmware or BIOS-compatibilityModule
mode under (U)EFI?

Just maybe, You installed one of
Your Linuxes in BIOS-mode and
the other in EFI-mode? By mistake
or intentionally?

Only You can know and tell.

Because GrUB's filesystem-drivers use firmware-functions, that
could explain Your delays.

NoNameNoBlame wrote:Just maybe, You installed one of
Your Linuxes in BIOS-mode and
the other in EFI-mode? By mistake
or intentionally?

No I installed in UEFI, as I did arch (in order to install arch in uefi mode you have to know what you are semi-doing..)

My bios is set to UEFI only mode (no secure-boot though)

Did You use some kind of volume management software or
a virtual machine?

Its bare metal, no volume management software, not even LVM.