Description of problem: I have been trying to install Fedora31 onto a system that has an NVMe disk and two SATA disks with multiple partitions containing multiple operating systems. The grub2-mkconfig command is taking a very long time (don't know how long haven't waited long enough I suspect > 30mins). I have tracked this down to what looks to be a gross inefficiency in the grub2-mount FUSE driver. If I run: mount /dev/nvme0n1p2 /var/lib/os-prober/mount time ls /var/lib/os-prober/mount/lib*/lib*.so* > /dev/null real 0m0.089s user 0m0.028s sys 0m0.044s If I run: grub2-mount /dev/nvme0n1p2 /var/lib/os-prober/mount time ls /var/lib/os-prober/mount/lib*/lib*.so* > /dev/null real 0m59.593s user 0m0.190s sys 0m0.254s A minute of 100% of a CPU core to list a directory on a fast NVMe SSD! What about climate change folks ? I believe this my issue in that grub2-mkconfig will take a "really" long time on my system with largely populated rootfs (It has all of the RPM packages for development that I use so is about 28 GBytes) and this system has a NVMe SSD and two SATA disks with multiple partitions and operating systems.
As a hack, if you change to use "mount" instead of "grub2-mount" then grub2-mkconfig all seems to work ok and is fast: mv /usr/bin/grub2-mount /usr/bin/grub2-mount-orig ln -sf mount /usr/bin/grub2-mount
Confirmed! [root@harting:~]$ time grub2-mkconfig --no-grubenv-update -o ted_with_os-prober Generating grub configuration file ... Found Fedora 30 (Thirty) on /dev/nvme0n1p5 Adding boot menu entry for EFI firmware configuration done real 2m50.582s user 0m2.156s sys 0m1.960s [root@harting:~]$ mv /usr/bin/grub2-mount /usr/bin/grub2-mount-orig [root@harting:~]$ ln -sf mount /usr/bin/grub2-mount [root@harting:~]$ time grub2-mkconfig --no-grubenv-update -o ted_with_os-prober_changed_mount Generating grub configuration file ... Found Fedora 30 (Thirty) on /dev/nvme0n1p5 Adding boot menu entry for EFI firmware configuration done real 0m5.041s user 0m2.026s sys 0m1.873s [root@harting:~]$
Installing F31 on my laptop and facing a similar issue, the bootloader step of Anaconda took 11 minutes according to /tmp/anaconda.log, and I had grub2-mount eating 100% of the CPU in top during this.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
This is a bug in upstream GRUB. You will need to report the issue there.