Bug 30283 - regression: udisks-daemon keeps forcibly unmounting floppies
Summary: regression: udisks-daemon keeps forcibly unmounting floppies
Status: RESOLVED WORKSFORME
Alias: None
Product: udisks
Classification: Unclassified
Component: operations (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: David Zeuthen (not reading bugmail)
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-20 08:52 UTC by Ian Abbott
Modified: 2012-11-15 15:45 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:


Attachments
udisks --dump (33.19 KB, text/plain)
2010-09-20 08:52 UTC, Ian Abbott
Details
udevadm info --export-db (4.00 KB, text/plain)
2010-09-20 08:54 UTC, Ian Abbott
Details
udevadm info --export-db (4.00 KB, text/plain)
2010-09-20 08:57 UTC, Ian Abbott
Details
/proc/self/mountinfo (817 bytes, text/plain)
2010-09-20 09:02 UTC, Ian Abbott
Details
/proc/self/mountinfo (2.83 KB, text/plain)
2010-09-20 09:03 UTC, Ian Abbott
Details
udevadm info --export-d (211.91 KB, text/plain)
2010-09-20 09:06 UTC, Ian Abbott
Details
/etc/fstab (1.67 KB, text/plain)
2010-09-20 09:07 UTC, Ian Abbott
Details
Output of 'udisks --monitor-detail' while mounting floppy (3.70 KB, text/plain)
2010-09-20 09:15 UTC, Ian Abbott
Details
simple patch (536 bytes, patch)
2010-10-24 22:44 UTC, Atlant
Details | Splinter Review
'udisks --monitor-detail' with Atlant's patch (1.83 KB, text/plain)
2010-10-25 07:31 UTC, Ian Abbott
Details

Description Ian Abbott 2010-09-20 08:52:18 UTC
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.
Comment 1 Ian Abbott 2010-09-20 08:54:20 UTC
Created attachment 38817 [details]
udevadm info --export-db
Comment 2 Ian Abbott 2010-09-20 08:57:47 UTC
Created attachment 38818 [details]
udevadm info --export-db
Comment 3 Ian Abbott 2010-09-20 09:02:18 UTC
Created attachment 38821 [details]
/proc/self/mountinfo
Comment 4 Ian Abbott 2010-09-20 09:03:42 UTC
Created attachment 38822 [details]
/proc/self/mountinfo
Comment 5 Ian Abbott 2010-09-20 09:06:17 UTC
Created attachment 38823 [details]
udevadm info --export-d
Comment 6 Ian Abbott 2010-09-20 09:07:31 UTC
Created attachment 38824 [details]
/etc/fstab
Comment 7 Ian Abbott 2010-09-20 09:10:55 UTC
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
Comment 8 Ian Abbott 2010-09-20 09:15:51 UTC
Created attachment 38825 [details]
Output of 'udisks --monitor-detail' while mounting floppy
Comment 9 Ian Abbott 2010-09-20 09:18:11 UTC
'gvfs-mount -oi' didn't capture anything.
Comment 10 Ian Abbott 2010-09-20 09:20:57 UTC
'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
Comment 11 Ian Abbott 2010-09-20 09:25:22 UTC
(Sorry for all the obsoleted attachments. Firefox was playing silly buggers and attaching the file above the one I selected.)
Comment 12 Atlant 2010-10-24 22:44:52 UTC
Created attachment 39751 [details] [review]
simple patch

plz, test this patch !
Comment 13 Ian Abbott 2010-10-25 02:25:49 UTC
(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.
Comment 14 Ian Abbott 2010-10-25 02:42:53 UTC
(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.
Comment 15 Ian Abbott 2010-10-25 07:31:34 UTC
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.
Comment 16 Atlant 2010-10-26 05:39:09 UTC
(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
Comment 17 Ian Abbott 2010-10-26 05:49:13 UTC
(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.
Comment 18 Balló György 2011-01-22 17:55:34 UTC
Atlant's patch works for me also.
What is the current state? Is anybody deal with this bug?
Comment 19 shoalcreek5 2011-07-30 11:50:17 UTC
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).
Comment 20 northar 2012-02-03 05:33:36 UTC
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.
Comment 21 Samuli Suominen 2012-04-20 10:08:46 UTC
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?
Comment 22 David Zeuthen (not reading bugmail) 2012-04-20 10:56:08 UTC
(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 :-)
Comment 23 David Zeuthen (not reading bugmail) 2012-04-23 07:23:52 UTC
(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).
Comment 24 Paul Menzel 2012-04-25 01:51:28 UTC
(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.

[…]
Comment 25 JD Hupp 2012-07-30 14:59:44 UTC
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?
Comment 26 David Zeuthen (not reading bugmail) 2012-09-28 18:40:13 UTC
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!
Comment 27 Olivier Desportes 2012-11-15 11:00:25 UTC
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.
Comment 28 Ian Abbott 2012-11-15 13:10:38 UTC
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?
Comment 29 David Zeuthen (not reading bugmail) 2012-11-15 15:28:56 UTC
(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.
Comment 30 Ian Abbott 2012-11-15 15:37:10 UTC
(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?
Comment 31 David Zeuthen (not reading bugmail) 2012-11-15 15:45:36 UTC
(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.