apollo@ecf.toronto.edu (Vince Pugliese) (11/30/88)
the tar problem reported is not an uncommon one, about not being able to
open the device. what one has to do is to make certain that the tape has be
rewound to its starting position. this can be done using the AEGIS rbak command.
assuming your at one of the unix shells type the following:
/com/rbak -dev ct -rewind
once that is done then you can tar to your hearts content. i strongly recommend
using /dev/rct8 as it rewinds on finishing your archive; /dev/rct12 does not though
this may be what you want. as a sidebar to this if you find yourself have to transfer
files to and from SUNs specify /dev/rst8 at the SUN side. this will write things
out using QIC-24. hope this is of some help.
vincetomc@oakhill.UUCP (Tom Cunningham) (12/03/88)
In article <738@mv07.ecf.toronto.edu>, apollo@ecf.toronto.edu (Vince Pugliese) writes: > the tar problem reported is not an uncommon one, about not being able to > open the device. what one has to do is to make certain that the tape has be > rewound to its starting position. this can be done using the AEGIS rbak command. > assuming your at one of the unix shells type the following: > /com/rbak -dev ct -rewind > > once that is done then you can tar to your hearts content. Well, I tried this from the csh and it seems to work OK, but when I follow this with "tar cvf /dev/rct8 ... " the immediate response is: tar: cannot open /dev/rct8 It doesn't even appear to go out the the device, as there is no sign of life from the drive. Now I am wondering if the device files need to be tweaked in some way. I have checked and both rct8 and rct12 are in the /dev directory. Here is an ls -lg: dspdom!/ [18] ls -lg /dev/rct8 1 crwxrwxrwx 1 root sys 0, 0 Feb 12 1988 /dev/rct8* Any further clues? By the way, thanks to the folks who responded via email, all of whom had the same advice as Vince, above. Given the unanimity of the replies, this behavior really baffles me. -- Tom Cunningham Motorola Inc. Austin TX {sun,uunet!mnetor,cs.utexas.edu}!oakhill!tomc
GBOPOLY1@NUSVM.BITNET (fclim) (12/03/88)
tom cunningham asked how to use tar on cartridge tapes. the
domain/ix 4.2bsd man page (section 4 on mtio) says that /dev/rct[8|12]
has a block length of 512 bytes and the man page (section 1 on tar)
says that (under the b option) the blocking factor on cartridge tape
must be 1.
therefore, you must do:
% /com/rbak -dev ct -rewind
% tar cvbf 1 /dev/rct8 ....
note the b option must be given and the arguments 1 and /dev/rct8 must
be in the same order as the b and f options.
you may specify the default blocking factor of 20 only when you are
using /dev/rmt[8|12]. ie
% tar -cv ....
% tar -cvb 20 ...
are the same. the max arg to the b option on /dev/rmt[8|12] is 20.
note that you need not rewind the mag-tape. but you must *always* issue
% /com/rbak -dev c -rewind
first before you use tar or dd(1) on the cart tape drive.
sometimes, i make tapes in another way:
% pdtar cvzf foo.pdtar.Z ...
% /com/rbak -dev ct -rewind
% /com/rwmt -dev ct -raw -unlab -write -rl 512 -bl 512 -rf f -f 1 foo.pdtar.Z
this way, you may have a few tar files on tape by changing the -f 1 option
to /com/rwmt to -f 2, etc. eg:
% /com/rwmt -dev c -raw -unlab -w -rl 512 -bl 512 -rf f -f 2 bar.pdtar.Z
puts bar.pdtar.Z after foo.pdtar.Z. When reading this tape on, say, a
sun machine, one may use
% tar -xvf /dev/rct0
where /dev/rct0 on a sun does not rewind when tar finished reading
foo.pdtar.Z.
to read bar.pdtar.Z on an apollo, do
% /com/rwmt -dev c -raw -unlab -r -rl 512 -bf 1 -rf f -f 2 bar.pdtar.:z
hope this helps. :-). fclim.
fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu
computer centre
singapore polytechnic
dover road
singapore 0513.frankp@CAEN.ENGIN.UMICH.EDU (Frank Xavier Pampreen) (12/03/88)
The best way to degub tar is to cat out the /dev/rct8 file. This file gives a better idea as to what is wrong. (i.e. not online, no PNA board, not begining of tape, etc.) If you correct the /dev/rct8 response than check to see the /dev/rct8 is correctly configured for your cartridge drive with 'edmtdesc'. Lastly make sure the /dev/rct8 is in the /sys/node_data.####/dev of the node with the cartridge if the node is diskless. Frank Pampreen CAEN University of Michigan frankp@caen.engin.umich.edu