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:
Code:
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:
Code:
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’
(http://tinyurl.com/8652w3)
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.
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.
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.
Mike_unique;1930978 Wrote:
> It does appear to be different.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 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.
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.
