OpenSUSE 11.1 64 bit w/ KDE 3.5 and OpenSUSE 11.0 32 bit w/ KDE 3.5.
Using the KDE floppy desktop icon failed to mount a 720 kb floppy.
Using the 64 bit SUSE with a root shell I manually mounted a 720 kb floppy and it worked:
mount -v -t vfat /dev/fd0 /media
However, this SUSE mount:
mount -v -t auto /dev/fd0 /media
failed with this error:
mount: you must specify the filesystem type
So I tried this on the Fedora 8 box:
mount -v -t auto /dev/fd0 /media
and because of the -v it had these messages:
mount: you didn't specify a filesystem type for /dev/fd0
I will try type vfat
It works on the Fedora box.
Is mount(8) broken in SUSE? It does appear to be different.
This stared in this thread, but I couldn’t see how to change the main thread title (I wanted to bump it with a new title):
Can’t mount 720k floppy in 11.1 - openSUSE Forums
You’d have to get more info out of mount to see what it is doing. According to the man page mount uses a heuristic when auto is in effect.
If no -t option is given, or if the auto type is specified, mount will try to guess the desired type. Mount uses the blkid or volume_id library for guessing the filesystem type; if that does not turn up anything that looks familiar, mount will try to read the file /etc/filesystems, or, if that does not exist, /proc/filesystems. All of the filesystem types listed there will be tried, except for those that are labeled “nodev” (e.g., devpts, proc and nfs). If /etc/filesystems ends in a line with a single * only, mount will read /proc/filesystems afterwards.
On 11.1 the file /etc/filesystems exists and vfat is on top. So the other possibility is that mount could not guess correctly. The way around it would be to try to edit the udev rules so that a type of vfat is used for the floppy device. Unfortunately I am not sufficiently conversant with udev rules to tell you how.
Given that I used the -v (verbose) option I would say SUSE mount(8) never even tried to guess. It certainly didn’t report any wrong guesses. I don’t see how the order of guesses or wrong guesses would apply if it doesn’t even try.
If a tree falls in a forest, and nobody hears it, does that mean that the tree is still standing? 
How do you know that -v is telling you everything it’s doing? There is also a -f option, I don’t know if that will tell you more. Maybe the only way to find out would be to read the source, unfortunately.
By comparison with Fedora 8 I would expect better than an opaque lack of reporting from -v. A failure of -v would be a bug all by itself. Other than misleading any attempt to diagnose problems using mount(8), whats the point of having a verbose reporting option that doesn’t work? It would be far better to return an error message that -v is not supported instead.
I agree, that reading through the SUSE mount(8) source or running it in a debugging session would be the only way to know for sure what its really doing. Any volunteers? In the meantime it still looks like a potential bug to me.
It could be that Fedora mount had some extra features added or that mount has had some debugging output removed since then.
I would say -v isn’t debugging output, its really diagnostic reporting. Debugging output is usually inserted in source code during development or maintenance. Yes, -v output could have been trimmed, at the expense of clarity and usability.
Its obvious the SUSE floppy desktop icon mount isn’t using vfat on the 720 kb format floppies, because -t vfat worked. Since it does mount 1.44 mb format floppies, it must be using some kind of mount option, which I would expect to be -t auto. The -t auto not working on the 720 kb format floppies supports this expectation. Broken is broken, no matter who broke it, when they broke it or how they broke it. For a Fedora enhancement to be a factor, it would have to more than a simple -v message change. It would have to be a functional change in the mount(8) function. Is it a possibility that mount(8) isn’t supposed to work for -t auto with 720 kb floppies any longer? I don’t know for sure. I haven’t made extensive use of mount in Linux. I used to use its ancestor allot in the late 80’s when I wrote Unix device drivers (under the not-evil AT&T source license, before SCO).
My focus is on if its a bug or not. If its a bug I think warning alarms should sound at SUSE since this is an essential function of the O.S. (who knows what else may be broken, did someone forget to setup the proper compile configuration flags, is their source copy the wrong one, is their source corrupted, who knows until its checked).
It’s all speculation until one can see what mount is doing, how it’s guessing the fstype, what the interaction with the floppy driver is, and so forth.
PS: I’m not a developer and have no dealings with Novell, other than as a user, so your reportage might more likely be actioned at the Novell Bugzilla.