Reply to topic

arch dualboot. update-grub takes 5 mins! grub-mount 100%CPU

User avatar yossarianuk
Registered Member
Posts
25
Karma
0
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 ?
User avatar Rog131
Registered Member
Posts
828
Karma
10
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
NoNameNoBlame
Karma
0
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?
User avatar yossarianuk
Registered Member
Posts
25
Karma
0
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
NoNameNoBlame
Karma
0
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'.
NoNameNoBlame
Karma
0
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>
User avatar yossarianuk
Registered Member
Posts
25
Karma
0
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)
User avatar yossarianuk
Registered Member
Posts
25
Karma
0
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.
User avatar yossarianuk
Registered Member
Posts
25
Karma
0
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?
NoNameNoBlame
Karma
0
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.
NoNameNoBlame
Karma
0
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?
NoNameNoBlame
Karma
0
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.
User avatar yossarianuk
Registered Member
Posts
25
Karma
0
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.

 
Reply to topic

Bookmarks



Who is online

Registered users: Baidu [Spider], Bing [Bot], gerdeg, Google [Bot], jacekalex, Majestic-12 [Bot], peje, stoffepojken