Floppies for the New Millennium
Some of us old-fogy x86 Linux users have been slow to warm to USB. In the 2.2 kernel days, we initially heard of people needing to solve driver problems to benefit their fancy digital cameras and thought “better them than us”. Linux USB support was first pioneered by Inaky Perez Gonzalez, and then rewritten by Linus Torvalds, Greg Kroah-Hartman and others, and was initially rough going.
Then, USB scanners, printers, mice, video cameras, ISDN and xDSL devices, modems, floppy drives, loudspeakers, joysticks, digital tablets, MP3 players, wireless devices, PDAs, sundry mass-storage devices and just about everything else hit the market—USB started looking a whole lot less like the Useless Serial Bus we used to joke about. Fortunately, the kernel's driver support caught up in the interim, but its architecture may be a bit unfamiliar to many. If you're lucky, your distribution will have made the messy details fade to background, but in case it hasn't, read on.
Linux's USB support starts with the kernel needing to recognise your motherboard's USB chipset, which will be a UHCI (Intel) or OHCI-class (Compaq and others) device, requiring the usb-uhci or usb-ohci kernel driver, respectively. (Both also will need the usbcore driver.) If lspci -v returns USB information that includes I/O ports at, then you have a UHCI controller. If the returned USB-controller text includes Memory at, then it's OHCI.
When you're done tweaking module loading (if necessary), the output of lsmod should include all three required drivers. For example, my laptop machine lists:
Module Size Used by Not tainted usb-uhci 20676 0 (unused) usb-storage 97120 1 usbcore 48000 1 [usb-uhci usb-storage]
The usb-storage driver is a translator that lets random-access-type USB devices be addressed using SCSI block-device names—we'll return to that later. Without it, you'd need some other intermediary to access files from the USB layers, such as the gPhoto2 application.
If you're running a 2.3.38 or later kernel (and you should really upgrade to 2.4.x or later, at this point), you also should add the following line to /etc/fstab to enable USB device tracking:
none /proc/bus/usb usbdevfs defaults 0 0
After this, type mount -a. Now, you're all done except for mounting the actual mass-storage device. The above step does not mount the device—usbdevfs is strictly an abstract support filesystem similar to /proc, used by the USB subsystem.
All of the above USB-configuration details should be taken care of automatically by modern Linux installer programs, but it is covered here in case it's not. If you're reasonably lucky, all you need to do is plug the drive in to a USB port or hub and mount it.
I created a mountpoint directory of /mnt/fob from which to hang the flash drive. That name owes to the drive being about the same size as a key fob or an old pocket watch (fob watch), lurking in one's trouser pockets in roughly the same fashion.
That was the easy part. Next was a wild ride trying to chase down how to mount it properly. My browsing of on-line materials suggested that USB flash drives, as with Iomega Zip disks, would be treated as SCSI. A glance at /proc/scsi/scsi after plugging in the Easy Disk clarifies that it's recognised as the first SCSI device and moreover that it's a rebranded DiskOnKey unit OEMed from M-Systems, Inc. Intuition therefore suggested mounting /dev/sda1 (on an otherwise IDE-based system), but intuition turned out to be dead wrong in the Easy Disk's case. Making the attempt resulted in this puzzling error:
guido:~# mount -t vfat /dev/sda1 /mnt/fob mount: block device /dev/sda1 is write-protected, mounting read-only mount: /dev/sda1 is not a valid block device
Some other USB flash drives reportedly do mount precisely in that way, whereas I found out that the Easy Disk mounts as /dev/sda, not /dev/sda1 or any other partition number—that is, it treats the drive as a device lacking the ability to house a partition table. The explanation of this curiosity turns out to lie in the ATAPI Removable Media Device (ARMD) BIOS Specification, laid down by Compaq and Phoenix in 1997 to generalise how a floppy-like drive should behave on the ATA bus in anticipation of traditional floppy drives going the way of the dodo. ARMD devices are basically big floppy disks, which per the spec have no partition table. Thus, the Easy Disk happens to be an ARMD (floppy-like) device. Apparently, many other USB flash disks are, by contrast, treated as regular ATAPI drives.
Like most flash devices, the Easy Disk came preformatted with the MS-DOS FAT filesystem. That raises, of course, the question of whether it might be rewritten to use less antique disk formats instead. I never tested that, partly because FAT, for all its faults, is supported by almost all UNIX workstations, Macs and MS Windows boxes. Partly, I shied away from attempting other filesystems in order to reduce device fatigue.
Now, some further elaboration of the mount command:
# mount -o uid=1000,gid=1000,noatime -t vfat \ /dev/sda /mnt/fob/
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- LiveCode Ltd.'s LiveCode
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide