++++++++++++++++++++ IMPORTANT NOTICE ++++++++++++++++++++ Due to a bug in the latest modules package, I've included patches in the insmod subdirectory of this distribution. This refers to version 1.1.87, a new fixed version may appear soon. Up to then this fix _must_ be implemented to prevent segment violations. Read the README file in that directory and follow the instructions before loading the ftape.o module! ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ---------- Install-guide -- An installation guide ---------- Written by Bas Laarhoven (sjl) & Kai Harrekilde-Petersen. Last update: 30/12/94 by sjl, for ftape v2.00 WHAT YOU NEED: ============== 1) the floppy tape driver distribution file `ftape-1.20.tar.gz' (this file is a part of it). 2) the kernel sources for Linux 0.99pl14t or later. If you know what you're doing you can use the driver with older kernel versions, but you have to hack the ftape and modules support in the kernel yourself! 3) modules utilities: `modutils-0.99.14.tar.gz' (or later). [Note that the old ones still work even if you get a warning saying you're using an old insmod and no symbols will be inserted !] 4) tools like `mt' and `tar' to use the driver (these can be found in the gnu cpio package). (Of course, you also need a tape drive installed and the appropriate tools to compile the sources) INSTALLATION STEPS: =================== If it's the first time you install ftape, you'll want to start with these steps, otherwise proceed with step D. A) Compilation of the `modules' utilities. B) Creation of the ftape devices. C) Installation of syslog[dk] (not necessary, but rather useful). Installation of the ftape driver consists of two main steps: D) Reconfiguring the kernel for ftape support. E) Compilation of the ftape driver proper. F) Loading and testing the driver. IMPORTANT: The version number of the running kernel must match the version of the sources in /usr/src/linux when ftape is built ! [You may get all kind of weird errors if they aren't the same.] Step A) - Compilation of the `modules' utilities: ------------------------------------------------- [You can skip this step if you have a recent set of modutils ready] The modules utilities are in a separate package (see above) that contains the following three programs: lsmod, insmod and rmmod. After unpacking the sources in `/usr/src/modules' build these utilities: cd /usr/src/modules ; make Test the utils by saying (as root) 'insmod drv_hello.o' This results in a message like this (if you're running X, you wont see these messages): module `drv_hello' (1 pages @ 0x01023000) created initializing module `drv_hello', 140 (0x8c) bytes init entry @ 0x01023034, cleanup entry @ 0x01023074 drv_hello.c: init_module called hello, world Then do a 'lsmod'. This will result in something like: Module: #pages: drv_hello 1 This means that everything worked out OK. Now that drv_hello has served it's purpose, remove it again: rmmod drv_hello There seems to be a problem with recent tools. If you get the message `___moddi3 undefined' when loading the module with insmod I suggest you skip this excercise. It has relation with ftape. Install the *mod utilities somewhere handy, eg: in /sbin. [NOTE: it may NOT be a good idea to install them on a NON-root partition, as they may be needed in an emergency situation (restore after a system crash)] cp *mod /sbin Step B) - Creation of the ftape devices: ---------------------------------------- (You can skip this step if you already have these devices) Check that you have the correct ftape devices: ls -lF /dev/*rft* crw-rw-rw- 1 root 27, 4 Feb 20 13:01 /dev/nrft0 crw-rw-rw- 1 root 27, 5 Feb 20 13:01 /dev/nrft1 crw-rw-rw- 1 root 27, 6 Feb 20 13:01 /dev/nrft2 crw-rw-rw- 1 root 27, 7 Feb 20 13:01 /dev/nrft3 crw-rw-rw- 1 root 27, 0 Feb 20 13:01 /dev/rft0 crw-rw-rw- 1 root 27, 1 Feb 20 13:01 /dev/rft1 crw-rw-rw- 1 root 27, 2 Feb 20 13:01 /dev/rft2 crw-rw-rw- 1 root 27, 3 Feb 20 13:01 /dev/rft3 If not, make them thus: mknod -m 666 /dev/rft0 c 27 0 mknod -m 666 /dev/rft1 c 27 1 mknod -m 666 /dev/rft2 c 27 2 mknod -m 666 /dev/rft3 c 27 3 mknod -m 666 /dev/nrft0 c 27 4 mknod -m 666 /dev/nrft1 c 27 5 mknod -m 666 /dev/nrft2 c 27 6 mknod -m 666 /dev/nrft3 c 27 7 These are the raw floppy tape devices and non-rewinding raw floppy tape devices for drive selection methods A:,B:,C: and D: People used to the old naming convention may want to set up some symbolic links once the drive select is known: lrwxrwxrwx 1 root 9 Feb 20 13:03 /dev/ftape -> /dev/rft0 lrwxrwxrwx 1 root 10 Feb 20 13:03 /dev/nftape -> /dev/nrft0 Step C) - Installation of syslog[dk]: ------------------------------------- (This step is optional. Check first to see if syslogd and syslogk are already running). You'll want to capture the messages that ftape issues with syslogk or syslogd (NET-2 version). If you don't have a syslog daemon running add the following to your rc.local file: if [ -x /etc/syslogk ] ; then syslogk on 2>&1 >>/var/log/kernel & fi This will append the kernel messages to the file `/var/log/kernel'. (Make sure this file exists - do `touch /var/log/kernel' as root) Step D) - Reconfiguring the kernel for ftape support: ----------------------------------------------------- If you don't have the proper kernel sources installed, do so now. The ftape driver needs access to some kernel source-files and searches the /usr/src/linux path. If you're sources are installed somewhere else you'll have to patch the driver or set up a symbolic link. Since the both the `modules' and `ftape' support are included with the standard kernel since 0.99pl14t, there is no longer a need for patching the kernel. cd /usr/src/linux ; make config Be sure to answer yes to 'QIC-117 tape support', and 3 for the NR_FTAPE_BUFFERS (unless you know what you're doing!). It is *not* necessary to include QIC-02 support for proper functioning (contrary to what has been said on the net). make dep ; make clean ; make Take a nap, read the newspaper or drink some tea / coffee while the kernel is being recompiled (this takes about 20 min on a 486DLC/33 box). Install the new kernel (keep the old one around, in case you can't boot with the new one) and reboot. Assuming no errors occurred during the compile, we're now ready to compile the modules utilities. Step E) - Compilation of the ftape driver proper: ------------------------------------------------- [The ftape module (as all modules) will only run with the kernel version it is compiled for. For ftape this is the kernel version running when compiling the driver ! This version *must* also match the sources in the directory /usr/src/linux.] Unpack the driver sources and enter the directory where they reside. Look in the Makefile for options with their descriptions. If you're using gcc 2.4.5 you'll *NEED* to set GCC_2_4_5_BUG, else the driver will fail ! Once all the options are set create the driver by: make clean ; make If you're using a kernel version 1.1.22 or earlier note that accessing the floppy drive at the same time as the tape drive will cause kernel panic. Later versions will prevent this problem: One cannot access the floppy drive while running ftape and vice versa. There is a patch for the gnu version of mt (cpio-2.3) distributed with the driver. It makes the `mt status' command display usefull information. You might want to install this but it is not mandatory. Step F) - Loading and testing the driver: ----------------------------------------- As said before, the `ftape.o' module will only run with the kernel version it's compiled on, if you get an error message saying that the kernel_version doesn't match the current kernel, remove the file kernel-version.h (or do a `make clean') and run `make' again. There should be *NO* warnings. *ALL* compiler warnings / errors should be investigated and reported. You'll need to be root to load the driver with insmod (specify the full path to insmod if it is not in the standard search path): su insmod ftape.o This results in a similar message as when you installed the drv_hello.o module. You'd probably like to catch the messages that ftape generates with a syslog daemon. Some other configurations may display them on the active console. See `Step D)' above for more. If everything went well you got a couple of lines including a copyright notice and some timing information. If you get any messages of the type `multiple definition of symbol ...' or `undefined symbol ...' something is wrong with either kernel sources or modules utilities. *** The kernel 1.1.0 is broken: get a later version ! *** You have to reload the driver *every* time you boot the system (Just as with the modules utilities, it's a good idea to have ftape.o on the root partition. The filesystem standard suggests somewhere under /boot). Instead of doing it by hand, you could include the following line in your /etc/rc.local: /sbin/insmod /boot/xxx/ftape.o Now put a tape in the drive and wait for the drive to stop making noise (Most tape drives start calibrating the head when a new tape is loaded.) Now try if the drive is recognized: mt -f /dev/rft0 rewind This will try to open the device. No tape motion will follow if the tape is already rewound. Because initially `tracing' is set to some value greater than zero, some debugging output (printk) is generated on the console. The messages generated when opening the device can start with some "timeout on Acknowledge" lines. This depends on the trace-level, and is normal as long as the driver is probing for a tape drive. If they keep appearing after the device is opened something is wrong. If all goes well, messages will appear saying something about "drive-wakeup method: xxxx" and "tape drive type: yyyy". If not, "no tape drive found !" says that the driver cannot activate the drive. In this case you can try the other devices (rft1-rft3). In case they all fail the driver will not work with your drive. If some message appears with "unknown vendor id", follow the instructions in the message so I can include this information with a new release. In the meantime the driver will function correctly if it is compatible with one of the known types. Now it's time to setup the symbolic link to the appropriate device or otherwise don't forget to substitute the correct device for the /dev/ftape used below. The next test verifies if the drive does respond to some simple commands: mt -f /dev/ftape reten The tape should wind completely to the end once and back to the beginning again. Depending on the tape used this may take a couple of minutes. If there are no error messages in the log everything is going fine. Now we are going to try to read some data from the tape. [Make sure a formatted tape is in the drive !] mt -f /dev/ftape fsf 0 This causes the driver to read the header segment and display some information on the tape in the drive (look in the kernel logfile). `mt' may fail with an I/O error if the tape contains no file marks or if the operation failed otherwise. Look in the log messages for errors. This may indicate that you're using the wrong dma channel with an FC-10 controller or other special configuration. Now it's time to try the write operation. Put a formatted tape in the drive (write protect removed) and initialize the tape for usage with the ftape driver: mt -f /dev/ftape erase This command writes a Linux tape label so you can recognize the tape when using other operating systems, and it clears all file marks on the tape (No real erasure takes place, all data is still accessible). This command must be issued before file marks can be written to tape ! At this point you're ready to use the driver to try a simple backup of the kernel sources. We'll be using gnu tar to write and verify the data: tar clvf /dev/ftape /usr/src/linux/* You'll see the file names coming by as the data is written to tape. If the operation succeeds without errors a verification can be done: ( cd / ; tar dvf /dev/ftape ) The data on tape will be compared with the files on disk and any mismatches will be reported. At this point the driver seems to be cooperating with the tape drive and you'll have to determine the method you'll use to make the backups. Unix (and therefor Linux) has a lot of tools to do this and it is a matter of taste which you want to use. Some of the options are: cpio, tar, dd and dump/restore. One final warning: If you are using compression when writing data to tape (e.g. tar with the `z' option) you may not be able to recover anything if the tape gets damaged ! A short introduction to file marks: =================================== File marks are written to tape to separate individual files (Note that one `tar' file may contain many data files!). So several files can be written to tape and individually retrieved. The way ftape implements these file marks allows almost random access to individual files (instead of sequentially reading the entire tape until ones finds the right file mark). Every time the device is closed after writing some data two file marks are written to tape. If the non-rewinding device is used the tape is rewound so it is positioned right between these two marks. If another file is written to tape the second marks is overwritten but the first stays causing succeeding files to be separated by exactly one file mark. The following should make this clear: After writing one file to the non-rewinding tape device the tape layout will be: When another file is written the layout will be: If we want to add another file to this tape after it has been rewound, there are to options: First to skip 2 file marks to position right between the last two marks. In this case we have to know how many files to skip. The other solution is to seek for the double file mark and position in between. This is done with `mt eom'. Remember to use the non-rewinding device when positioning the tape or it will be rewound when closing ! Appending a file to a tape: mt -f /dev/nftape eom tar cvf /dev/ftape Reading the first and third files from tape: mt -f /dev/ftape rewind tar xvf /dev/nftape mt -f /dev/nftape fsf 2 tar xvf /dev/nftape The best way to understand what is happening is to picture the tape layout and count the file marks that have to be skipped. BTW: Keep in mind that file marks aren't written to tape until the header segment is updated. For non-rewinding devices this will not happen automatically: Make sure that either the last write is to a rewinding device or issue an `mt rewind' or `mt rewoffl' to flush the buffers. The last command will put the drive offline until you reload the cartridge (or the driver). While the drive is offline all commands will fail. How to handle Panics or Oops with ftape-2.0 and up: =================================================== Look in kernel log for 'init_module @ 0xXXXXXXXX' where XXXXXXXX stands for the address where init_module is loaded. Now the module offset can be calculated: nm ftape.o | grep init_module results in something like: 00000110 T _init_module Subtract this value (00000110 or what it really reads) from the load address XXXXXXXX and you get the load offset. When an oops or panic shows look for the value of the program counter: EIP: 0010:YYYYYYYY You have to subtract the load offset from the EIP value If you don't know how to subtract hexadecimal :-) make sure to mention all the above referenced values. -------------------- end of the Install-guide ----------------------