NetBackup upgrade to 7.5 caused sgscan to disappear

[AV77]

Hi,

After what seemed to be a successful upgrade of NetBackup Master/Media from 6.5.6 to 7.5.0.3 on Solaris 10 (VCS Cluster) my sg devices disappeared and I cannot rebuild them. At least without a reboot I can't.

The sg devices disappeared (sgscan returns nothing, not tapes nor disks) from both Solaris10 x64 members of the cluster.

I am puzzled by the fact that sgscan cannot see anything...

I can see the tape devices with "cfadm -al"  as

c1::5005076312436e37           tape         connected    configured   unknown
c1::500507631243acd1           tape         connected    configured   unknown

but nothing is returned using sgscan.

in sg.conf I have these relevant entries:

name="sg" parent="fp" target=0 lun=0 fc-port-wwn="500507631243acd1";
name="sg" parent="fp" target=0 lun=1 fc-port-wwn="500507631243acd1";
name="sg" parent="fp" target=0 lun=0 fc-port-wwn="5005076312436e37";
name="sg" parent="fp" target=0 lun=1 fc-port-wwn="5005076312436e37";

and in sg.links:

name="sg" parent="fp" target=0 lun=0 fc-port-wwn="500507631243acd1";
name="sg" parent="fp" target=0 lun=1 fc-port-wwn="500507631243acd1";
name="sg" parent="fp" target=0 lun=0 fc-port-wwn="5005076312436e37";
name="sg" parent="fp" target=0 lun=1 fc-port-wwn="5005076312436e37";

modinfo returns:

188 7b35a000   35d0 328   1  sg (SCSA Generic Revision: 3.6)

I tried unlaoding the sg module by "modunload -i 188", and reload the driver but it returns

# modunload -i 188
can't unload the module: Device busy
 

Any suggestions??? Any thoughts why could it happen? Is "reboot -- -r" the only answer?

[revarooo]

# modunload -i 188
can't unload the module: Device busy

hmmm thats OS related.

What does /usr/openv/volmgr/bin/scan   show?

[mph999]

Should not need a reboot.

Try this...  

cd /usr/openv/volmgr/bin/driver

cp sg.links sg.links.safe

cp sg.conf sg.conf.safe

../sg.build all

modunload -i $(echo $(modinfo |grep "sg (SCSA" |awk '{print $1}'))

mv /kernel/drv/sg.conf /kernel/drv/sg.conf.old

/usr/openv/volmgr/bin/driver/sg.install

If the above does not work, try this ....

cd /usr/openv/volmgr/bin/driver

cp sg.links sg.links.safe

cp sg.conf sg.conf.safe

modunload -i $(echo $(modinfo |grep "sg (SCSA" |awk '{print $1}'))

mv /kernel/drv/sg.conf /kernel/drv/sg.conf.old

/usr/openv/volmgr/bin/driver/sg.install

Regards,

Martin

[AV77]

Hi revaroo, thanks for coming back

I will try Martin's suggestion asap, but to your question:

scan  - returns nothing

I wonder if modunload keeps returning "busy" whether I should do (obviously when NetBackup/Volmgr processes are down)

modunload -i 0  

as per http://docs.oracle.com/cd/E19455-01/805-7378/debug-84/index.html

Has anyone seen this??? 

[AV77]

sorry, I was wrong. The output from san is as follows:

# scan
************************************************************
*********************** SDT_TAPE    ************************
*********************** SDT_CHANGER ************************
************************************************************
Unable to intialize the device mappings table, status = 1
 

[Marianne]

Question: can you confirm that old sg driver was removed and new version of sg driver succesfully installed during upgrade?

install_trace.#### in /usr/openv/tmp will hopefully contain this info.

maybe Martin can confirm what sg driver version should be on NBU 7.5?

[Marianne]

Device Mapping!   

Unable to intialize the device mappings table, status = 1

Try to download and and install latest Device Mappings:

http://www.symantec.com/docs/TECH189461

[AV77]

Hi Martin,

as expected the output:

# ../sg.build all
The file ./st.conf should be appended to /kernel/drv/st.conf.
A reboot may be necessary to create any new device files.
Created file ./sg.conf.
Created file ./sg.links.

# modunload -i $(echo $(modinfo |grep "sg (SCSA" |awk '{print $1}'))
can't unload the module: Device busy

========================

As I cannot risk an unexpected reboot or a crash I feel I'll have to stop here and wait for the weekend when I hopefully can reboot.  I am worried as identical lost of sg devices happened on both servers of the VCS cluster after/due to upgrade to 7.5 (or 7.5.0.3). 

[AV77]

from the /opt/openv/tmp/install_trace.###

....

Original /etc/inetd.conf saved as /etc/inetd.conf.NB_072612.19:39:51.
Sending SIGHUP to inetd process.

        Copied files to /kernel/drv/sparcv9.

Doing add_drv of the sg driver

Leaving existing sg configuration.
If you wish to update the configuration you need to
        rm -f /kernel/drv/sg.conf
and rerun /usr/openv/volmgr/bin/driver/sg.install.

Converting STREAMS files.  This may take a few minutes.

STREAMS files conversion is complete.

...

[AV77]

no joy... changing/updating mappings didn't do the trick...

# tpext -get_dev_mappings_ver
device mappings version in the EMM database is 1.102
device mappings version from the local file is 1.102
Local device mappings file is up-to-date
 

[mph999]

225 7bbf0000   37a8 291   1  sg (SCSA Generic Revision: 3.7)

[mph999 · Accepted solution]

Hmm, suspect the sg driver is having a moment, i'd just reboot, 'cos it ain't going to unload any other way ...

[AV77]

188 7b35a000   35d0 328   1  sg (SCSA Generic Revision: 3.6)
262 7a786000   3d90 151   1  sgen (SCSI generic driver 1.11)
 

SCSA Generic Revision: 3.6 - is on both members of the cluster.

Does it mean the driver should have but hasn't been upgraded during the upgrade to 7.5 or 7.5.0.3 ?

thanks!

[Marianne]

When you reboot, PLEASE don't use 'reboot -- -r'. Rather create /reconfigure touch file and reboot using init 6.

'reboot' will sync filesystem and reboot without performing any of the shutdown scripts in rc0.d.

[AV77]

ineteresting...

on my old cluster (running NBU 6.5.6 on Solaris 9)

188 78400000   35cd 269   1  sg (SCSA Generic Revision: 3.6)

and

190 78402815   35cd 278   1  sg (SCSA Generic Revision: 3.6)

===========

on this one (running NBU 7.5.0.3 on Solaris 10)

188 7b35a000   35d0 328   1  sg (SCSA Generic Revision: 3.6)

and

188 7b35a000   35d0 328   1  sg (SCSA Generic Revision: 3.6)

same revision, different sizes (assuming due to diff OS versions)




 

[AV77]

very good point!

[AV77]

Any clues why sg driver wasn't updated (on either member of the cluster) to 3.7?

what do you think about  "modunload -i 0", or is it too risky in a prod environment?

Thanks!

[mph999]

No idea - modunload is fine, just make sure you get the right driver.

Martin

[AV77]

How do I make it sure?

[mph999]

Run the comamand I gave.

modunload -i $(echo $(modinfo |grep "sg (SCSA" |awk '{print $1}'))

It automatically checks.

martin