The Stealth Desktop Part IV: Removable Drives and Scanners

By Timothy R. Butler | Posted at 11:53 PM

I would like to thank our kind readers for the encouragement and
the appreciation. This time, we turn to issues more related to
hardware. First we will see how to enable removable drives in our Slack
installation, with especial attention to floppies; and then we will
examine how to setup new hardware, using our scanner as an example,
since its setup was tricky.

Accessing removable drives

The classical UNIX answer to accessing removable drives is to bind them to a particular directory in the root filesystem, and the action
for doing this is called “mounting”. Once mounted, the drive would be
transparent to the filesystem until it was no longer necessary. Then
you would “unmount” the drive. When mounted, the drive would be
locked, in order to prevent data loss and corruption. The removable
drives would often be mounted in the administrator console by the
sysadmin; a normal user would not be allowed to change the mounting
status of any device.

This all made sense in a world of bigger, centralized computing; but it is utter nonsense in today's world of desktop personal
computers. Sadly, GNU/Linux inherits the UNIX way of treating
removable drives, and this does not help us in our goal of using
Slackware as a KGX desktop. It is inconvenient to users, and largely
unnecessary. For some time now, other distributions such as Mandrake
used supermount, a special kernel patch that allowed
transparent on-demand mounting and unmounting of devices. But
Slackware does not have it, so we must look for other answers.

After installation, the Slackware system makes removable devices mountable only by root. We need to change this so that our users
could mount/unmount them as they see fit without root's help. The key
to allow this is the file /etc/fstab, which is explained by the
fstab (5) man page. (If you're using Konqueror to read this,
you can see the fstab man page here.) Part
of a typical /etc/fstab file should read like this:

/dev/cdrom       /mnt/cdrom       iso9660 noauto,user,ro   0   0
/dev/fd0         /mnt/floppy      auto noauto,user      0   0

In your Slackware system, changing the lines of /mnt/cdrom and /mnt/floppy in this fashion will make the CD-ROM and floppy drives
available to all users.

What if we're using some kind of USB drive? I have here a Plextor 24/10/40U USB 2.0 driver, which was properly detected and configured
by Mandrake. But the question was, would it be detected by Slackware?
Would I have to edit some arcane config files and do some /dev
filesystem wizardry? No way! What I did is to plug the USB drive and
watch the boot messages for something interesting. At boot time, the
kernel detected the USB drive without problems:

hub.c: new USB device 00:07.2-1, assigned address 2
usb.c: USB device 2 (vend/prod 0x93b/0x10) is not claimed by any active driver.
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
scsi1 : SCSI emulation for USB Mass Storage devices
  Vendor: PLEXTOR Model: CD-R   PX-W2410A  Rev: 1.03
  Type:   CD-ROM ANSI SCSI revision: 02
Attached scsi CD-ROM sr0 at scsi1, channel 0, id 0, lun 0
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 2
USB Mass Storage support registered.

So, I know that the driver was recognized, that it is acessed through SCSI emulation, and that its device name is /dev/sr0. Let's
make this CD Writer accessible under the /mnt/cdrom2 location. To do
this, we must add this line to the /etc/fstab file:

/dev/sr0         /mnt/cdrom2      iso9660 noauto,user,ro   0   0

In fact, we just copied the line for the CD-ROM, changed the device name and the mount directory, and that was it. In order to
access the drives, we have to issue the command mount
[device]
, where [device] can be cdrom or any other
removable drive under /etc/fstab. In the case of the Plextor USB
CD-ROM, all I had to do was to type mount cdrom2 and I was
all set.

One thing to bear in mind is that all removable drives must be mounted, and for most users this is highly inconvenient. The
inconveniences does not necessarily stem from the difficulty of
performing the action, but rather from the difficulty of the whole
concept and idea of mounting and unmounting. This is very difficult
to grasp for most non-technical users, and it is not going to change
until something equivalent to Mandrake's supermount (which allows
transparent mounting/unmounting of removable drives) is integrated
into the mainstream kernel. Take your time training your users on
this task, and make sure they are comfortable doing it.

