Amanda-Users

Re: Problems with finding tapes loaded

2003-11-06 11:29:33
Subject: Re: Problems with finding tapes loaded
From: Jon LaBadie <jon AT jgcomp DOT com>
To: amanda-users AT amanda DOT org
Date: Thu, 6 Nov 2003 11:28:20 -0500
On Thu, Nov 06, 2003 at 07:51:34AM -0800, Adam Ardis wrote:
...
> 
> Anyone have an idea what that refers to?  This backup
> setup has been working for some time, although on
> occassion I have seen problems with writing to all 4
> drives.  I guess I could have a problem with the
> cables.  And I'm wondering if the (4,0) (4,1) (4,2)
> part of this message refer to /dev/rmt/0ubn, 1ubn, and
> 2ubn.

Not certain.  /dev/rmt/0, 1, 0n, ... are symbolic links
to actual hardware devices.   What does ls -l /dev/rmt/0
report?  The actual device name may include a 4,#.

> But if I have a cable problem, would amanda still show
> the drives being empty instead of no drives at all?

A scsi cable has 50 - 80 wires.  If one is defective
would all functions be affected?  Probably not.

> mt command doesn't work though, so maybe this says
> something.

It say the problem has nothing to do with amanda.
That is an important finding.  Time to stop even looking
at amanda and get your tape drives working.  If mt
doesn't even work, then reads and writes with tar, dd,
ufsdump will fail too.

> 
> twdbs001:/export/home/amanda$ mt -f
> /devices/pci@1f,4000/scsi@3,1/st@2,0:ubn rewind
> /devices/pci@1f,4000/scsi@3,1/st@2,0:ubn: No such
> device or address

Curious as to why you switched to the actual device
names here rather than /dev/rmt/...

BTW the long listing for my tape drive shows this:

/dev/rmt/0 ->  ... /st@5,0:

In my case the 5,0 refers to the scsi id and lun.

Thinking back to your 4,0 4,1 ... messages, are your
4 drives in a single library and the 4 being the scsi id
with the ,# being the lun within the library?  If so,
does your /kernel/drv/st.conf file show boot time scans
are activated for lun > 0?  By default it is not.

Have you changed any hardware configuration recently?
If so, the symbolic links in /dev/rmt are not reset
automagically.  You need to do a reconfiguration reboot
to reset them.  Either "touch /reconfigure" and reboot
or during boot when you get the 5 second opportunity,
enter "b -r" to give boot options.

Alternatively, if you can't reboot, you can try to reset
them with from the command line.  I'd suggest the following
steps:

1. move the current rmt directory out of the way by renaming
   to something like rmt.old.  Remember, it only contains
   symbolic links so all we are doing is giving you the
   ability to restore things to the original state.

2. create a new rmt directory with the same owner/group/mode.

The above steps would not be a bad idea before a reconfig reboot.

3. run either:

        /usr/sbin/devfsadm -c tape
              or
        /usr/sbin/tapes         # depricated but available


If the /dev/rmt/* links are recreated then the system knows
about your drives and they have drivers attached.  This could
also be checked before this with prtconf -v though the output
is long and you have to find what you are looking for.

If what they point to is the same as the links in rmt.old
then this was a exercise in futility :)  If different then
there was a hardware change without a reconfigure reboot.


A basic caveat is don't even think about trying amanda
commands until you can use your tape drives with the
commands that came with the system.

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)