USB floppy automounting takes very long

This bug also occurs in the flight 3 Dapper live CD, but does not occur in Gnoppix or any KDE-based live CDs.

--Dane

So the device is not automatically mounted?

After the floppy is mounted, can you please do

 cat /etc/mtab

and

  ls -l /etc/mtab

and copy the output here?

Do you happen to have /etc/mtab symlinked to /proc/mounts?

Thanks or the reply, Martin.

The behavior has changed recently, possibly due to the latest updates (in both breezy and dapper flight 4). Now what happens is that once I put the floppy in the disk drive, it takes about 2 minutes (!) for the green light to turn off, but after that, it mounts and opens up a window in the file manager, displaying all the files on the drive.

When I unmount it, by right-clicking on the icon in the file manager, it unmounts nice and fast but displays an error: Unable to eject media. This makes sense because the floppy drive does not support autoejecting. Remounting it again causes it to take about another 2 minutes, but evenutally it opens a window and functions properly.

Here is the output you requested:

dane@TopHat:~$ cat /etc/mtab
/dev/hda1 / ext3 rw,errors=remount-ro 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs rw,noexec,nosuid,nodev 0 0
usbfs /proc/bus/usb usbfs rw 0 0
tmpfs /lib/modules/2.6.12-10-686/volatile tmpfs rw,mode=0755 0 0
shm /dev/shm tmpfs rw,noexec,nosuid,nodev 0 0
tmpfs /dev tmpfs rw,size=10M,mode=0755 0 0
/dev/sda /media/floppy vfat rw,nosuid,nodev,quiet,shortname=winnt,uid=1002,gid=1002,umask=077,iocharset=utf8 0 0

dane@TopHat:~$ ls -l /etc/mtab
-rw-r--r-- 1 root root 482 2006-02-20 12:08 /etc/mtab

Hope this helps.

If pmout works fast, then I assume that this is a hal issue. Can you please do a full hal debug output as described on the second half of http://wiki.ubuntu.com/DebuggingRemovableDevices ? After that, please do

  dmesg > dmesg.txt

and attach dmesg.txt here, too. Thanks!

Some requested output.

some requested output

some requested output

some requested output

Here's some more of the output from the hal debugging page:

dane@TopHat:~$ id
uid=1002(dane) gid=1002(dane) groups=4(adm),20(dialout),21(fax),24(cdrom),25(floppy),26(tape),29(audio),30(dip),44(video),46(plugdev),104(lpadmin),105(scanner),106(admin),1002(dane)

dane@TopHat:~$ id hal
uid=111(hal) gid=111(hal) groups=111(hal),24(cdrom),25(floppy),46(plugdev)

dane@TopHat:~$ uname -a
Linux TopHat 2.6.12-10-686 #1 Mon Jan 16 17:58:04 UTC 2006 i686 GNU/Linux

More attachments on the way...

Need anything else?

Thanks!

Thanks; you picked the wrong half of the page (I asked for the hald debug output on the second half). Anyway, this is obsolete now since your dmesg.txt already revealed the problem:

[4295128.689000] SCSI error : <1 0 0 0> return code = 0x8000002
[4295128.689000] sda: Current: sense key: Medium Error
[4295128.689000] Additional sense: Id CRC or ECC error
[4295156.603000] UDF-fs: No partition found (1)

So your kernel needs this long time while blocking on a read result from the floppy drive. Maybe you can try another medium?

I just tried a brand-new IBM-formatted floppy disk, and got the same results. Also, as you may have missed it above in all the posts, I am using kernel 2.6.12 on my installed Breezy system, and kernel 2.6.15 on the Dapper Live CD.

I also just tried using the command, "pmount /dev/sda /media/floppy" and got the same long mount time as when it attempts to automount it. I also just did all the online updates in hopes that it would get fixed, but to no avail.

If this is a kernel problem, it appears to be in both 2.6.12 and 2.6.15.

Thanks for checking again. It still looks suspiciously hardware-related, but if the floppy drive works well on other computers or under Windows, then it must be a kernel bug.

I've just finished testing the floppy drive on several of systems; the original computer is Ubuntu Breezy on a P4-generation Celeron. Here are the results:

Ubuntu Breezy on P4/Celeron: takes a long time to mount (mounts and opens automatically). HAL and pmount are installed. Killing hald and using "pmount /dev/sda" takes a long time to mount, but eventually mounts it on /media/sda. Keeping hald "dead" and using "mount /dev/sda /mnt/test" mounts it in under 10 seconds.

Gentoo 2.6.15 on AMD64: mounts in under 10 seconds using the command, "mount /dev/sda /mnt/floppy2". HAL and pmount are not installed on this system.

Mepis 2.6.15 on Pentium 3: takes a really long time to mount (by clicking on the floppy icon that appears on the desktop). HAL and pmount are installed. Killing hald and then using "pmount /dev/sda" causes it to take a long time to mount (but it eventually shows up on /media/sda). Keeping hald "dead" and doing "mount /dev/sda /mnt/sda" mounts it in under 15 seconds.

Gnoppix Live 2.6.10 on Pentium 3: Mounts in under 15 seconds (mounts and opens automatically). HAL and pmount are installed.

I hope some of this is helpful. What do you make of it?

One more thing:

I just tried leaving hald running on the original computer (P4/Celeron) and unmounting the drive (since in mounts it automatically) then mounting it manually using, "mount /dev/sda /mnt/test". It mounted in under 10 seconds.

I just installed the latest updates for Dapper. The problem seems to have been fixed in all kernels. I suspect that it was a problem with either pmount or HAL.

In Breezy the problem still exists.

Thank you for checking this again. However, this problem is way too complicated to fix it in Breezy, so a fixed Dapper will have to do (only six weeks left! :) )

Any time :-). Thanks for the fix!

I tried the Dapper i386 Desktop Cd live environment and experienced the same problem :

 doubleclick on the floppy icon na dit takes about a minute to do something and then it does NOT open the floppy contents. Doubleclicking it again finaly opens the contents. (file list window).

The same happens with the other floppy unit, which is an ATA floppy (LS-120).

During the long "something" it does not wait on error or like, but actually reads the floppy. Click..click...click... like when formatting or doing a sector copy. After a while I started counting the clicks and counted 21. So there were at least 40 clicks or more, meaning, at least half of the floppy was read in.