Accessing floppy drives

Floppy drives are a somewhat special case: they are slow, writable, unreliable, and ubiquitous. Mandrake's supermount allowed
transparent mounting of floppies, but this made data transfer
(especially writing into floppies) very unreliable and prone to data
loss, so this is not a solution.

The traditional way of using floopies in the UNIX world is by mounting them as you would do with any other removable drive, using
the mount and umount commands. While mounted, you
can exchange data with the floppy disk in a suppossedly transparent
way, but, in reality, the slow-as-molasses speed of the floppy disk
data transfer makes this impractical. In my opinion, the best way to
use floppies is to copy the relevant content onto the hard drive, and
when one is finished working on it, then copy the file(s) back into
the floppy. The most appropriate way to do this is by using the
mtools package, but the mtools programs are a set of command-line
utilities, that largely resemble their DOS counterparts. If you are
used to the DOS command line, then fine. But most people aren't, and
they need an easy way to access floppies.

I used to take advantage of the mtools package and a wonderful app, the MTools File Manager, which is an easy-to-use
mtools graphical frontend. I still have that app around, but it is no
longer necessary under Slack (or KDE) for that matter. However, in
case you want to see it, it is available at the MToolsFM homepage.
If you don't have KDE installed, or if you prefer a simpler solution
to use your floppy disks, this program is strongly recommended.

Screenshot of the MTools File Manager

Figure 20

The MTools File Manager. (762×543, 12K)

KDE provides a way to use floppy disks in a transparent way via the floppy:/ KIO Slave. To access the A: floppy, you simply
need to write floppy:/a/in the Konqueror location bar. (If
you are reading this using Konqueror, and you have a floppy disk
inserted into your first floppy drive, you can try browsing its
contents in this link.) The only requirement
for this feature is that you have the mtools utilities installed.
This solution is very easy and straightforward, and in my experience,
it was well understood and received by end-users.

Formatting floppies

Before they can be used, floppy disks should be formatted. Of course, all floppy disks come pre-formatted these days with the DOS
format, but in my experience the factory formatting was very
unreliable and tended to cause data loss, so it is convenient to
re-format the drive. Formatting also is handy when you want to get
rid of all the data at once, because it erases the disk
completely.

You can format disk using the KFloppy utility that comes with KDE. To invoke it, you can type kfloppy in the Run Command dialog
(to see it, press ALT+F2) or in Utilities > KFloppy in the KDE
Menu. You can see a screenshot of KFLoppy on Figure 21.

Screenshot of the KFloppy utility

Figure 21

The KFloppy utility.

An example of hardware setup: The scanner

We could easily go on for hours on how to configure endless devices for your Slackware desktop; but this would be pointless given
the fact that hardware configuration in Slack is, as you were able to
see, mostly easy and straightforward. Given the fact that my office
workstation has a scanner, we'll go on how to configure it as an
example. The scanner in question is a BenQ Scan2Web S2W 4300U.

Scanner management in an UNIX system is done by an application program interface known as SANE (Scanner Access
Now Easy), which is composed of two parts: a
frontend, which is an application that uses the SANE
interface, and a backend, which is a scanner driver which
implements the SANE interface. Most graphical apps in a GNU/Linux
system are SANE-aware; now, the tricky part is getting a SANE driver
for your scanner, that is, finding a suitable backend for it.
Fortunately, SANE supports a wide array of devices, and you have a
good chance of getting your equipment supported. You can refer to the
SANE homepage for more
information.

Since my office workstation is a dual-boot setup, the first time I unpacked the scanner I booted into Windows 98SE and installed the
manufacturer-supplied Windows drivers according to the provided
instructions. The scanner worked
very well, so I got ready to make it available under GNU/Linux. I
booted into Slackware, and voila! The scanner was automatically
configured, and both xsane and kooka (two scanning
applications) were immediately aware of the scanner! I started
scanning pictures in no time. Easy, isn't it?

