[conspire] Editing Fstab
rick at linuxmafia.com
Mon Dec 5 20:48:16 PST 2005
Quoting John Andrews (jla1200 at netzero.net):
> I'm trying to get a handle on editing the fstab even though it seems
> rather "easy". I finally got it to read a new usb stick using dev
> /sda1, media as the mount point and vfat as the file type. and the
> rest similar to the other entrys.What would be the dev type of a
> digital camera? What file type? and other entries noauto, etc.
Now, _there's_ an interesting question. I hope you don't mind if I peel
it rather like an onion -- sort of in reverse, really, starting with the
simple core and gradually pasting some of the peel back onto it -- as
that seems both the most fruitful and the laziest way to approach it.
The first part of that is how to mount USB block-device (mass storage)
media such as USB flash drives -- which turns out to generalise nicely
to other mass storage devices reached over USB, such as various types of
non-volatile media inside digital cameras.
_Linux Journal_ was kind enough to publish my modest little article on
using USB flash drives on Linux:
You may want to read the full article for details, but, after discussing
the necessary kernel modules and how to ensure that they're loaded, the
piece mentions an /etc/fstab entry you want to add (if it's not already
there) to enable /proc's tracking of USB devices:
none /proc/bus/usb usbdevfs defaults 0 0
(Do "mount -a" at the root-user prompt to activate that mount, and
simultaneously check your syntax. ;-> )
More than likely, you won't need to make that edit -- you'll probably
already have that /etc/fstab line and the consequent /proc/bus/usb tree
Last, my article went on to describe the most straight-forward,
simple-minded way to -- at last -- mount the actual flash drive, which
will be addressable either as /dev/sdX (X=a,b,c, etc.) or as /dev/sdXN
(N=1,2,3, etc.), depending on whether the flash drive emulates a hard
disk or a floppy disk: Any random flash drive might be one or the
other, without particular rhyme or reason.
Why an /dev/sd?? device, you might wonder. Well, this is kernel
programmers practicing what Larry Wall calls one of the cardinal virtues
of programmers: laziness. How to address SCSI mass-storage (and other)
devices is already a very well-solved problem, so, shimming the SCSI
layer into USB-device addressing made the problem easier. The fact that
these aren't _really_ SCSI devices is true but beside the point: It was
the easiest, quickest, and most-reliable way to solve the problem.
I described how to solve the USB-flash-drive problem despite the fact
that you'd already solved it, because it's the gateway to solving other,
similar problems, such as addressing USB-connected digital cameras
operating in mass-storage mode, or other memory-technology devices
You'll notice my qualifier in the above: "operating in mass-storage mode".
Let me add another onion layer, and also introduce you to one of my
link-farm pages, the one for Linux hardware-support Web sites. Start at
my knowledgebase, http://linuxmafia.com/kb/ , and pick the Hardware
category, thereby going to http://linuxmafia.com/kb/Hardware/ . Notice
the entry for "Help Resources", described as "List of info. resources
for all hardware categories...." Picking _that_ link, you (finally)
arrive at my hardware-support link farm page:
You'll probably find a number of relevant entries, but the one I want to
call your attention to immediately is "Digital cameras (see also USB,
Firewire, etc.): http://www.teaser.fr/~hfiguiere/linux/digicam.html".
Go there, please.
You will notice that the page clarifies that USB-connectable digital
cameras (not including some with crazy proprietary protocols) connect
using either a mass-storage, random access "USB Mass Storage" mode or a
streaming, serial-port-like "PTP" = Picture Transfer Protocol (aka Still
Image Device) mode. There will usually be tiny switch on the camera
chassis, to select which addressing mode to use.
The page goes into some detail on Linux ramifications, including the use
of gPhoto2 as a nearly universal Linux software solution, since it
understands how to do PTP and in general does all the right things.
Some digital cameras (I'm talking still-photo cameras, for simplicity's
sake) will sport Firewire aka IEEE-1394 ports instead of USB -- or in
addition to USB. Frankly, the situation's pretty much exactly the same,
except using slightly different Linux drivers: You load a couple of
kernel drivers that shim onto SCSI mass storage support, et voilo: You
have storage on your camera addressable as /dev/sdX or /dev/sdXN.
My link farm has Firewire information linked as
"http://www.linux1394.org/", which please see if that applies to your
Filesystem type? Pretty much inevitably vfat. VFAT is not very good,
but it's a lingua franca, you see. You can usually in theory reformat
to use something else, but probably shouldn't if only because it limits
whom you can hand your camera's flash media to (comprehensibly, anyway).
What my article did _not_ cover is Linux's Hotplug subsystem, which you
can and should read about at http://linux-hotplug.sourceforge.net/ , and
which is another outer layer of that onion. The point of Hotplug is to
move past my article's primordial-Unixey approach of manually mounting
and umounting devices, instead taking care automaticdally of all tasks
that would ordinarily have to be handled manually, when plugging and
unplugging removable devices.
You ask about "noauto": That mount option (in /etc/fstab) specifies
that the device described on that /etc/fstab line is _not_ to be
automatically mounted at boot time, as part of the startup process.
You might well, for example, include that option for CD-ROM/CD-R[W],
DVD, floppy, and similar devices.
Along those same lines, please note my article's suggestion about the
> How do I get a Netzero.deb file to install ? I transfered it from
> the usb stick okay but then it was a read only file or not a
> directory and i couldn't install it. I tried as root. dpgk install
> netzero.deb but it didn't work.
Googling on the name "netzero.deb" suggests that you are probably
talking about Netzero's proprietary dialer software, done up as a binary
package for LinspireOS/LindowsOS. Linspire uses the ".deb" package
format characteristic of Debian (and also innumerable other
You did not identify your distribution: That may be an absolutely
crucial factor -- but I cannot address that, because you didn't specify.
Making the optimal assumption, let's assume that you're running either
LinspireOS or some other Debian-compatible Linux distribution that is
reasonably close in version numbers to the LinspireOS release for which
your netzero.deb package is intended. In that case, you become the root
user, "cd" to wherever the package file is sitting, and then install it
using "dpkg -i", like this:
$ su -
# cd /tmp
# dpkg -i netzero.deb
This assumes, of course, that you've put netzero.deb into /tmp.
Presumably, you already did try something roughly like that, and
encountered some problem or other -- but your description was
unfortunately sufficiently inexact that it's difficult to understand
what problem you encountered.
Maybe, if you don't mind, you can try again and note down _exactly_ what
happened. Ideally, you would copy-and-paste the commands you type and
precisely what the return text is from your command session, or use the
"script" utility to log your session to disk -- and post relevant
sections here so we can see exactly what you're running into.
Not intending to be critical, but where you say "dpkg install netzero.deb"
is a case in point: "install" is not a valid parameter for the "dpkg"
command. "-i" or "--install" are valid options, however -- and might
very well have been what you typed on the affected systems, and meant to
type here -- but we cannot tell from what you said.
Rick Moen "Anger makes dull men witty, but it keeps them poor."
rick at linuxmafia.com -- Elizabeth Tudor
More information about the conspire