Video Screencast Help

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

Created: 28 Dec 2012 • Updated: 06 Jan 2013 | 8 comments
This issue has been solved. See solution.

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

Comments 8 CommentsJump to latest comment

Nicolai's picture

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.

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.

Marianne's picture

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.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

weigojmi's picture

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's picture

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
 

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

weigojmi's picture

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's picture

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's picture

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.

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.

SOLUTION
Marianne's picture

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.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links