Re: [Networker] Faulty device status info

Stan,
        Sorry, I forgot to mention, be careful not to remove the
carriage return from the resource field when removing the
tape/barcode/slot entry (they act as place markers) so, if your labels =
barcode and the barcode was 123456L3 and the slot was 234 then 
Position cursor on the end 3 of entry the loaded barcode field and press
backspace 8 times. Do this for the tape name too and for the slot number
above you would position cursor just after the 4 and backspace 3 times.

If you leave the carriage returns in then Networker will not complain.
(I know it is a bit fiddly and probably not supported by EMC but it has
got me out of a few similar situations).

You could try deleting volume from media database and relabelling a
scratch volume, but I'm not sure if that will buy you anything

Regards
Bob


>-----Original Message-----
>From: EMC NetWorker discussion 
>[mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On Behalf Of Stan Horwitz
>Sent: 27 November 2006 15:18
>To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
>Subject: Re: [Networker] Faulty device status info
>
>On Nov 27, 2006, at 9:46 AM - 11/27/06, Stuart Whitby wrote:
>
>> Hmm.  Maybe a bit late, but if you can identify the save 
>which thinks 
>> it's writing to that drive, that should filter back through to 
>> NetWorker.  Should be obtainable from the daemon.log if you 
>can't get 
>> it using lsof against the [dead] nsrmmd.
>>
>> Otherwise, if all other backups on that storage node are 
>done, you may 
>> be able to kill off the nsrexecd process on that system.  The server 
>> will see this and restart the mmds.  It *may* be possible to try 
>> running a small save to that pool with other drives in 
>service mode.  
>> Haven't tried this, but this may force nsrd into realising that the 
>> mmd is no longer there.
>
>This is very strange. I killed off the save that was going to 
>that device, then after a while, I killed the nsrmmd for it.
>
>On the basis of the email from Bob Wood, I tried adjusting the 
>tape library resource, but it gave me an error that said it 
>needed 13 tapes loaded. I then noticed that in the list of 
>tapes, one item in the list was blank, so I filled it in with 
>the proper label, then I manually loaded that tape into the 
>affected tape drive via the library's control panel. I then 
>tried to use nsrjb -HEv on that drive. It did attempt to 
>unload the tape, but it failed because the tape is defective 
>(probably munged tape marks), so I tried using "nsrjb -u" and 
>it again complained that the tape was is write mode!  
>Sigh!
>
>Bouncing nsrexecd is not an option because this tape library 
>is connected to the server and I have some other backups in 
>progress that I don't want to interrupt.
>
>Unless someone else has any ideas, I guess I will just have to 
>do without that tape drive for a couple of days until I can 
>shut down the networker daemons, empty out /nsr/tmp and 
>restart stuff. Oh well!
>
>
>Thanks
>
>To sign off this list, send email to 
>listserv AT listserv.temple DOT edu and type "signoff networker" in 
>the body of the email. Please write to 
>networker-request AT listserv.temple DOT edu if you have any problems 
>with this list. You can access the archives at 
>http://listserv.temple.edu/archives/networker.html or via RSS 
>at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>
>

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER