Technical:Storage:USB
From K12LTSP Wiki
see also StorageFloppyUsb
Contents |
K12LTSP release 4.4.1-3
Note: This entry seems to be out of date. While it does work, K12LTSP release 4.4.1-3 seems to have all of this setup and simply uncommenting the RCFILE_01 = floppyd line in /opt/ltsp/i386/etc/lts.conf seems to work (however, you may need to include the usb modules as below). In addition, it includes an updated version of mtools that allow both the floppy and usb stick to be accessible.
USB Storage
In addition to floppy storage, it is also possible to use USB Storage Devices. What follows describes how to enable and use a USB flash drive. Then mtools or MToolsFM, if a graphical interface is desired, can then be used to access the storage device. Many thanks to Alain Knaff (author of mtools) for his assistance with this.
USB Storage: Is the device supported?
The first step is simply to determine if the device is supported by Linux.
If the device can be mounted on the LTSP server, then there is a very good chance that the client will also be able to mount the device. Next, check to see if mtools can access the device when it is attached to the LTSP server. So ... unmount the device (umount /tmp/flash) since mtools doesn't use a mounted device and modify the .mtoolsrc file for the account you are using to test with and add a new entry, for example.
# First SCSI hard disk partition
drive r:
file="/dev/sda1"
fat_bits=0
hidden<code>16 cylinders</code>500 heads<code>8 sectors</code>16
exclusive
mformat_only
You will also need to setup MToolsFM so that driver is a recognized entry. See MToolsFM mods for details of this above entry in mtools.conf
USB Storage: Mods to lts.conf
These changes are required to insure that the drivers for the device are loaded by the LTSP client. For the flash drive I used, this meant including sd_mod module, in addition to the usb drivers in /opt/ltsp/i386/etc/lts.conf. Also, you need to load the RCFILE for the device.
RCFILE_01 = "flash"
RCFILE_02 = "usb"
MODULE_01 = "usb-uhci"
MODULE_02 = "usb-storage"
MODULE''03 = "sd''mod"
See troubleshooting for ideas on how to determine which modules are needed if the above aren't correct.
USB Storage: Mods to rc.d
Now, create a new file in rc.d (called flash in the above example) which creates a device entry for the USB storage device, sets permissions, and loads floppyd to access the device. It is simple to edit the existing floppyd rc file to get the one desired. Also, you will need a device file. Easiest is to just copy the device file that worked on the server from the /dev directory to a new directory under /opt/ltsp/i386. This will change the filesystem for the client, but I do not know of another way to do this yet. I created a new directory called dev-files and copied the device file entry
cp -a /dev/sda1 /opt/ltsp/i386/dev-files/sda1
I needed this because devfsd overwrites the existing entries in /opt/ltsp/i386/dev when the client boots. If the device is always attached, then devfsd can be used to automatically create the device file (see comments in RCFILE "flash").
With this in place, the RCFILE is:
<verbatim>
#====/bin/bash ==== # # First, since floppyd runs as nobody, make /tmp world accessible. # chmod 777 /tmp # # Make sure usb modules are loaded in lts.conf, # also must load sd_mod in lts.conf # Make the usb drive world accessible. # # chmod 666 /dev/sda1 # Above only works if drive is already attached when client boots # and /dev/sda1 is created by devfsd, but what if it isn't attached at boot? # create a /tmp/dev entry for it and use that instead # mkdir /tmp/dev # #copy the previously created device node # cp -a /dev-files/sda1 /tmp/dev/sda1 # # and make it world accessible # chmod 666 /tmp/dev/sda1 # # Finally, start floppyd. # #If already attached #floppyd -d /dev/sda1 # # or if manually created # floppyd -d /tmp/dev/sda1 # # It should be possible to have both floppy and USB flash devices on the same # client, but floppyd currently only works on the clients with port 5703 # so can't load floppyd on alternate port. This should be corrected in a future # patch to mtools, allowing access with the following # floppyd -l -s 5704 -d /tmp/dev/sda1 # provided .mtoolsrc is then setup correctly
</verbatim>
USB Storage: Mods to .mtoolsrc
Finally, mtools needs to know how to access the device. Either mtools.conf in /etc (on the LTSP server), or .mtoolsrc in all users' home directories can be modified. It is probably safest to set each user's .mtoolsrc
<verbatim>
# set drive a: to access the USB flash drive a: file="$DISPLAY" remote
</verbatim>
Drive a: is used since at the client, only this drive is accessible at this time with mtools (14 March 2003). Also, note the use of $DISPLAY and remote. Both are required if the client is to access a locally attached USB flash. By default, this entry seems to be present for K12LTSP. If you do not use both, then mtools will either fail, or attempt to access the device as if it were connected to the LTSP server.
USB Storage: MToolsFM mods
If you want to access the device at a drive letter other than a: then you must configure MToolsFM to recognize this. With MToolsFM running, Select Options--Configure MToolsFM ... and enter all valid drive letters. (Use CNTRL-C as a keyboard shortcut to this option.) These drive letters correspond to the drive letters listed in mtools.conf and/or .mtoolsrc. Then, in .mtoolsrc, provide the information for this drive. You can run mtoolstest to see what mtools will try to access.
USB Storage: Troubleshooting
If you having problems, then troubleshooting is next up. Several key commands assist greatly in this process: fdisk, mount, lsmod, insmod and modprobe. Also, what follows parallels (more or less) the approach used to get my flash device working.
The simplest place to start (again) is to see if you can mount the flash drive on a system running linux locally. As mentioned, the LTSP server is a good candidate for this test. Connect the device to the system. (My device has an LED that indicates status. If the LED is green, then the device was detected. Other devices may have similar visual indicators.) Check /proc/scsi/scsi to see if the device was detected correctly. Next, try to mount the device.
e.g (following assumes the device was detected at /dev/sda1)
<verbatim>
#mkdir /tmp/flash #mount /dev/sda1 /tmp/flash
</verbatim>
NOTE: your device may to be detected at /dev/sda1 or at /dev/sd* depending upon which scsi device it is. Check /proc/scsi/scsi (cat /proc/scsi/scsi). This will tell you where the device was detected:
<verbatim>
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: USB Mass Model: Storage Device Rev:
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: FUJITSU Model: MHR2020AT D Rev: 70BD
Type: Direct-Access ANSI SCSI revision: 02
</verbatim>
On my LTSP server, I have two USB devices:
<verbatim>
scsi0: the USB flash, device node is /dev/sda1 (First primary partition of first SCSI drive) scsi1: a Pocketec 20Gb USB drive, device node is /dev/sdb1 (First primary partition of second SCSI drive)
</verbatim>
You can also check to see if the device is attached. Again, in /proc/scsi, there will be a directory created called usb-storage-x, where x is the device number. e.g.
<verbatim>
# pwd
/proc/scsi/usb-storage-0
# cat usb-storage-0/0
Host scsi0: usb-storage
Vendor: Stormblue Co., Ltd.
Product: USB Mass Storage Device
Serial Number: MASS STORAGE - 9
Protocol: Transparent SCSI
Transport: Bulk
GUID: 04831307fffe9ffffffffe99
Attached: Yes
</verbatim>
If the device was detected, and attached, then it should mount. Once you know the device can be mounted, it is time to get some more information about the device that mtools may need. fdisk provides this information.
<verbatim>
# fdisk -l /dev/sda1
Disk /dev/sda1: 8 heads, 16 sectors, 499 cylinders Units = cylinders of 128 * 512 bytes
</verbatim>
This additional information can be included in the mtools.conf (or .mtoolsrc) file to help mtools identify and access the device (see Is the device supported? above).
So .. if things are working, you can now both mount the device when it is attached to the LTSP server, and access it directly with mtools if it isn't mounted, but is attached to the LTSP server.
It is now time to get it working with the client. First, set the runlevel for the client to runlevel 3. This is so we can check entries in the client's /proc to see if the device is being detected correctly and then the same troubleshooting done for the server applies.
If the client doesn't detect or is unable to mount the device at runlevel 3 then most likely it is an issue with modules not being loaded. If it can be mounted at runlevel 3, but not at runlevel 5, it is probably a problem with the device file specified for floppyd.
You can check the modules needed using lsmod. Reboot the client (without the USB flash attached) and run lsmod at the prompt. This will give you a list of loaded modules. Then, plug in the device, and run lsmod again. Most likely, no new modules were autoloaded, but check anyway. When you plug in the device, you may (should) be notified by hub.c that a new USB device was connected. You may also be notified by usb.c that the device was not claimed by any active driver. This is a sure indication that you need to load some modules. Try loading usb-uhci, usb-storage, and sd_mod. It is almost a given that you will have to load these three modules.
<verbatim>
bash-2.05# modprobe usb-uhci bash-2.05# modprobe usb-storage bash-2.05# modprobe sd_mod
</verbatim>
When usb-storage loads, it loads scsi_mod. Also, depending on your system, some of these may have autoloaded. Now, when you plug in the USB flash, you will get notification that the device was detected and attached. You will also be told where the device node is.
<verbatim>
hub.c: USB new device nonnect on bus2/2, assigned device number 2
scsi0 : SCSI emulation for USB Mass Storage devices
usb-uhci.c: interrupt, status 3, frame# 19
Vendor INFO
Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 64000 512-byte hdwr sectors (33 MB)
sda: Write Protect is off
Partition check:
/dev/scsi/host0/bus0/target0/lun0:<7>usb-storage: queuecommand() called p1
</verbatim>
So the device node is sda1 (partition 1). Use mount to mount the device to a temporary mount point.
<verbatim>
bash-2.05# mkdir /tmp/flash bash-2.05# mount /dev/sda1 /tmp/flash
</verbatim>
You may get some errors like
<verbatim>
SCSI error: hots0 id 0 lun 0 return code = 8000002
Sense class 7, sense error 0, extended sense 0
</verbatim>
Ignore them, and run lsmod again looking for any new modules that were automagically added. See if you can list the contents of the device. (assuming it has files already on it).
<verbatim>
bash-2.05# ls /tmp/flash file1 file2
</verbatim>
Or create a new directory on the device
<verbatim>
bash-2.05# mkdir /tmp/flash/newdir bash-2.05# ls /tmp/flash file1 file2 new
</verbatim>
So, our list of additional modules is: usbuhci, usb-storage, scsimod, sdmod (and some others, but the above are essential). However, since usbstorage loads scsimod, we do not need to specify scsimod in our lts.conf file. I load usb as well since it will be needed by usb keyboards and mice anyway.
If the above hasn't worked, then you still have some more work to do. Read up on insmod, modprobe and a little on how devfsd works. With these and lsmod, you can track down the missing modules. Also, you make need to create the device file, or copy the correct file from the LTSP server (which is what I did).
USB Storage: Editorial Comments
Add any comments concerning above (with contact info if desired)
Above tested with Casetronic mini-itx 2688R, 32Mb Universal Smart Drive, K12LTSP 3.01, dahopkins@comcast.net, 14 Mar 2003
