unix consulting in the uk.
real life unix observations and tips.
unix consulting in the uk.
real life unix observations and tips.
|
|
|
|
HALVARD'S COOKBOOK FOR USING DLTS UNDER ON SUNOS 4.1.x and 5.x.note: this is an old document. it is kept as a reference for checking out stylesheets and for a simple how-to on learning how to configure 3rd party tape drives on Solaris. please refer to sites like dlttape , quantum or storagemountain for newer information.by Halvard Halvorsen, Sundot. DLT stands for Digital Linear Tape; a technology originally developed and marketed by Digital but later sold to Quantum who now sell and further develop the DLT's. They come mainly in two variants - the 2x00 and 4x00 series - either as single devices with 20 GB (2000) and 40 GB (4000) (compressed) capacities or as stackers (2500,2700 and so on). As this is written there is no official support from Sun on these drives; but Sun are soon the resell the 4000 and 4700 under the SparcStorage name. Future versions of Solaris 2.x might however include support. This document explains how to set up and use the DLT 2000 and 4000 half inch tape drives on both SunOS 4.1.x (Solaris 1.x) and SunOS 5.x (Solaris 2.x). This cookbook does not include instructions for use and setup with special purpose backup programs like Networker. INDEX.
1. CONFIGURING SUNOS FOR USE WITH DLT'S.For all files you are likely to edit or otherwise change I recommend for you to take a backup before applying your changes (including /vmunix when making a new kernel under 4.1.x). I use vi for editing all configuration files to avoid problems with expanding tab's and so on. Hint: use cp -p configfile configfile.orig to preserve the date on the original file. Also it is generally a good idea to apply the latest scsi and kernel related patches before starting out with your DLT confiuration to ensure a stable environment. Check vs the latest Solaris patch reports from Sun for the various versions of SunOS to find information on this topic. 1.1 SunOS 4.1.4 (and probably all other 4.1.x's).Edit the file /usr/sys/scsi/targets/st_conf.c - the last lines should look something like this after including information about the DLT. note - 5 spaces between DEC and DLT2000 and one space between Quantum and DLT2000/DLT4000. Your vendor may have changed the string that the drive presents itself as (many companies OEM these drives) - do a probe-scsi/probe-scsi-all from the boot-monitor and carefully note the output to get the correct string and then edit the file according to the probe-scsi output.
/* Exabyte 8505 */
{
"Exabyte EXB-8505 8mm Helical Scan", 16, "EXABYTE EXB-8505",
ST_TYPE_EXB8500, 1024,
(ST_VARIABLE | ST_BSF | ST_BSR | ST_LONG_ERASE),
5000, 5000,
{ 0x14, 0x15, 0x8C, 0x8C },
{ 0, 0, 0, 0 }
},
/* DEC 1/2" Cartridge - DLT 2000 */
{
"DEC DLT2000", 15, "DEC DLT2000", ST_TYPE_REEL, 16384,
(ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR),
400, 400,
{ 0x17, 0x18, 0x80, 0x81 },
{ 0, 0, 0, 0 }
},
/* Quantum 1/2" Cartridge DLT 4000 */
{
"Quantum DLT4000", 15, "Quantum DLT4000", ST_TYPE_REEL, 16384,
(ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR),
400, 400,
{ 0x80, 0x81, 0x82, 0x83 },
{ 0, 0, 0, 0 }
}
};
int st_ndrivetypes = (sizeof (st_drivetypes)/sizeof (st_drivetypes[0]));
#endif /* NST > 0 */
Verify that st_drivetype in /usr/sys/scsi/targets/stdef.h looks similar to this (it normally does):
struct st_drivetype {
char *name; /* Name, for debug */
char length; /* Length of vendor id */
char vid[24]; /* Vendor id and model (product) id */
char type; /* Drive type for driver */
short bsize; /* Block size */
int options; /* Drive options */
int max_rretries; /* Max read retries */
int max_wretries; /* Max write retries */
u_char densities[NDENSITIES]; /* density codes, low->hi */
u_char speeds[NSPEEDS]; /* speed codes, low->hi */
};
After editing the file st_conf.c make a new kernel (config/make as usual; consult your system documentation or the file /sys/`arch -k`/conf/README if you do not know how to make a new kernel) and copy it to /vmunix. I have only tested this under 4.1.4 - but it should also work under earlier 4.1.x's. 1.2 SunOS 5.3.insert these lines before the first "name=" in /kernel/drv/st.conf : tape-config-list = "DEC TZ87", "DEC TZ87 DLT", "dlt2000-data", "DEC DLT2000", "Digital DLT2000 DLT", "dlt2000-data", "DEC DLT2500", "Digital DLT2500 DLT", "dlt2000-data", "DEC DLT2700", "Digital DLT2700 DLT", "dlt2000-data", "Quantum DLT4000", "Quantum DLT4000 DLT", "dlt4000-data", "Quantum DLT4500", "Quantum DLT4500 DLT", "dlt4000-data", "Quantum DLT4700", "Quantum DLT4700 DLT", "dlt4000-data"; dlt2000-data = 1, 0x33, 16384, 0x21d, 4, 0x17, 0x18, 0x80, 0x81, 2; dlt4000-data = 1, 0x33, 16384, 0x21d, 4, 0x80, 0x81, 0x82, 0x83, 2; 1.3 SunOS 5.4 and 5.5.insert these lines before the first "name=" in /kernel/drv/st.conf : tape-config-list = "DEC TZ87", "DEC TZ87 DLT", "dlt2000-data", "DEC DLT2000", "Digital DLT2000 DLT", "dlt2000-data", "DEC DLT2500", "Digital DLT2500 DLT", "dlt2000-data", "DEC DLT2700", "Digital DLT2700 DLT", "dlt2000-data", "Quantum DLT4000", "Quantum DLT4000 DLT", "dlt4000-data", "Quantum DLT4500", "Quantum DLT4500 DLT", "dlt4000-data", "Quantum DLT4700", "Quantum DLT4700 DLT", "dlt4000-data"; dlt2000-data = 1, 0x33, 0, 0x21d, 4, 0x17, 0x18, 0x80, 0x81, 2; dlt4000-data = 1, 0x33, 0, 0x21d, 4, 0x80, 0x81, 0x82, 0x83, 2;Note: there is a bogus commented DLT entry in the Solaris 2.5 configuration file - leave it commented ;-| See chapter 6 for detailed notes on the configuration files. 2. CONNECTING AND VERYFYING THE DLT.Shut down your Sun workstation/server and power off the machine and all scsi-devices. Connect the DLT to the scsi-bus using good cables and make sure the bus is terminated correctly. Set the scsi-id; id 4 or 5 are the most common to use - i have used 5 for my testing. If possible use a separate or underutilized SCSI bus for the DLT. Running the tape drive (especially a DLT2000) on the same bus as the disk drives will never let you achieve any good throughput according to Rohbeck of Quantum/Germany. You bought the DLT because of performance didn't you ? Power on the devices/machine again and halt the boot process with STOP-A (L1-A) (or the BREAK key if you have an ASCII console). Use the probe-scsi command from the boot-monitor (or probe-scsi-all) to verify that the drive is connected properly. Note: output from probe-scsi will not always be correct if you enter the PROM monitor by breaking the boot process! According to Sun this will be the case especially on the new Ultra machines. See chapter 12 for more on this. Boot the machine - for SunOS 5.x use boot -rv, for SunOS 4.1.4 use boot. When booting you should see a message similar to these: "st4: " "st5: " for SunOS 5.x and "st1: " "st1: " for 4.1.4. On SunOS 5.x an mt -f /dev/rmt/0 status should give a first line looking like this for the 2000/4000: "REEL tape drive:" If the drive does not identify itself as shown for 5.x you have probably missed a space or something in your st.conf file (4.1.x will give you "SCSI tape drive:"). 3. DEVICES TO USE.3.1 SunOS 4.1.4/DLT 2000.- assuming you have set the scsi-id to 5:
3.2 SunOS 4.1.4/DLT 4000.
3.3 SunOS 5.x/DLT 2000.- assuming that the DLT is the first tape device on the scsi-bus (lowest id).
3.4 SunOS 5.x/DLT 4000.
4. PARAMETERS FOR DUMP/UFSDUMP.4.1 SunOS 4.1.4/DLT 2000.
4.2 SunOS 4.1.4/DLT 4000.
My size recommendation for 4.1.4 are based on information ("nn% done") from dump using a 1 GB filesystem. 4.3 SunOS 5.x/DLT 2000.
I was able to back up around 9.5 GB using the uncompressed device and over 21 GB using compressed mode using the above commands on file systems containing a mix of text and binary files; compression rates will depend on the data you are trying to compress. 4.4 SunOS 5.x/DLT 4000.
4.5 BPI,blocking factor,speeds and MTBF.Read the man pages for dump/ufsdump - the above is just to show examples on a level 0 dump with my parameters and my devices.
126 is the maximum blocking factor for dump/ufsdump. Speeds observed when writing with dump/ufsdump :
MTBF is 80 000 hours and estimated head life is 10 000 hours for both drives. According to DEC's 4000 manual the media can endure 500 000 passes and it has a shelf life of 10 years. 5. DENSITY INDICATORS (or: density select-don't use it if you dont mean it!).The 2000 drive has 5 indicators on the left and 4 on the right hand side. The 4000 drive has 6 indicators on the left and 4 on the right hand side. The ones on the left are used to indicate the density. There is also a density select button placed below the density indicators. The density select button always override whatever you select in software (ie which device you write to). My recommendation is that you leave the select button alone. The drive automatically read pre-recorded tapes in whatever format you wrote it in. Also you do avoid pushing the buttons and there is no need to watch/decode the density override lamp and blinking density lamps. I find using the drive easier when selecting the density i want from SunOS. On another note - the density indicator lamps on my tested 2000 was somewhat slow to respond. The 4000's I've seen did not have this problem. If you go from 6 GB mode to 10 GB mode on the 2000 it generally takes some time before the 6 GB lamp lit off and for the 10 GB lamp to lit. The same applies to the compress lamp. This can be a little confusing if you only put a few megabytes on the tape - so be patient ;^) Also when doing dump/ufsdump on large filesystems it takes a while for the command to build it's mapping and thus the lamps will not change before a new tape header is actually written. You can not put different densities on the same DLT tape - the drive use the density which was selected at BOT. Rohbeck writes: The density indicator lamps light up according to the new format as soon as the tape has been initialized to the new format. This includes rewriting the tape header which takes a few seconds. You cannot change the density in the middle of a tape, but you can turn compression on and off on the fly. 6. DETAILED INFORMATION ON MY CONFIGURATION FILES.You can skip this chapter if you want to - it is only here to justify my selections and to tie some loose ends. As you are likely to find lots of other entries on the DLT on the net and from your vendor I have included this rather long and detailed chapter to explain why my recommended configuration files look the way they do. There are several ways of configuring this device and not one is "the correct one" - however the information provided below will enable you to understand why my recommendation looks the way it does and hopefully if you read the rest of this document it will enable you to change the DLT's behaviour to your taste if you so want. 6.1 Density codes for the DLT 2000.First the density codes - I use these for the 2000
0x19 gives the same result as the 0x81 code - but I prefer to not use it; it is likely to give some confusion when reading the configuration file (two codes for the same density). Also on page 7-48 in the DEC manual for the 2000 0x19 is listed as "10 GB" - see the table below. This just adds to the confusion so I prefer to just throw away the 0x19 code and I recommend for you to do the same thing. The DEC manual for the 2000 lists the following codes:
Quantum has newer manuals and also Application Notes that lists the correct density codes. The Application Notes are available on the web - but the current ones point in different directions. For example the entries recommended for 5.3 is totally different to 5.4 with regards to the order of the density codes,they use the BSD compability devices in Solaris 2.x instead of Solaris ones and they also fail to mention the block size error for 5.3. However the recent updated Application Notes are much better than the previous versions ;-) Rohbeck of Quantum will receive detailed information on these matters. 6.2 Density codes for the DLT 4000.The DEC manual for the 4000 lists all of the 2000 density codes plus these in the chapter on mode select:
6.3 Configuration file for 4.1.4.Part of st_conf.c (just showing the 2000) :
/* DEC 1/2" Cartridge */
{
"DEC DLT2000", 15, "DEC DLT2000", ST_TYPE_REEL, 16384,
(ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR),
400, 400,
{ 0x17, 0x18, 0x80, 0x81},
{ 0, 0, 0, 0 }
}
The explanation of these fields is found in
/usr/kvm/sys/scsi/targets/stdef.h :
struct st_drivetype {
char *name; /* Name, for debug */
char length; /* Length of vendor id */
char vid[24]; /* Vendor id and model (product) id */
char type; /* Drive type for driver */
short bsize; /* Block size */
int options; /* Drive options */
int max_rretries; /* Max read retries */
int max_wretries; /* Max write retries */
u_char densities[NDENSITIES]; /* density codes, low->hi */
u_char speeds[NSPEEDS]; /* speed codes, low->hi */
};
The density codes _should_ go from low to high and if you consult
chapter 3.1 and 6.1 they do. My st_conf.c differ from DEC's (and
others you are likely to find) with regard to the 0x19 code. You are likely to be provided with configuration files from other sources that do not list the density codes in the "low->hi" order. I (now) prefer to do it according to the SunOS 4.1.x man page; even if it means that you have to use devices such as /dev/nrst25. And once again- be aware of the 5 spaces in the "DEC DLT2000" string. 6.4 Configuration file for 5.3.Small part of st.conf (example with just the 2000 included): # # Copyright (c) 1992, by Sun Microsystems, Inc. # #ident "@(#)st.conf 1.6 93/05/03 SMI" tape-config-list = "DEC DLT2000", "Digital DLT2000 DLT", "dlt2000-data"; dlt2000-data = 1, 0x33, 16384, 0x21d, 4, 0x17, 0x18, 0x80, 0x81, 2; name="st" class="scsi" ...Excerpt from the st man page :
...
The formal syntax is:
tape-config-list = triplet [, triplet * ];
where
triplet := vid+pid, pretty print, data-property-name
and
data-property-name = version, type, bsize,
options, number of densities,
density [, density* ],default-density;
bsize
is the preferred block size of the tape device. The
value should be 0 for variable block size drives.
number of densities
is the number of densities specified.
Each tape drive can support up to four densities. The value
entered should therefore be between 1 and 4; if less than 4,
the remaining densities will be assigned a value of 0x0.
density
is a single byte hexadecimal number. It can
either be found in the drive specification manual or be
obtained from the drive vendor.
default-density
has a value between 0 and (number of densities - 1).
...
The extra DLT added in the "Digital DLT2000 DLT" string is added
for readability and it is also a nice to way to ensure that your
entry is correct (look at the output from boot -rv). 6.4.1 Problem with zero block size under SunOS 5.3.So why is the block size set to 16384 when the man page say : "value should be 0 for variable block size drives" ? Well - it's a bug in 5.3 - if you use 0 you will get divide by zero errors (!); so the the bsize must be set to something else. However if you keep the non-zero value and upgrade to 2.4 you will get problems - more on that later. (Also refer to SunSolve bugid 1200807 for a long description of this). 6.4.2 Halvard's setup for 5.3/2000.Densities go from low to high and the last "2" in the dlt-data line sets the default (/dev/rmt/0) device to use the 10GB uncompressed device (points to 0x80). I think this makes good sense. 6.4.3 DEC's setup for 5.3/2000.Now lets look at a typical recommendation for 5.3 (DEC's old) which you are likely to find on the net. I think DEC's one is totally out of place ... ;-) (DEC probably just moved their 4.1.x recommendation to 5.x without checking the format ...) : tape-config-list = "DEC DLT2000", "(nickname)", "magic-data"; magic-data = 1, 0x33, 16384, 0x21d, 4, 0x80, 0x81, 0x19, 0x18, 3; 6.4.4 Halvard's vs DEC's 2000 setup - or why you should avoid DEC's setup.and thus we can set up the following table:
I know that the "native default" mode of the drive is 20 GB compressed; but I prefer to only use compression when I ask for it. Your mileage may vary, and if you want to change the "default device" from 10 GB uncompressed to 20 GB compressed you should be able to do so by reading this paper ;^) 6.5 Configuration file for 5.4/5.5.First part of 5.4 st.conf (with just the 2000 as an example): # # Copyright (c) 1992, by Sun Microsystems, Inc. # #ident "@(#)st.conf 1.7 93/12/20 SMI" # # Following entry below supports Metrum Tape Drives at any target. # Remove the '#' character to really configure a Metrum Tape Drive. # You can construct similar entries for other tape drives. # Refer to st(7) man page for details. # #tape-config-list= # "Metrum", "Metrum VHS Cartridge", "metrum-data"; #metrum-data =1,0x36,1024,0x1639,1,0,0; tape-config-list = "DEC DLT2000", "Digital DLT2000 DLT", "dlt2000-data"; dlt2000-data = 1, 0x33, 0, 0x21d, 4, 0x17, 0x18, 0x80, 0x81, 2; name="st" class="scsi" ...As you will note there is only one change here - the block size is set to zero as it should be according to the man page (see 6.3). This is the only change (but a vital one - see below). Devices to use and so on is similar to 5.3. 6.5.1 Problem with non-zero block size under SunOS 5.4/5.5.If you specify something else than zero for the block size under 5.4 this gives some weird results. The drive behaves like a fixed record size device - ie it only accepts output in the specified block size. This behaviour is of course highly unwanted ;^). If you used the drive (or any other third party drive defined in st.conf) under 5.3 and kept your st.conf file when upgrading your drives will suddenly appear unusable. The fix is to put in the zero as shown for DLT. If not changing the block size to zero you will see error messages like these (example with tar) :
tab% tar cvf /dev/rmt/0h .
a ./ 0 tape blocks
a ./helse2.sh 12 tape blocks
a ./Helsesjekk.doc 28 tape blocks
tar: write error: Invalid argument
tab%
WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@4,8400000/esp@4,8800000/st@5,0 (st5):
write: not modulo 16384 block size.
( The block size problem (for both 5.3 and 5.4) is discussed to length under Sun's bugid 1200807 (SunSolve). If you read the notes on this bugid - beware that Legato use their own internal format for backup (Networker/32Kb) and thus you should only use Legato's st.conf if you have Networker! ) This is a Solaris software bug - the drive itself will accept any block size from 1 byte to 16 MB. 6.6 To REEL or not to REEL.If you get access to Quantum's papers and also in some other configuration files you will notice that some of them do not use the REEL as a type. Common other "device types" to use are "other SCSI drive" (0x36) for 5.x and "Generic 1/2" Cartridge" (0x26/ST_TYPE_HIC) for 4.1.x. As all of these are _generic_ drivers as is the REEL one i still prefer to use REEL as originally recommended by DEC and I've noticed no unwanted behaviour using REEL as the type. At least on Solaris 2.x (SunOS 5.x) i strongly prefer the drive present itself as "REEL" instead of the rather vague "other SCSI drive". 7. THOSE DRIVE OPTIONS - WHAT DO THEY MEAN?from the 5.3 st man page:
is a bit pattern representing the drive options,
as defined in /usr/include/sys/scsi/targets/stdef.h. Valid
flags for tape configuration are:
ST_VARIABLE 0x0001
ST_REEL 0x0004
ST_BSF 0x0008
ST_BSR 0x0010
ST_LONG_ERASE 0x0020
ST_KNOWS_EOD 0x0200
ST_IQIC 0x0002
ST_UNLOADABLE 0x0400
ST_LONG_TIMEOUTS 0x1000
part of the /usr/include/sys/mtio.h file in 5.3:
#define MT_ISQIC 0x32 /* generic QIC tape drive */ #define MT_ISREEL 0x33 /* generic reel tape drive */ #define MT_ISDAT 0x34 /* generic DAT tape drive */ #define MT_IS8MM 0x35 /* generic 8mm tape drive */ #define MT_ISOTHER 0x36 /* generic other type of tape drive */from the 4.1.4 /usr/sys/scsi/targets/stdef.h file:
/* Defines for supported drive options */
#define ST_VARIABLE 0x001 /* supports variable length I/O */
#define ST_REEL 0x004 /* 1/2-inch reel tape drive */
#define ST_BSF 0x008 /* Supports backspace file */
#define ST_BSR 0x010 /* Supports backspace record */
#define ST_LONG_ERASE 0x020 /* Long Erase option */
#define ST_AUTODEN_OVERRIDE 0x040 /* Auto-Density override flag */
#define ST_NOBUF 0x080 /* Don't use buffered mode */
#define ST_NOPARITY 0x100 /*
* This device cannot generate parity,
* so don't check parity while talking
* to it.
*/
#define ST_KNOWS_EOD 0x200 /* knows when EOD has been reached */
#define ST_QIC 0x202 /* QIC tape drive knows EOD */
/*
* old defines for the options flag - not supported anymore
* here for historical reference only.
*/
/* was ST_NO_FSR- Sysgen only 0x020 /* No forwardspace record */
/* was ST_NODISCON- Sysgen only 0x080 /* No disconnect/reconnect support */
/* was ST_NO_QIC24- Sysgen 0x100 /* No QIC-24 (for Sysgen) */
/* was ST_NO_POSITION- ignore 0x400 /* Inhibit seeks flag */
and some more from the 4.1.4 /usr/sys/scsi/targets/stdef.h file
#define ST_TYPE_CDC 0x20 /* CDC - (not tested) */ #define ST_TYPE_FUJI 0x21 /* Fujitsu - (not tested) */ #define ST_TYPE_KENNEDY 0x22 /* Kennedy */ #define ST_TYPE_HP 0x23 /* HP */ #define ST_TYPE_HIC 0x26 /* Generic 1/2" Cartridge */ #define ST_TYPE_REEL 0x27 /* Generic 1/2" Reel Tape */ #define ST_TYPE_EXABYTE 0x28 /* Exabyte */ #define ST_TYPE_EXB8500 0x29 /* Exabyte */ #define ST_TYPE_PYTHON 0x2c /* Archive Python DAT */ 8. OTHER DLT'S - STACKERS (2500,2700,4500,4700) AND XT'S (2000xt,2500xt,2700xt).I have no experience with these drives whatsoever - but for these drives my configuration files should still be usable. The 2500/2700 and 4500/4700 are 2000's and 4000's with a 5 or 7 cartridge auto-loader. The 2000xt drives are a newer version of the 2000 with expanded capacity (15 GB uncompressed/30 GB compressed). If my entries do not work out of the box just do a probe-scsi as mentioned earlier to see what the drive presents itself as and rewrite the configuration file. Remember that spaces are indeed very significant!. At least the DLT 2700 have been tested by others using my configuration files and also all of Quantum's pages use the same entry for eg a DLT 2000 and a DLT 2700. The x700 loaders have LED's similar to the 2000/4000 and the x500 loaders use an LCD display. 9. CompacTape III,CompacTape IIIxt and CompacTape IV.
The 4000 will automatically recognize the tape so if you try to write in 40 GB/compressed mode on a III tape you will get compression but not in 40 GB mode. The drive will write in 20 GB/compressed mode. The same thing happens when using a IV tape and trying to write on it in one of the "older" modes (80 and 81 codes); the drive writes the tape in "IV mode" - ie 20 GB uncompressed or 40 GB compressed. So please use the correct devices and the correct tapes to avoid confusion. The DLT 4000 can write 2.6, 6.0 and 10 GB formats (rewrite your configuration file for doing this ;-) - but you do have to use the correct cartridges). 10. NOTE ON MICROCODE/FIRMWARE UPDATES.If you do not get the drive to work at all or you experience other unexplainable problems you might have a firmware problem. The DLT's have a Flash EEPROM which will allow you to load new microcode to the drive from tape. Contact your vendor if you need a microcode update.Your microcode revision might show (or might not - depending on what your vendor/reseller have chosen to implement) when using the probe-scsi command. If you have a newer drive (ie a Quantum made one) it _should_ show - Rohbeck for the last time ;-) : The version will always show. The vendor/product ID can be changed, but the version will always show up, at least the first 4 bytes, which identify formatter (first 2 bytes) and SCSI controller revision (3rd and 4th byte). The formatter version is a hex number, the controller version is the firmware rev. in hex, e.g. 1E for V30. The Quantum papers mentions the following restrictions for use with Sun's:
11. WRITING YOUR OWN ENTRIES FOR THIRD PARTY TAPE DRIVES.Reading this paper should enable you to configure other third party drives as well. In principle you will have to have following at hand:
12. CORRECT USE OF THE "probe-scsi" COMMAND.From Sun: We have documented this carefully in the OpenBoot 3.x Command Reference manual (802-3242-10). It states: "If you boot the OS, exit from the OS into OBP without resetting the system, then use some OBP commands, the commands might not work as expected. In this case, you may have to power cycle the system to restore normal operation." The specific example given in the manual which WILL FAIL is probe-scsi. We say "reset the system first (reset-all), then invoke the (probe-scsi) command." so set setenv auto-boot? false, then do a reset-all or reset and then a probe-scsi (probe-scsi-all) would be the correct way to do it an Ultra and possibly other machines. Remember to do a setenv auto-boot? true when done.13. PLANNED EXTENSIONS OF THIS DOCUMENT.
14. DLT COOKBOOK AVAILABILITY ON THE NET.
APPENDIX A - SOURCES.sources of information:
APPENDIX B - THANKS.to the following persons for very valuable input :
APPENDIX C - LEGAL NOTICE.Copyright (c) 1995,1996 Skrivervik Data AS.
|
|
