Error nbjm(pid=5996) NBU status: 800, EMM status: The robotic library is not defined in EMM

[weigojmi]

Hello, I currently get this error on all tape backups.  This started after I was having a problem with a downed drive so I deleted all drives and robot and ran device config to re-add them.  All looks good to me otherwise...I'm able to run inventory, robtest detects robot ok, no other errors in gui.

I've done so far:

- Restart nb services

- Restarted nb server

- Seeing these errors in app log:

TLD(0) [4020] Lock of B:\VERITAS\Volmgr\misc\tldcd.lock failed with LOCK_OP_FAILED: Error: -3

Unknown robot number 0, from host us010017.na.ina.com

TLD(0) unavailable: initialization failed: Robot number does not exist

Thanks,

Jamie

[Nicolai]

In the GUI under robots - Do you have both TLD0 and TLD1 defined ?.  You should be able to delete TLD0 as I believe TLD1 is the active with tape drives defined.

[Marianne]

I agree with Nicolai.

If you did not restart NBU device management services after deleting devices, new robot was probably added as TLD(1).

Please double-check current device config.

Also check STU properties - if robot is now no. 1, update STU properties or create a new STU and update all policies.

[weigojmi]

Hi, there is only 1 robot (tld0) defined but I notice 2 new additional STU are created. One using tld(0) and one tld(1). I assume these were created during running the device config wizard? They are not used in any policies and I deleted them. No change in problem status however.

[Marianne]

Please show output of these commands (in <install-path>\veritas\volmgr\bin):

tpconfig -l

vmoprcmd -d

as well as this one (in <install-path>\veritas\netbackup\bin\admincmd)

bpstulist -L
 

[weigojmi]

Device Robot Drive Robot Drive Device Type Num Index Type DrNum Status Comment Name Path robot 0 - TLD - - - - {6,0,0,0} drive - 0 hcart2 3 UP - HP.ULTRIUM2-SCSI.000 {4,0,3,0} drive - 1 hcart2 1 UP - HP.ULTRIUM2-SCSI.001 {6,0,1,0} drive - 2 hcart2 2 UP - HP.ULTRIUM2-SCSI.002 {7,0,2,0} PENDING REQUESTS DRIVE STATUS Drv Type Control User Label RecMID ExtMID Ready Wr.Enbl. ReqId 0 hcart2 TLD - No - 0 1 hcart2 TLD - No - 0 2 hcart2 TLD - No - 0 ADDITIONAL DRIVE STATUS Drv DriveName Shared Assigned Comment 0 HP.ULTRIUM2-SCSI.000 No - 1 HP.ULTRIUM2-SCSI.001 No - 2 HP.ULTRIUM2-SCSI.002 No - Label: ESL9322_US010017 Storage Unit Type: Media Manager Host Connection: us010017 Number of Drives: 3 On Demand Only: no Density: hcart2 (14) Robot Type/Number: TLD (8) / 1 Max Fragment Size: 2048 Max MPX/drive: 8 Label: Disk Storage Unit Type: Disk Media Subtype: Basic (1) Host Connection: us010017 Concurrent Jobs: 1 On Demand Only: yes Path: "C:\Temp" Robot Type: (not robotic) Max Fragment Size: 524288 Max MPX: 1 Stage data: no Block Sharing: no File System Export: no High Water Mark: 90 Low Water Mark: 80 Ok On Root: yes Label: Catalog_Backup Storage Unit Type: Disk Media Subtype: Basic (1) Host Connection: us010017 Concurrent Jobs: 1 On Demand Only: yes Path: "B:\Catalog_Backup" Robot Type: (not robotic) Max Fragment Size: 524288 Max MPX: 1 Stage data: no Block Sharing: no File System Export: no High Water Mark: 90 Low Water Mark: 80 Ok On Root: no Strange stu list shows robot #1? Should I recreate that STU?

[weigojmi]

I recreated the STU and now the stu list shows the right robot #. Test backup looking OK! Any idea why gui showed one # and stulist shows another?

[Nicolai · Accepted solution]

From my experience if you re-start Netbackup services (all of them) without restarting the (java) gui - some information may be invalid until the GUI is restarted as well.

[Marianne]

This is what I thought from the beginning - that STU was the culprit.

My initial thought was that device config would show robot 1 and STU robot 0.

I have very early in my troubleshooting with NBU learned to rely on cmd output - while collecting output in order to log a Support call with Symantec, I was actually able to pinpoint the problem and fix it without logging the call.