Tim:
No, I'm saying that dynamically connected things don't have an entry
written for them in the fstab file, automatically. Additional to that,
you wouldn't mount them in that abbreviated manner, manually.
Marko Vojinovic:
No? And what service provides automatic mounting (in runlevel 3, no X active)?
There wasn't one.
And what if automounter doesn't work as expected?
You're equally up the creek without a paddle.
This situation is not good, and you're not the first to complain about
it. I haven't seen a decent suggestion about resolving it. I've seen
comments to use gnome-mount, which as we both feel, sounds silly. Not
to mention being yet another thing to learn, and a convoluted thing, at
that.
And I've seen arguments on both sides as to whether a text only mode
should have an automounter. Myself, I feel that if you've plugged a
flashdrive into the socket, you want to use it. Why should you have to
play the role of the computer to mount it?
Yes, I see the need in proper dismounting before an unplug, but there's
a world of difference between a simple "dismount flashdrive" command and
a varying "mount /dev/variable-name ..." command.
I plug in my USB flash memory, kernel detects it, udev creates /dev/sdb for
it, and that's it. There is nothing in /media, nothing in /mnt. I have to su
to root, and manually mount it via
# mount -t vfat /dev/sdb /some/directory
which of course works, but is a pain since only root has privileges for
accessing the data.
A difficulty with this, that you'd otherwise put entries into the fstab
file, is that you can't always predict which device a removeable drive
will be found at. You might have two drives, that aren't always used.
Today your flashdrive might be /dev/sdb tomorrow it could be /dev/sdc.
The move towards drive labels avoids that issue. But it's a right
nightmare to add a label to a Microsoft filesystem on Linux.
So what is the name of the daemon that should do all this
for me? (it doesn't seem to work properly, so I need to tweak with it...)
Last I looked into it, it was some interaction between HAL and either
Gnome or KDE.
or you can use gnome-mount to get it work out the details.
Well, I tried something like
$ gnome-mount --device /dev/sdb
and the first thing it did was to complain that there is no X running (!!),
than it falls back to text-mode, complains that it cannot find any partitions
on /dev/sdb, and fails. It does not detect the filesystem, it does not read
off the label, it does not create a mount point.
Shouldn't that be something like sdb1 rather than just sdb?
But I think that the fault is in hal not providing appropriate info for it,
since "lshal | grep sdb" returns nothing. Hal does not seem to have detected
the flash memory, so gnome-mount knows nothing about it.
Just to muddy the waters, there's been a bit of an ongoing issue with
udev and USB devices lately. Some people have been unable to mount
things. I think it must be hardware dependent, as I don't have those
problems (currently).
I haven't quite got around to looking at manual mounting on FC7, it's
working automatically for me, quite fine.
I think you might want to have a look at man gnome-mount
Besides from not being intended for direct usage, I get the feeling that it
simply does not work properly without Gnome running. It reads settings from
gconf (which may not exist)
Yes, I don't think much of things that rely on gnome-something (gconf,
etc.), when Gnome shouldn't be a requirement. I've been right peeved at
gconf, just lately, trying to sort out a keyboard issue. That's
something that I don't think should be handled by gconf.
All in all, I believe the culprit is hal in this particular case. But how do I
get it to work?
I think you need to look into how to make HAL rules. It's changed a lot
since the last time I looked at that (I had to fiddle around to get a
digital camera mounted to read its files - that was a nightmare). But I
still feel that the user shouldn't have to go around modifying HAL rules
for something as commonplace as a flash drive.
Of course, I can always edit /etc/fstab and put in appropriate data by hand,
and this will work, but that is a workaround, not a solution, right?
I tend to agree. You paint yourself into a corner trying to write fixed
rules for non-fixed media.