| Summary: | regression: udisks-daemon keeps forcibly unmounting floppies | ||
|---|---|---|---|
| Product: | udisks | Reporter: | Ian Abbott <ian> |
| Component: | operations | Assignee: | David Zeuthen (not reading bugmail) <zeuthen> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | aklhfex, atlantida, ballogyor, biru.ionut, freedesktop, paulepanter, ssuominen |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
udisks --dump
udevadm info --export-db udevadm info --export-db /proc/self/mountinfo /proc/self/mountinfo udevadm info --export-d /etc/fstab Output of 'udisks --monitor-detail' while mounting floppy simple patch 'udisks --monitor-detail' with Atlant's patch |
||
Created attachment 38817 [details]
udevadm info --export-db
Created attachment 38818 [details]
udevadm info --export-db
Created attachment 38821 [details]
/proc/self/mountinfo
Created attachment 38822 [details]
/proc/self/mountinfo
Created attachment 38823 [details]
udevadm info --export-d
Created attachment 38824 [details]
/etc/fstab
Versions: udisks-1.0.1 plus "Update to latest LVM2 API" and "Fix long hangs on probing nonexistant floppy drives" patches (commits 2b2fcf80841972b70ad695a5a1ed74487d4fd37a and ca93d4e2d9e7f483b2fde1725da086e2cca44164). gvfs-1.6.3 libatasmart-0.17 Created attachment 38825 [details]
Output of 'udisks --monitor-detail' while mounting floppy
'gvfs-mount -oi' didn't capture anything. 'udevadm monitor --udev --property' (as root) didn't capture anything useful, just the following... monitor will print the received events for: UDEV - the event which udev sends out after rule processing (Sorry for all the obsoleted attachments. Firefox was playing silly buggers and attaching the file above the one I selected.) Created attachment 39751 [details] [review] simple patch plz, test this patch ! (In reply to comment #12) > Created an attachment (id=39751) [details] > simple patch > > plz, test this patch ! I'm sure that would work as it revokes commit 2b2fcf80841972b70ad695a5a1ed74487d4fd37a ("Fix long hangs on probing nonexistant floppy drives"), but then a less crude fix for the "long hangs probing" problem would be required. (In reply to comment #13) > (In reply to comment #12) > > Created an attachment (id=39751) [details] [details] > > simple patch > > > > plz, test this patch ! > > I'm sure that would work as it revokes commit > 2b2fcf80841972b70ad695a5a1ed74487d4fd37a ("Fix long hangs on probing > nonexistant floppy drives"), but then a less crude fix for the "long hangs > probing" problem would be required. Sorry, my mistake, Atlant! My above comment is wrong. I'll try your patch. Created attachment 39761 [details] 'udisks --monitor-detail' with Atlant's patch (In reply to comment #12) > Created an attachment (id=39751) [details] > simple patch > > plz, test this patch ! I've tested your patch and it works for me! I've attached the output of 'udisks --monitor-detail' with udisks-daemon running (compiled from git head plus your patch (id=39751)). The output is a result of a 'mount /mnt/floppy' command, where /mnt/floppy is listed as the mount point of /dev/fd0 in my /etc/fstab file: /dev/fd0 /mnt/floppy auto noauto,user 0 0 The floppy was mounted successfully and no longer forcibly unmounted by udisks-daemon immediately after. I could also unmount the floppy and mount it again with no problems. I don't know what effect your patch has on the "long hangs on probing nonexistant floppy drives" fix as I couldn't reproduce the problem on a stock udisks-1.0.1 installation on my system even when the floppy drive was unplugged from its controller. (In reply to comment #15) > I don't know what effect your patch has on the "long hangs on probing > nonexistant floppy drives" fix as I couldn't reproduce the problem on a stock > udisks-1.0.1 installation on my system even when the floppy drive was unplugged > from its controller. The patch against the "long hangs on probing > nonexistant floppy drives" is already applied in GIT, several lines above my changes (In reply to comment #16) > (In reply to comment #15) > > I don't know what effect your patch has on the "long hangs on probing > > nonexistant floppy drives" fix as I couldn't reproduce the problem on a stock > > udisks-1.0.1 installation on my system even when the floppy drive was unplugged > > from its controller. > > The patch against the "long hangs on probing > nonexistant floppy drives" is already applied in GIT, several lines above my changes I was just trying to check that your patch didn't regress the "long hangs" bug as it's in the same function. Atlant's patch works for me also. What is the current state? Is anybody deal with this bug? I don't think they care or are even aware that the bug is over 2 years old and still is showing as "NEW" in the bug tracker. It seems their "poor" developers can't even spend 10 dollars on a floppy drive to test. (Hell, I'll ship 'em one for free if they'll give me the address and guarantee that they'll to fix the bug--and I'm an unemployed college student with two kids and a wife!) The problem is that the developers think floppies are obsolete, even though there are many items still in use that require floppies (such as an early 90's, high-end, $4000--original price--Roland Electronic Piano that reads midi files on a floppy disk). Lots of users still affected by this regression, se bug 441835 at launchpad for example. Yes, floppys are an obsolete media, still, users like me, sometimes have to get data off retro-computers and alike. Sometimes this is the only way.. Devs,Please have a look a this soon. Thanks. What is the status here? Sister bug http://bugs.gentoo.org/338185 has been open for too long. Is this still a problem with udisks2? (In reply to comment #21) > What is the status here? Sister bug http://bugs.gentoo.org/338185 has been open > for too long. It's not really something I'm planning to spend time on in udisks since a) I'm focusing on udisks2; and b) floppies are extremely rare nowadays. > Is this still a problem with udisks2? I doubt it's a problem with udisks2.. in fact, last I checked, all the parts in the stack (kernel, udisks2, gvfs, nautilus) worked fine with floppies, see http://people.freedesktop.org/~david/palimpsest-gvfs-udisks2-pc-floppy.png But it's not something I check very often and in Fedora we never automatically load floppy.ko even if the hardware is there. I'll check Monday when I'm in the office - don't have any floppy drives or disks here :-) (In reply to comment #22) > I doubt it's a problem with udisks2.. in fact, last I checked, all the parts in > the stack (kernel, udisks2, gvfs, nautilus) worked fine with floppies, see > > http://people.freedesktop.org/~david/palimpsest-gvfs-udisks2-pc-floppy.png > > But it's not something I check very often and in Fedora we never automatically > load floppy.ko even if the hardware is there. I'll check Monday when I'm in the > office - don't have any floppy drives or disks here :-) It works fine except for the fact that there's a bug in mount(8)... basically 'mount /dev/fd0 /mnt' doesn't work but 'mount -tvfat /dev/fd0 /mnt' does. I've reported this bug to Karel Zak (the util-linux maintainer). (In reply to comment #22) > (In reply to comment #21) > > What is the status here? Sister bug http://bugs.gentoo.org/338185 has been open > > for too long. > > It's not really something I'm planning to spend time on in udisks since a) I'm > focusing on udisks2; and b) floppies are extremely rare nowadays. Also in Debian there are several reports regarding that issue. 561737: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561737 561746: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561746 592719: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592719 596890: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596890 622618: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622618 669973: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669973 Having a working udisks2 package will not be enough, since that one will not be ported back to already released distribution versions. I wonder if there are problems with RedHat or openSUSE too. Or do they ship an earlier version not affected by this regression. Anyway, it is known what caused the regression. So it would be great if the attached patch to this report – which has been tested – could be applied. The problem of systems having a delay during start up because no floppy drive is attached should be able to be fixed differently. Since the commit message of the commit causing the regression does not specify the root cause, I can only guess. Is the floppy module doing the probing or udev? If we figure that out people affected by a crappy BIOS should be able to pass in a command line option and be done with it. […] Even if floppies are rare on the general desktop, I would sure like to see this fixed. Floppies still have a strong niche in specialty equipment. I have a bunch of machines here with floppy drives. Is there a work-around? Older version that works? Udisks2? Other? OK, long time without an update. In the mean time development focus has been udisks 2.0 which is a completely different codebase where floppy disks actually work. Since udisks 2.0 has been shipping in distros since the spring, I'm not really interested in fixing this for udisks 1.x. So I'm closing it as WORKSFORME. Apologies if this is inconvenient for you but please do update to the latest version. Thanks! Tagging this as WORKFORME is not acceptable and simply not true. Ubuntu 10.04 is LTS and use this non working version of udisk. 12.04 is LTS too and also use this piece of crap that is the last 1.x version. Some might consider beyond them as to why some people still use floppies but they do : in the professional world, a lot of appliances, industrial equipments rely on floppies, like machinetools... Overlooking floppies as not worth a debug is despising at best, irresponsible at worst. Please fix ASAP or cancel officially your last 1.x version so that the former and working version (1.0.1-1build1) is not replaced by this buggy one on our Ubuntu's. Assuming Atlant's patch in comment 12 doesn't reintroduce the "long hangs on probing non-existant floppy drives" bug (which I've not managed to test myself as I couldn't reproduce the original problem), couldn't Atlant's patch be applied and be done with it? Or are the two bugs mutually unfixable? (In reply to comment #27) > Tagging this as WORKFORME is not acceptable and simply not true. > Ubuntu 10.04 is LTS and use this non working version of udisk. > 12.04 is LTS too and also use this piece of crap that is the last 1.x > version. > > Some might consider beyond them as to why some people still use floppies but > they do : in the professional world, a lot of appliances, industrial > equipments rely on floppies, like machinetools... > Overlooking floppies as not worth a debug is despising at best, > irresponsible at worst. > Please fix ASAP or cancel officially your last 1.x version so that the > former and working version (1.0.1-1build1) is not replaced by this buggy one > on our Ubuntu's. I'm sorry that you are unhappy about Ubuntu but that's not my problem. As I said, udisks upstream - as well as many downstream distributors of our software - have moved on to udisks 2.x. I'm also sorry you are not happy to learn that your problem is fixed in the latest version. To put it very bluntly, we don't care much about udisks 1.x anymore (we especially don't often listen to people calling it a "piece of crap") and we don't work much on it except for security bug-fixes. Because of this, we don't want our bug database to be littered with bugs that are never going to get fixed. So I'm closing this bug again. Don't reopen it or you will get banned. (In reply to comment #29) > To put it very bluntly, we don't care much about udisks 1.x anymore (we > especially don't often listen to people calling it a "piece of crap") and we > don't work much on it except for security bug-fixes. Because of this, we > don't want our bug database to be littered with bugs that are never going to > get fixed. So I'm closing this bug again. Don't reopen it or you will get > banned. Perhaps it should be resolved as WONTFIX rather than WORKSFORME in that case? (In reply to comment #30) > Perhaps it should be resolved as WONTFIX rather than WORKSFORME in that case? If the issue wasn't fixed in 2.x and it's not an issue that I wanted to fix I would have closed it WONTFIX. If the issue was fixed in response to the bug, I'd close it with resolution FIXED. But since the issue is already an non-issue in the latest version, I chose to close it WORKSFORME. At least that's how I use Bugzilla. Other maintainers may use it in different ways. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 38816 [details] udisks --dump I'm using Gentoo's udisks-1.0.1-r2, which is effectively udisks-1.0.1 plus the "Update to latest LVM2 API" patch (commit 2b2fcf80841972b70ad695a5a1ed74487d4fd37a) and the "Fix long hangs on probing nonexistant floppy drives" patch (commit ca93d4e2d9e7f483b2fde1725da086e2cca44164). The problem is with the latter patch. If udisks-daemon is running, then after using the 'mount' command to mount a filesystem on an inserted floppy disk, the mount succeeds, but immediately afterwards, udisks-daemon steps in and forcibly unmounts it again! The problem seems to be due to the handling of media change notification. The "Fix long hangs on probing nonexistant floppy drives" patch modifies update_info() in "src/device.c" so that the device_is_media_available flag is always set to FALSE for a (removable) floppy drive. Consequently, the file system gets forcibly unmounted because udisks-daemon thinks the mounted medium has gone away! Mounting the floppy with the 'udisks --mount' command works, but it ought to be possible to use the regular 'mount' command.