GNOME Bugzilla – Bug 351753
missing floppy causes loop on scan devices
Last modified: 2008-05-09 15:31:12 UTC
Steps to reproduce: 1. clean update of cvs 2. gparted 3. never ending scan Stack trace: bash-3.1#!$ gparted ====================== libparted : 1.7.1 ====================== Unable to open /dev/floppy/0 read-write (Read-only file system). /dev/floppy/0 has been opened read-only. ^X^X ^X bash-3.1# bash-3.1#gparted /dev/hda ====================== libparted : 1.7.1 ====================== bash-3.1# running with no args looped indef. running on /dev/hda was fine. bash-3.1#ls -ail /dev/f* 1584 lrwxrwxrwx 1 root root 4 2006-08-17 11:08 /dev/fb0 -> fb/0 1674 crw-rw---- 1 root root 10, 63 2006-08-17 11:08 /dev/fbsplash 796 lrwxrwxrwx 1 root root 13 2006-08-17 11:08 /dev/fd -> /proc/self/fd 1848 lrwxrwxrwx 1 root root 8 2006-08-17 11:08 /dev/fd0 -> floppy/0 1143 crw-rw-rw- 1 root root 1, 7 2006-08-17 11:08 /dev/full /dev/fb: total 0 1582 drwxr-xr-x 2 root root 60 2006-08-17 11:08 . 787 drwxr-xr-x 16 root root 3980 2006-08-17 15:19 .. 1583 crw-rw---- 1 root video 29, 0 2006-08-17 11:08 0 /dev/floppy: total 0 1846 drwxr-xr-x 2 root root 60 2006-08-17 11:08 . 787 drwxr-xr-x 16 root root 3980 2006-08-17 15:19 .. 1847 brw-rw---- 1 root floppy 2, 0 2006-08-17 11:08 0 no physical floppy present. Other information:
could you test this with the latest release please? see #325969 for more info
that was tested on yesterday's cvs ! that bug refers to this being fixed in 0.1 !? are we talking at cross purposes here?
oops, my fault. I'm trying to clean out some old bugs and accidentily confused your bug with another one. my apologies :)
bios is set for one floppy which is not present. That's the root cause but you could look to see if gparted is handliing this condition sensibily and whether there should be a way to interupt the spin cycle manually. Having to use xkill seems a bit clumbsy. there also seems to be a long delay assoc with the 'progress' bar. As you recall I have about 23 partitions and it can take about 30s to log them all wheres any commandling tool does it in the bat of an eye. I suspect there is a lot of dead time around the call that logs each partition. Users are always a bit wary when using partitioning tools. Having long delays with this sort of tool can be very unnerving. Could those delays be cut? regards.
sorry , I withdraw the speed comment. This seems to be a lot faster now. hwvr , I think the floppy issue needs looking at. If I did not know the prog and have a lot of confidence in it , I would be very worried about hitting a partitioning tool with xkill. ;)
about the delays: - i am planning on replacing the pulsebar with a progressbar - delays can be caused by a number of things: - if there's something wrong with a device libparted will probe a (very) long time. I have to investigate this and see what to do about that. - depending on the filesystem, it's size and the amount of data in it, it can take a long time to determine used/unused space. CLI tools usually don't scan for all devices and they usually only show the partitiontable without info about used/unused space. That explains a lot :) However, it would be great to cut the time down and i think i'll focus a bit on that for the release after 0.3 Tonight i'll try to reproduce this problem with the floppydrive.
couldn't reproduce it, but i think it'll drop the libparted's probing anyway and simply parse the devices from /proc/partitions. This is lightning fast, robust and in case it misses something (which isn't very likely i think) you can always force scanning by using CLI arguments.
ok, just committed a change to CVS which will parse /proc/partitions instead of relying on ped_device_probe_all(). Among other things this should solve your problem. Please try it as soon as the anonymous servers are synced. thanks! (as said before, this approach is extremely simplistic. If you think it could miss something or cause other problems i'd like to know about it :) )
hi, reverted back to parted probing after i've heard fixes are underway. Future releases of parted will skip cd/floppy drives and this will effectively fix this problem.
I know it's a old bug, but some ubuntu users (Ari & Don Melcer) reported the same problem. Here's the bug in the Launchpad bug tracker: https://launchpad.net/bugs/155047 When they open GParted, they get the following output in the terminal: ====================== libparted : 1.7.1 ====================== Unable to open /dev/fd0 read-write (Read-only file system). /dev/fd0 has been opened read-only. Unable to open /dev/fd0 - unrecognised disk label. There isn't a physical floppy present.
yes this is old because it's fix , which seemed rather good, got reversed. apparently after a year the anticipated fix in libparted has not materialised. It would be good to see the fix restored. In addition the snappy response to logging devices would be a real bonus this has always been horribly slow. If I start parted it grabs the partition table in a flash , gparted has always been tiresome with the scrolly thing bouncing back and forth for ages. Is there anything bad about restoring the /proc/partitions approach? TIA.
ps I think the work around is to specify the root device of the drive you want on command line. eg. gparted /dev/hda you could suggest that to your lauchpad friends. If they work off menus and icons they could change the command run by the icon. HTH
This should have been fixed by parted update to 1.8.8. It is in the last beta and next release ! http://gparted-livecd.tuxfamily.org/beta.php
Thank you all for this bug report. My name is Curtis Gedak and I am the new C++ developer for GParted. Recently I confirmed that the infinite loop problem is fixed when using libparted 1.8.8. Hence I am closing this bug. TEST STEPS ---------- 1) Set BIOS to indicate 3.5" 1.44MB Floppy, although there is no physical floppy drive in this computer. 2) Started GParted v0.3.6, which took about 3 minutes before "Scanning all devices..." completed. Then I exited GParted. user@host:~$ sudo gparted ====================== libparted : 1.8.8 ====================== Unable to open /dev/fd0 read-write (Read-only file system). /dev/fd0 has been opened read-only. Input/output error during read on /dev/fd0 user@host:~$ 3) Started Parted, which also did not go into an infinite loop. user@host:~$ sudo parted GNU Parted 1.8.8 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) quit quit user@host:~$ CONCLUSION ---------- The infinite loop "Scanning devices..." problem caused by a missing physical floppy drive (though BIOS indicates a floppy drive is present) is fixed with libparted 1.8.8.
Hi Curtis, good to see gparted getting some love again. It's a great tool. However I'm not sure to what extent this has been fixed. You say it not longer has infinite loop but say that you waited 3 minutes. I think it is unacceptable to wait three minutes and I seriously doubt whether I waited that long for before resotrting to xkill. I really dont like things like partitioning tools misbehaving and I ain't going to wait to see how much damage it can do if it goes buggy. In fact rereading #1 it said indefinate loop not infinite, one can program an infinite loop but you can not test it. ;) If I understand what you describe in pargraph 2) in you last post it seems essentially the same as what I originally reported. You may also look at the way gparted it calling whatever scans for devices since it is not responding to anything short of kill -9 I think man system covers this senario and how to avoid it. regards.
Hi gg, It's good to hear from you. With many of these old bugs I don't receive any response. :-) Perhaps I misunderstood the problem listed. 1) If the problem is that GParted takes a long time in scanning devices, then that is currently being tracked as bug #453555 2) If the problem is that GParted takes an "indefinite" time scanning devices when the BIOS indicates a floppy drive is present, but no physical drive is present then I would say that this bug is fixed. On my computer when the BIOS is configured properly (e.g., BIOS indicates no floppy drive, as no physical floppy drive is present), then scanning devices takes 20 seconds. This isn't exactly fast, but it significantly better than when the BIOS is misconfigured. Have I misunderstood the problem? Your help to clarify this is appreciated.
Now that I re-read bug #453555 it sounds a lot like this one. Could these all be caused my a misconfigured BIOS???
gparted is slow logging devices , I reported that about 2 yrs back when plors was on board. That was other than bug #453555 but that seems to cover that issue , so let's leave it at that. That is nothing to do with this bug. BIOS correct for hardware seems to avoid this issue. You seem to correctly summarise the problem in 2) of #17 but again fail to say how you think this is fixed. My indef. delay = your 3 min, do you regard that as correct behaviour?
Thank you gg for the prompt response. I am re-opening this bug. I apologize for not providing my reasoning in the earlier message. Following are the testing results, some analysis of the results, and my thoughts: TESTING RESULTS =============== The results are broken down into the following three sections: 1) Devices are discovered using the libparted library function call ped_device_probe_all(). This is not source code within GParted, but is a third party library used by GParted. This generates a list of devices. 2) For each device in the list, GParted tests if the device is valid by trying to read the first sector from the device. Any device that fails this test is removed from the list of devices. 3) For each valid device, GParted reads information about the device and each partition, including how much space is used in each partition. BIOS BIOS CORRECT WRONG DESCRIPTION ======= ===== =============================================== ***** STEP 1 ***** 9s 33s Time spent in libparted's ped_device_probe_all() ------- ----- ----------------------------------------------- ***** STEP 2 ***** 0s 0s Time spend reading first sector of hard drives NOTE: This is to validate if device is real ------- ----- ----------------------------------------------- n/a 36s Total time spent reading first sector of floppy drive NOTE: This is to validate if device is real Breakdown of reading floppy drive follows: ----------------------------------------------- n/a 24s - open floppy device ERROR DISPLAYED: Unable to open /dev/fd0 read-write \ (Read-only file system). /dev/fd0 \ has been opened read-only. n/a 12s - read floppy device ERROR DISPLAYED: Input/output error during read on /dev/fd0 n/a 0s - close floppy device ------- ----- ----------------------------------------------- ***** STEP 3 ***** 11s 11s Time spent reading valid device information Breakdown of reading hard drives follows: ----------------------------------------------- 1s 1s - SATA II 500 GB drive with 13 partitions 10s 10s - IDE 160 GB drive with 7 partitions ======= ===== =============================================== 20s 80s Total time from start to end scanning devices ANALYSIS OF RESULTS =================== A) In step 1, there is a significant time difference. I suspect that much of this is time wasted (e.g., device timeouts) examining the floppy device. B) In step 2, a significant amount of time is spent trying to read from the floppy device. I suspect device timeouts as the problem here too. C) In step 3, the biggest difference is in the time spend collecting information from an IDE hard drive. SATA drives appear to be at least 10 times faster in this regard (at least on my computer). REASONING ========= You raise a good question. What is correct behavior for an application? Should an application be responsible for "correcting" devices incorrectly configured in the BIOS? If so, this would produce extra coding for all applications that may use such a device. In the case of storage devices, this may include editors, word processors, spreadsheets, .... Is this a good thing? Should GParted ignore all storage devices attached to the floppy or CD device drivers? If so, then this limits GParted's functionality for any future devices that may use the floppy or CD device interface. Should libparted only return valid devices from the ped_device_probe_all() function call? If so, GParted would not require the extra code to test if a device is valid. Perhaps this would be a good thing, though that depends on the real purpose of the function call. This decision should probably lie with the Parted developers. In summary, I don't believe that GPARTED should be responsible for "correcting" an incorrectly configured BIOS. I believe that the root cause of the problem should be addressed. The primary fix is to correct the BIOS. A secondary fix might be to have libparted return only valid devices from the ped_device_probe_all() function call. I am not overly convinced that the secondary fix is the right thing to do since it is a band-aid for the primary cause of the problem. I look forward to your thoughts on this issue. Regards, Curtis Gedak
Thanks for the thorough analysis. I would go alone with the arguement that text processors etc should not need to double check if the system is correctly responding. However, gparted is a low level maintainance and repair tool and it is already recognised by section 2 above that it really does need to check if a device is working correctly before even considering modifying it. Imagine if a HD is going flakey. You're not going raise your hands and say "not my business fella , sort out ya system" and then start trying to repartition it. Maybe the incorrect floopy is a rather unlikely situation that should be fixed elsewhere but I think it highlights something that could and should be handled better. It also appears that libparted could be handling this better but if gparted chooses to use that library it has to accept responsability for that choice. If it is found to be lacking a work around should be found. While 80s is better than 3 min or indefinate, I really don't like this sort of tool going walkabouts. It's very unnerving. Worse still, unless it is run from command line, you dont even get to see the error. IRRC this error is not detected by gparted so not displayed to the user. If I was working form command line it would be quicker to use the std commands anyway. I'd like to see the following approach: 1/ Accept the BIOS misconfig as a test condition that could also reflect a failing hard drive. 2/ if possible find a quicker way to detect this sort of condition. Either by getting some improved output from libparted or by using a different technique. 3/ in all cases trap and display when this sort of critical error occurs. Thanks for you interest.
The approach you suggested sounds reasonable. Since my preference is to continue using libparted for device detection, I will look into point #2 first.
(In reply to comment #20) > You raise a good question. What is correct behavior for an application? > > > Should an application be responsible for "correcting" devices incorrectly > configured in the BIOS? > > If so, this would produce extra coding for all applications that may > use such a device. In the case of storage devices, this may include > editors, word processors, spreadsheets, .... Is this a good thing? In general, the ideal should be to provide efficient and correct behavior in all cases. If a problem is reported that does not lie in the application but affects its behavior adversely, and an upstream fix is not possible, then a workaround in the application itself would improve its utility and quality. Of course, if the problem affects many different applications, the correct course of action is to share code between them, by creating a library function to implement the workaround. In this case, libparted and GParted seem to be the only applications that anyone has pointed to this affecting. Applications such as text editors do not scan devices and so are not affected. The best location for a fix might be libparted, not GParted; if you and the libparted developers all agree to that, an appropriate bug should be filed for that component and this one closed. But I would argue that since no upstream fix is possible for bad BIOS configuration, and it seems to be not uncommon, it is appropriate for this to be worked around somewhere along the line. It also seems, from your statistics, that a significant portion of the delay is in fact occurring in GParted code, so unless libparted provides a function that returns only valid devices, part of the fix needs to be in GParted. > Should GParted ignore all storage devices attached to the floppy or CD > device drivers? > > If so, then this limits GParted's functionality for any future devices > that may use the floppy or CD device interface. Well, the problem lies in the slowness of GParted's autodetection. Autodetection does not need to be completely correct, if complete correctness causes problems, since manual detection is always possible to use instead. So if future devices use the floppy or CD device interface, then at worst, someone wishing to use GParted on them would have to provide an explicit device on the command line (or an appropriate GUI option). This theoretical risk is probably acceptable when weighed against significant efficiency problems that people are indicating occur right now in some incorrect configurations. However, simply ignoring floppy/CD drives might not be necessary. According to your statistics, GParted spent 36 s attempting to read the floppy disk. If a sharp timeout were put on attempts to read from a floppy disk, for instance 1 s, the problem would be greatly mitigated. On the other hand, real floppy disks (or other devices using that interface) would in most cases be validated in under 1 s, judging by your figures for how long it takes to validate hard disks -- 0 s for two. Again, in the exceedingly unlikely event that a) someone wants to repartition something that uses the floppy disk interface *and* b) it takes over 1 s to respond to a write, it should still be possible to use GParted on it manually (the decreased timeout need only apply to autodetection). On the other hand, in your scenario, time taken for autodetection would be reduced by almost 50%, a large gain.
(In reply to comment #20) > 20s 80s Total time from start to end scanning devices Can any scans be performed in parallel? How much can a multi-threaded implementation reduce the processing duration?
Thank you Simetrical for your insightful comments. And thank you Markus for your comments here and on bug 453555. Especially the following comment http://bugzilla.gnome.org/show_bug.cgi?id=453555#c12 in which you point out that Windows XP does not like having the floppy disabled in the BIOS. Using the logic that auto detection does not have to be 100% correct (a workaround of providing the device name to gparted is available), it would be preferable to limit the time spent scanning floppy devices. There are two areas to address this problem: 1) Limit or eliminate time in GParted validating floppy devices. Unfortunately the libparted function calls used by GParted do not appear to provide control over the device timeout. The calls used are: void ped_device_probe_all () int ped_device_open (PedDevice *dev) int ped_device_read (const PedDevice *dev, void *buffer, PedSector start, PedSector count) Hence I believe the best option would be to skip floppy device names during the "validate device" step in GParted. The device names to be ignored when using autodetection would be: /dev/fd0 /dev/fd1 (Are there others to ignore?) This would cut 36 seconds off of the device validation time listed in comment #20. 2) Log a bug with the Parted team regarding the floppy device / BIOS wrong problem This may reduce the 33 seconds of time spent in ped_device_probe_all(). Following is the Parted bug report: http://parted.alioth.debian.org/cgi-bin/trac.cgi/ticket/194
I think I have come up with a good compromise on this problem. It appears that the misconfigured BIOS floppy device does not get listed in /proc/partitions. So I have written code with the following logic: If /proc/partitions exists, then parse the devices from this file Else use libparted ped_device_probe_all() I have posted a copy of the updated source code at: http://gparted.sf.net/gparted-0.3.7-svn.tar.bz2 Would some of you be able to compile and test this on your systems?
I already did rm /dev/fd0, which solved the problem for me for the moment. I assume it will be regenerated on reboot, but I don't plan to reboot right now. I don't know offhand how to regenerate it manually (I guess some kind of mknod invocation); if you know, I can do that and test whether it fixes the problem. Without /dev/fd0 to slow things down, running your version versus the package now gives the same startup time, about 11 s. However, running the packaged version prints out these errors, which your version does not: Unable to open /dev/hda read-write (Read-only file system). /dev/hda has been opened read-only. Unable to open /dev/hda read-write (Read-only file system). /dev/hda has been opened read-only. Unable to open /dev/hda - unrecognised disk label. (/dev/hda is my optical drive.)
Hi Curtis. #26 may be a good way to go. I have a vague recollection that it may have been done that way a couple of years back so you may want to check back bugs and changelog to see if there were any issues with that. I suspect it was just a short cut to use an existing library fn. You may also want try to build some rapport with the guy doing partedmagic, which as you may know got forked from the gparted live cd project due to some fallout with the previous gparted maintainer who then lost interest. Patrick Vincent, IIRC, is very competant and has resolved a number of issues in gparted that he patches for his live CD. I don't know whether he would want to feed any of that back now there's a new team here but it's worth asking. regards.
Simetrical, thank you for testing out the code. Regarding re-creating the floppy device node (/dev/fd0), you could investigate using the /usr/sbin/MAKEFLOPPIES command. I haven't used this command myself so I don't know much about it. gg, thank you for your comments. Bart had implemented parsing /proc/partitions back on 2006-09-07, and then backed it out on 2006-09-11 stating that libparted had a fix to arrive soon. It appears that the libparted fix never arrived. I did not find any other reasons why Bart reverted back to libparted for probing devices. I investigated Bart's previous code, and then wrote my own for parsing using regular expressions. Patrick Verner did fork a copy of GParted called VisParted. Since GParted development was begun anew, I received an email from Patrick indicating that he plans to stop maintaining the VisParted fork. I had previously looked at the VisParted source code, but do not recall any code fixes in this area.
thanks, that keys in with my fading recollection of that issue, that it had been rather brushed aside. I was not meaning that Patrick had touched this issue but had quite a few mods but it seems you are aware already. good to see things converging again.
(In reply to comment #29) > Simetrical, thank you for testing out the code. Regarding re-creating the > floppy device node (/dev/fd0), you could investigate using the > /usr/sbin/MAKEFLOPPIES command. I haven't used this command myself so I don't > know much about it. After executing that command, which restored /dev/fd0, /usr/bin/gparted was 84 seconds to start up; /usr/local/bin/gparted remained 11 seconds. So the fix works for me.
Thank you for the testing Simetrical.
The changes to parse /proc/partitions if it exists, have been committed to the Gnome repository for inclusion in the next release of GParted. For systems with /proc/partitions, this change removes the need to use the libparted ped_device_probe_all() function call. Closing this bug.
Following are the testing results on my system after this change was applied: CODE FIXED BIOS BIOS BIOS CORRECT WRONG WRONG DESCRIPTION ======= ===== ===== =============================================== ***** STEP 1 ***** 9s 33s - Time spent in libparted's ped_device_probe_all() 0s Time spend parsing /proc/partitions and devices ------- ----- ----- ----------------------------------------------- ***** STEP 2 ***** 0s 0s 0s Time spend reading first sector of hard drives 0s NOTE: This is to validate if device is real ------- ----- ----- ----------------------------------------------- n/a 36s n/a Total time spent reading first sector of floppy drive NOTE: This is to validate if device is real Breakdown of reading floppy drive follows: ----------------------------------------------- n/a 24s n/a - open floppy device ERROR DISPLAYED: Unable to open /dev/fd0 read-write \ (Read-only file system). /dev/fd0 \ has been opened read-only. n/a 12s n/a - read floppy device ERROR DISPLAYED: Input/output error during read on /dev/fd0 n/a 0s n/a - close floppy device ------- ----- ----- ----------------------------------------------- ***** STEP 3 ***** 11s 11s 4s Time spent reading valid device information Breakdown of reading hard drives follows: ----------------------------------------------- 1s 1s 0s - SATA II 500 GB drive with 13 partitions 10s 10s 4s - IDE 160 GB drive with 7 partitions ======= ===== ===== =============================================== 20s 80s 4s Total time from start to end scanning devices