The Stealth Desktop Part IV: Removable Drives and Scanners
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 drivesFloppy 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.
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 floppiesBefore 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.
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.
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 .