Bug 1744693
Summary: | grub2-mkconfig does not work correctly with os-prober | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | apt-ghetto | |
Component: | grub2 | Assignee: | Peter Jones <pjones> | |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | high | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 30 | CC: | dmach, ewleaver, fmartine, ghborrmann, ja, kflorek46, lkundrak, pjones, terry1 | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | x86_64 | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | If docs needed, set a value | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 2173780 (view as bug list) | Environment: | ||
Last Closed: | 2020-05-26 18:22:02 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 2173780 |
Description
apt-ghetto
2019-08-22 17:04:18 UTC
Same bug here, for a long time. I just figured it would disappear one day. One other thing I noticed is that there are items dm0, dm1,.. in /dev/. one for each "device-mapper" error. (They appear in nautilus.) For me, it about a GPT partitioned nvme drive with EFI boot. Any partition that gets this error, such as device-mapper: remove ioctl on osprober-linux-nvme0n1p2 failed: Device or resource busy Command failed. will not get a repeat error if sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg is run again, but the partition will still not get a line in the grub boot menu. If you keep repeating the command, eventually there will be 0 items in the grub menu (other than the Fedora one you are running.) "dmsetup remove_all" will reset the process to the beginning, but putting that in "/etc/grub.d/30_os-prober" does not fix the leaving out of menu items at all for me. (Even though the osprober-linux-nvme0n1p* items are gone afterwards.) Out of the 3 other partitions to boot, I get just one, nine times out of ten tries, and I have never gotten all 3. Using EFI, I can get a menu from the BIOS (with F11) which boots the 4 different partitions directly, which is my workaround. The reason 99.9% of Fedora users do not notice this problem is probably they do not have other linux versions on their computer. They would not even run "grub2-mkconfig." It is still a pity that this cool feature of grub2 has been undone in Fedora since at least Fedora 28. With Fedora 31, the bug is gone. Alas, all is not well: os-prober is causing grub2-mkconfig to take up to 19 minutes to execute on my systems. Fully updated F31 os-prober is very slow when a second partition is present with a previous version of Fedora. The run time increases from 2 seconds to nearly 2.78 minutes when os-prober is called - see below. This delay (of several minutes) also occurred when initially installing F31 from a fast XFCE Live USB3 stick. It took longer running os-prober than the whole of the rest of the installation! geany /etc/default/grub and add GRUB_DISABLE_OS_PROBER="true" [root@harting:~]$ time grub2-mkconfig --no-grubenv-update -o fred_no_os-prober Generating grub configuration file ... Adding boot menu entry for EFI firmware configuration done real 0m2.191s user 0m1.092s sys 0m1.008s [root@harting:~]$ geany /etc/default/grub and remove GRUB_DISABLE_OS_PROBER="true" [root@harting:~]$ time grub2-mkconfig --no-grubenv-update -o fred_os-prober Generating grub configuration file ... Found Fedora 30 (Thirty) on /dev/nvme0n1p5 Adding boot menu entry for EFI firmware configuration done real 2m47.766s user 0m2.150s sys 0m1.924s [root@harting:~]$ Yes, indeed, the 'Device or resource busy' problem seems to be gone. But I can confirm, that os-prober takes very long to finish: 18:38.97 total Maybe it is better to file a new bug report and close this one? I have just adding bug https://bugzilla.redhat.com/show_bug.cgi?id=1782773 This is on the slowness of os-prober due to the performance of grub2-mount I believe. The problem also exists in CentOS-8-Stream. But there appears to be a simple fix that works both there and in Fedora 30: The do_unmount() function in /usr/libexec/osprobes/50mounted-tests and in /usr/libexec/linux-boot-probes/50mounted-tests calls dmsetup remove $dm_device In both files change this call to dmsetup remove --force --deferred --retry $dm_device Then make sure 'sudo dmsetup ls' returns "No devices found" before kicking off "grub2-mkconfig -o /boot/grub2/grub.cfg.new" Please give it a try, let us know how it goes. Thanks! I probably have the same problem: Created a sparse file. Partitioned it using sfdisk, an UEFI layout (EFI, /boot, /, swap, /home) Ran losetup -fp <image> to make the partitions available Mounted image's partitions in the correct order + bind-mounted dev, proc, sys Installed packages via dnf install --installroot=... etc. Chrooted to the installed system Ran grub2-mkconfig grub2-mkconfig is extremly slow and it looks it's due to os-prober. What's even worse, it creates a config file based on the *host* environment and not the content of the image. I'm not sure if it's because I'm running f33 host (newer) and f32 chroot or if the host settings win because the probe comes second... I'd expect records from image's /etc/fstab to take precedence. I know I'm doing crazy things, but it still should be working as expected :) If someone is interested, I can provide my intallation script and instructions as an reproducer. This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. 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 '30'. 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 30 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 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 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. |