Well… not that fast. The next day I booted into Slackware, ready to do some scanning, and… nothing! The scanner was absent, and no
app would be able to find it. Checking the console output, the SANE
backend complained that no firmware was available. So, how could I
reproduce the good results of the first boot? I had to start all over
again from GNU/Linux to see what was missing.

Now, let me stress: a great number of scanning devices won't give you any problem in GNU/Linux; and others are going to give
you some issues; mine was in this last category. Plug your scanner to
your computer, boot into Slackware, and see if Kooka or XSane are
aware of it. Only if they don't then consider following these
steps.

First of all, we see that at boot time the kernel recognizes the scanner without any trouble:

# dmesg | grep scanner
usb.c: registered new driver usbscanner
scanner.c: USB scanner device (0x04a5/0x20b0) now attached to scanner0
scanner.c: 0.4.16:USB Scanner Driver

Then we must see what kind of scanner it is. For this, we'll use the sane-find-scanner utility:

# sane-find-scanner

  # No SCSI scanners found. If you expected something different, make sure that
  # you have loaded a SCSI driver for your SCSI adapter.

found USB scanner (vendor=0x04a5, product=0x20b0) at /dev/usb/scanner0
found USB scanner (vendor=0x04a5 [Color], product=0x20b0 [ FlatbedScanner 22]) at libusb:004:002
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

  # Scanners connected to the parallel port or other proprietary ports can't be
  # detected by this program.

The sane-find-scanner tool suggests us to use the scanimage -L command, so we're happy to oblige:

# scanimage -L
device `snapscan:/dev/usb/scanner0' is a Acer FlatbedScanner22 flatbed scanner

So, to summarize: it looks like we have a scanner on the location /dev/usb/scanner0 (automatically recognized by the kernel), and that
such scanner is using the snapscan backend. Then, we could
use the graphical xsane tool to see whether the scanner is
actually usable. But xsane complains about missing
parameters or device not found. How is that possible?

Looking at the SnapScan backend homepage you can get the answer. It turns out that many
scanners of the SnapScan type actually upload their firmware from the
hard disk at the first use of the scanner, and thus they need to be
told where is a firmware file suitable for them. Following the
instructions on the website, I located the
file named u176v046.bin, on my scanner's setup CD, copied it to the hard
drive, and edited the file /etc/sane.d/snapscan.conf with
the appropriate location. That solved the issue; I was able to use
the scanner with great success from that point.

One of the best apps for using your scanner is XSane. XSane is an excellent application done in GTK+ that resembles the vast majority of scanning applets in
Windows. Regrettably, the user interface is less than optimal in my
opinion, just like the Windows applets it sought to emulate. But a
lot of the time this at least is something familiar, so you might
know your way around it. Moreover, it could be used by GIMP as an
acquisition plugin just by placing a symlink in the
~/.gimp-2.0/plug-ins/ directory. You can see a screenshot of XSane in
Figure 22.

Screenshot of the XSane windows

Figure 22

The XSane scanning frontend. (836×555, 235K)
Screenshot of the Kooka scanning application

Figure 23

The Kooka scanning front end for KDE. (664×744, 129K)

On the other hand, Kooka (shown in Figure 23) is a scanning frontend for KDE that looks much more organized. Kooka sets your scanned
images into collections that are very handy to use. However, in this
case, XSane is better in my opinion, because it looks so much like
those scanning applets of Windows, being therefore more familiar.

What's next?

The next article will be, hopefully, the last of the series. There we will see how to get online, apply software updates, install some
third party software, and set up a KDM graphical login. Stay
tuned!

Eduardo Sánchez is a Contributing Editor of Open for Business. He is married to Gloria, and lives with his wife in Asunción, Paraguay (South America), where he works as pastoral assistant of Villa Morra Baptist Church. You can reach him at esanchez@ofb.biz .