Drives showing "Cartridge In" - False Positive

[EricPMT]

I have a number of drives lately that are indicaitng there is a tape in the drive when there really is not.  Here is the output from robtest:

drive 1 (addr 500) access = 1 Contains Cartridge = no
drive 2 (addr 501) access = 1 Contains Cartridge = yes
drive 3 (addr 502) access = 1 Contains Cartridge = yes
drive 4 (addr 503) access = 0 Contains Cartridge = yes
Source address = 1163 (slot 164)
Barcode = 103973                    
drive 5 (addr 504) access = 1 Contains Cartridge = no
drive 6 (addr 505) access = 1 Contains Cartridge = yes
Source address = 1047 (slot 48)
Barcode = 102149                          
drive 7 (addr 506) access = 1 Contains Cartridge = yes
drive 8 (addr 507) access = 0 Contains Cartridge = yes
Source address = 1193 (slot 194)
Barcode = 109587                          
drive 9 (addr 508) access = 1 Contains Cartridge = no
drive 10 (addr 509) access = 1 Contains Cartridge = yes
drive 11 (addr 510) access = 1 Contains Cartridge = no
drive 12 (addr 511) access = 0 Contains Cartridge = yes
Source address = 1206 (slot 207)
Barcode = 103891                          
drive 13 (addr 512) access = 1 Contains Cartridge = no
drive 14 (addr 513) access = 1 Contains Cartridge = yes
drive 15 (addr 514) access = 1 Contains Cartridge = yes

As you can see 9 drives say there is a cartridge, but only 2 actually do.  I have verified this is the case in the silo.  As soon as NBU tries to use the drives, they are marked down.

The media servers have no problems detecting the drives.  Am I looking at some configuration issue or is this a Hardware issue with the drivs or the silo itself?

[sdo]

1) New build?  Or, an existing environment which used to work ok?

2) Library make, model and FW version?

3) NetBackup version?

4) Master OS version?

5) If any media servers are Linux/Unix... do you see anything in:   /var/log/messages     (or the equivalent)

6) If any media servers are Windows... do you see any events in the application or system event log?

[Marianne · Accepted solution]

NBU has no control over what the robot sees or reports. What happens if you tell the robot to unload one of the drives? e.g. unload d10 Or when you tell the robot to move the tape in 'loaded' drives to an empty slot or the map/cap? m s10 p1 If the robot remains 'confused', you may need to reboot/IPL the robot.

[mph999]

Reboot library (proper power off on)

Try again, if you still see the same, you'll need to call hardware vendor.

As Marianne points out, what is seen in robtest is 'sent' from the library, so if it is wrong, it is the library having an issue, not 'robtest'

[Mark_Solutions]

This can also be orphaned allocations

nbrbutil -resetall

can clear it up too .. but when nothing is running

A nbrbutil -dump will show if it is the case

[mph999]

Don't think orphaned allocations would cause the 'wrong' output in robtest ...

[EricPMT]

Thanks all.  I was pretty sure this was an issue with the silo itself and nothing to do with NBU, but just wanted to make sure I wasn't missing anything.  Here is what I did to fix the issue.  It was an out of the box approach but worked.

I suspended all jobs and made sure there were no tapes in any of the drives.  I opened the silo and was able to manually place a tape into each of the drives.  Closed the silo and let it re-initialize.  After everything was up, the panel on the silo now said all drives were in a loaded state.  I opened the silo and manually ejected each tape by pressing the eject button on ecah drive.  Placed the tapes back into empty slots.  After the silo re-initialized, I ran a ./inventory.  All drives are now working.  They all say empty and none of them went down last night when the backup jobs ran.

[Marianne]

Please mark solution for one of the posts that said this was a robot issue.