On Thu, 2019-12-12 at 10:01 +0000, Terry Barnaby wrote: > On 12/12/2019 06:33, Terry Barnaby wrote: > > I have just started to try out Fedora31 on some of our systems. > > > > I am using a bit of an unusual, manual install method copying an image > > of the rootfs to the disk and configuring this, (this may be related > > to my issue, but I have been using the same system for 6 years or > > more). The particular hardware platform is a bit complicated using a > > PCIe card with NVMe disk and two SATA disks. It has to boot (BIOS boot > > and /boot) from one of the SATA disks and then uses the rootfs system > > on the NVMe disk. I don't think that is related to the the issue though. > > > > The issue is that when I run "grub2-mkconfig -o /boot/grub2/grub.cfg" > > to manually configure grub2, this process hangs. There is a process > > grub2-mount that is sitting there using 100% of a CPU core. Not sure > > what this process does (seems new after Fedora29) but it is passed the > > /dev entry for a disk partition some presumably mounts the file system > > and "probes" for what OS is installed there. The file system it hangs > > on (if you kill the grub2-mount process it will hang on another > > drive), is easily mountable without any issues. > > > > It seems like there is some bug in this grub2-mount program. Has > > anyone else seen this or have any ideas what might be the issue. > > > > A bit more digging. It seems the issue is seen within os-prober. > Tracking this down: > I am running Fedora29 with the 5.3.11-100.fc29.x86_64 kernel. > > I have a Fedora31 rootsfs on the partition /dev/nvme0n1p2 and have > chroot'ed to this (with some /sys, /dev mounts etc). (Fedora31 would be > running the vmlinuz-5.3.15-300.fc31.x86_64 kernel). > Within the os-prober it effectively does the following at some point: > grub2-mount /dev/nvme0n1p2 /var/lib/os-prober/mount > ls /var/lib/os-prober/mount/lib*/lib*.so* > > 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 > > grub2-mount appears to be a FUSE driver to mount various file system > types. I am guessing that there is either a bug in grub2-mount or there > is a kernel level incompatibility (FUSE API) with the slightly older > 5.3.11-100.fc29.x86_64 kernel or it is very very very very inefficient. > A minute of 100% of a CPU core to list a directory on a fast NVMe SSD! > Talk about bloatware and what about climate change folks ? > > I guess 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 > package for development that I use so is about 28 GBytes) and this > system has an SSD and two SATA disks with multiple partitions and > operating systems. > > > Terry > Maybe https://bugzilla.redhat.com/show_bug.cgi?id=1744693 John _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
