ok, it's got a tape, but it's not rewound. Can you try this with a scratch
tape in the drive? (This will erase everything on the tape.) 

mt -f /dev/nst0 rewind
mt -f /dev/nst0 status
dd if=/dev/zero of=/dev/nst0 bs=32k count=1
mt -f /dev/nst0 status
mt -f /dev/nst0 rewind
dd if=/dev/nst0 of=/tmp/zeroes
mt -f /dev/nst0 rewoffl
mt -f /dev/nst0 status

/tmp/zeroes should be 32K long, and all 0x0s.


> -----Original Message-----
> From: Jeff Q Silverman [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 15, 2002 1:36 PM
> To: Bort, Paul
> Cc: 'Jeff Q Silverman'; [EMAIL PROTECTED]
> Subject: RE: My tape drive dissappeared after updating the operating
> syste m - now what?
> 
> 
> jeffs@truk /atm/cowiche/home/jeffs 1000 $ >>sudo mt -f 
> /dev/nst0 status
> Password:
> SCSI 2 tape drive:
> File number=-1, block number=-1, partition=0.
> Tape block size 13344 bytes. Density code 0x61 (unknown to this mt).
> Soft error count since last status=0
> General status bits on (1010000):
>  ONLINE IM_REP_EN
> jeffs@truk /atm/cowiche/home/jeffs 1001 $ >>
> 
> I symlinked /dev/tape to /dev/nst0.
> 
> 
> 
> Jeff Silverman, sysadmin for the Research Computing Systems (RCS)
> University of Washington, School of Engineering, Electrical 
> Engineering Dept.
> Box 352500, Seattle, WA, 98125-2500
> [EMAIL PROTECTED]
> http://rcs.ee.washington.edu/BRL/people/jeffs/
> 
> 
> On Mon, 15 Jul 2002, Bort, Paul wrote:
> 
> > Jeff, 
> > 
> > You didn't include the results of `mt -f /dev/nst0 status`, 
> which might give
> > some information about the state of the drive. Also, I hope 
> you're using
> > /dev/nst0 instead of /dev/st0 in your amanda configuration, 
> or your backups
> > may be no good. 
> > 
> > You can continue to do backups to your holding disk, which 
> you can then
> > flush to tape later.
> > 
> > > -----Original Message-----
> > > From: Jeff Q Silverman [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, July 15, 2002 12:06 AM
> > > To: [EMAIL PROTECTED]
> > > Cc: [EMAIL PROTECTED]
> > > Subject: My tape drive dissappeared after updating the 
> > > operating system
> > > - now what?
> > > 
> > > 
> > > I have been using amanda without a problem for over two 
> years.  This
> > > weekend, I updated the operating system on my amandaa server 
> > > and the tape
> > > drive broke.  I assume that the problem is a software 
> problem with the
> > > operating system.
> > > 
> > > With a tape in the drive, the command
> > > 
> > > cat /dev/st0
> > > 
> > > causes the process to hang in a sleep (wait for I/O) state.  
> > > I assume that
> > > the cat command ought to output the contents of the tape to 
> > > the next file
> > > mark, right?
> > > 
> > > dmesg has the following information (edited for relevence, I hope)
> > > 
> > > Linux version 2.4.9-12smp 
> ([EMAIL PROTECTED]) (gcc
> > > version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #1 SMP 
> Tue Oct 30
> > > 18:16:48 EST 2001
> > > 
> > > 
> > > (scsi0) <Adaptec AIC-7892 Ultra 160/m SCSI host adapter> 
> found at PCI
> > > 0/9/0
> > > (scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
> > > (scsi0) Downloading sequencer code... 396 instructions downloaded
> > > scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast 
> SCSI) 5.2.4/5.2.0
> > >        <Adaptec AIC-7892 Ultra 160/m SCSI host adapter>
> > > blk: queue c17fc418, I/O limit 4095Mb (mask 0xffffffff)
> > >   Vendor: SEAGATE   Model: ST318416N         Rev: 0004
> > >   Type:   Direct-Access                      ANSI SCSI 
> revision: 03
> > > blk: queue c17fc218, I/O limit 4095Mb (mask 0xffffffff)
> > >   Vendor: ADIC      Model: FastStor DLT      Rev: 0133
> > >   Type:   Medium Changer                     ANSI SCSI 
> revision: 02
> > > blk: queue c17fc018, I/O limit 4095Mb (mask 0xffffffff)
> > >   Vendor: QUANTUM   Model: DLT8000           Rev: 0232
> > >   Type:   Sequential-Access                  ANSI SCSI 
> revision: 02
> > > blk: queue c15c9a18, I/O limit 4095Mb (mask 0xffffffff)
> > >   Vendor: IBM       Model: DDYS-T36950N      Rev: S80D
> > >   Type:   Direct-Access                      ANSI SCSI 
> revision: 03
> > > blk: queue c15c9818, I/O limit 4095Mb (mask 0xffffffff)
> > >   Vendor: QUANTUM   Model: ATLAS10K2-TY734L  Rev: DDD6
> > >   Type:   Direct-Access                      ANSI SCSI 
> revision: 03
> > > blk: queue c15c9418, I/O limit 4095Mb (mask 0xffffffff)
> > >   Vendor: SEAGATE   Model: ST173404LW        Rev: 0002
> > >   Type:   Direct-Access                      ANSI SCSI 
> revision: 03
> > > blk: queue c15c9218, I/O limit 4095Mb (mask 0xffffffff)
> > > Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
> > > Attached scsi disk sdb at scsi0, channel 0, id 5, lun 0
> > > Attached scsi disk sdc at scsi0, channel 0, id 8, lun 0
> > > Attached scsi disk sdd at scsi0, channel 0, id 9, lun 0
> > > (scsi0:0:0:0) Synchronous at 20.0 Mbyte/sec, offset 31.
> > > SCSI device sda: 35885168 512-byte hdwr sectors (18373 MB)
> > > Partition check:
> > >  sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 >
> > > (scsi0:0:5:0) Synchronous at 160.0 Mbyte/sec, offset 63.
> > > SCSI device sdb: 71687340 512-byte hdwr sectors (36704 MB)
> > >  sdb: sdb1
> > > (scsi0:0:8:0) Synchronous at 160.0 Mbyte/sec, offset 127.
> > > SCSI device sdc: 143443640 512-byte hdwr sectors (73443 MB)
> > >  sdc: sdc1
> > > (scsi0:0:9:0) Synchronous at 160.0 Mbyte/sec, offset 63.
> > > SCSI device sdd: 143374738 512-byte hdwr sectors (73408 MB)
> > >  sdd: sdd1
> > > ...
> > > st: Version 20010812, bufsize 32768, wrt 30720, max init. 
> > > bufs 4, s/g segs 
> > > 16
> > > Attached scsi tape st0 at scsi0, channel 0, id 4, lun 0
> > > 
> > > 
> > > 
> > > Eventually, the system crashes.  The SCSI controller is 
> an AIC7800.
> > > 
> > > Questions:
> > > 
> > > 1) Anybody have any good ideas about what is going wrong and 
> > > how to fix
> > > it?
> > > 2) Am I testing the tape subsystem properly?
> > > 3) Am I correct in assuming that I cannot do anything 
> else with Amanda
> > > until this problem is resolved?
> > > 
> > > The tape drive is an ADIC FastStore 22, which is a DLT tape 
> > > drive and a
> > > changer.
> > > 
> > > 
> > > 
> > > Jeff Silverman, sysadmin for the Research Computing Systems (RCS)
> > > University of Washington, School of Engineering, Electrical 
> > > Engineering Dept.
> > > Box 352500, Seattle, WA, 98125-2500
> > > [EMAIL PROTECTED]
> > > http://rcs.ee.washington.edu/BRL/people/jeffs/
> > > 
> > > 
> > > 
> > 
> 

Reply via email to