Red Hat Bugzilla – Bug 972670
os-prober generates infinite stream of I/O error on fd0 log entries
Last modified: 2016-07-19 06:14:22 EDT
Description of problem: I was just doing a net install of fedora 19 beta and it reached the "installing boot loader" step and displayed a busy cursor for about 20 minutes, so I started checking out the various consoles by switching with Ctrl-Alt-Fn. In the shell I did a ps command and found it sitting in os-prober. In the syslog window I found an infinite number of I/O error messages for device "fd0". This computer does not have a floppy disk installed, but I hadn't disabled the floppy in the BIOS. Seems unlikely to me that even if there was an OS on the floppy that you'd really want it listed permanently in your grub.cfg file :-). Perhaps os-prober should ignore floppy drives? Version-Release number of selected component (if applicable): os-prober-1.58-1.fc19.x86_64 (I think) How reproducible: I only did the one install, but seems likely it would happen again under the same set of conditions. Steps to Reproduce: 1. Boot netinst CD, install fedora 19 beta. 2. Watch spinning circle forever at install boot loader time 3. Actual results: It finally completed in about 30 minutes of doing install boot loader Expected results: A lot less time Additional info: https://lists.fedoraproject.org/pipermail/test/2013-June/116016.html
Reproducible also with installation via the iso DVD final TC2 i.e. in systems without Floppy Disk Drive. Enable "Floppy Disk Boot Seek" in BIOS. Start installation.
os-prober scans any removable-media and lists their OSes too, so it is natural to scan for an OS on a floppy. It is probably left to the os-prober user (e.g. grub2-mkconfig) to decide which OSes it wants. This is actually a guess, so maybe excluding any removable media including floppies is also an option for os-prober developers. Anyway, the bug is about when no floppy disks are available. I wonder if there are any ways to check if there are any floppy disk in the drive. I'll try to see if I can find any. Excluding fd0 is not a fix, but can be a workaround for F19 (while this bug was present in older versions too).
I have now disabled, all what there is to disable (including parallel and serial port, second and third boot device), enabled USB, PS2, first boot device - cdrom, network etc.. This bootloader process took now approximately 1 minute. Now I have enabled step by step all disabled BIOS options. The last but one was "onboard FDC controller", still 1 minute duration of "bootloader installieren". After enabling Floppy Drive A the process "bootloader installieren" took about 15 minutes. Tom is right, also in my case it's fd0.
Please give the output of the following command when your floppy drive controller is ENABLED in BIOS: floppy --probe
On the fedora 19 system where I had the problem, I only have f19 installed, and apparently the util-linux package no longer includes the /usr/bin/floppy program, so this is hard to do (one more reason to exclude fd0 in os-prober since they seem to be trying to eradicate floppy support everywhere :-).
I can do a test. But in my test it's only useful to enable the BIOS settings for "Boot Up Floppy Disk Seek" (about 5 min delay to the bootloader install time) or Floppy Disk Drive A or Floppy Disk Drive B (each about 10 min delay time). Enabling the Onboard FDC Controller in "my" Phoenix Bios does not add any time to the 1 min Bootloader install time. Which test do You want?
That would be nice. Probably the latter is more useful, but if you can do both tests, that would be great. It is surprising that floppy is removed in F19! :P
Hi, didn't find the floppy command. Do You know kfloppy? I have it now installed. Is it helpful for this test? I don't know kfloppy to the detail You want to have a test. It can be used as command line tool, but there is naturally no "--probe" argument. How shall I test? I have no floppy drives connected, possible is enable/disable in the BIOS, which arguments of kfloppy are useful for this test?
I really think the thing to do here is just ask upstream os-prober not to probe floppy drives (perhaps add a special parameter to force it to do so, in case some crazy idiot somewhere is still booting something via a special floppy). IIRC, it is not really possible to reliably tell if a floppy drive is populated or not without actually trying to read it.
Short question: What is expected by the command "floppy --probe"? The manual shows "--probe, -p - Probe for available floppy drives. floppy creates and displays a list of all detected floppy drives." In this case also kfloppy can be used. In my system there is no Floppy Disk Drive connected (I can easily connect,if really neccessary for this problem). Kfloppy says if I enable the first floppy drive (A) in Bios "internal error: device not correctly defined". fdformat says: " [joerg@localhost ~]$ fdformat /dev/fd0 fdformat: stat failed /dev/fd0: Datei oder Verzeichnis nicht gefunden [joerg@localhost ~]$", the same for fd1. That's all what I have found so far about floppy commands/tests.
Adam: upstream is VERY unresponsive. Some of my patches are pending there for months (maybe more than a year), without any comments. So, probably I should do it myself if it is not possible to detect if a floppy drive physically exists (I'll send the patch upstream though). Joerg: Thanks for the test. The problem with kfloppy is that it is a KDE application, I'm looking for something that can be used by os-prober to detect if a floppy drive exists physically. Does KFloppy print the error message fast? Or it takes minutes? (No, there is no need to connect a floppy drive, sine in that case os-prober should immediately understand that there are no floppies in the drive). What about fdformat? Does it print the error message immediately? The only problem with using fdformat in os-prober is that if a floppy actually exists, it'll be formatted! If KFloppy and/or fdformat can detect that no floppy drives exists in a few seconds, I'll try to use the same method. If not, probably we should go with disabling fdX probing in os-prober altogether. (Unfortunately, sending options to os-prober is not easy, since it is called by grub2-mkconf. Using environment variables is probably a better option. I wonder if anaconda developers agree with setting an environment variable for os-prober. If not, it should be disabled by default.)
Peter, WDYT would be best to do here? Just drop scanning floppy drives?
I saw bazillions of I/O errors in the log for fd0. If someone could notice just one error and give up instead of retrying infinitely, that would also make it go a lot faster (don't know if error status makes it all the way up to the user that early though).
Both commands are very quick (fdformat immediately). Kfloppy on the command line calls the "kfloppy window", You have to click "format", then click something like "verify", all answers are immediately. I think (I am no linux expert) both programs check first the device list, and if the device is not in the list, the answer is like "no device". As I understand both programs will try to format.
Well, I think I should drop scanning floppy drives for now. It seems that will be a better bug!
*** Bug 1115026 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
The Fedora os-prober does not appear to analyze btrfs systems. I had a similer problem with SUSE's os-prober. I worked with SUSE to debug their os-prober, such that it would work with btrfs or ext4 files and also recognize floppy/DVDs. Open Source, Why not look at SUSE's version of os-prober for their corrections.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.