After Reboot sg path does not exist

Please verify that persistent binding is in place to ensure that device addresses do not change when system is rebooted.

What hba and driver is used in your master ? (check /var/adm/messages shortly after reboot)

What does 'sgscan' and 'scan' report after the reboot?

After each reboot I get the same device address... It seems that the raw file is missing where the device address is pointing to. Here are the messages after the last reboot: ... Apr 15 10:14:18 hsrvbkpt1 scsi: [ID 799468 kern.info] st3 at fp0: name w50014380032c1d5a,0, bus address 2 Apr 15 10:14:18 hsrvbkpt1 genunix: [ID 936769 kern.info] st3 is /pci@0,0/pci8086,340c@5/pci10df,fc42@0/fp@0,0/tape@w50014380032c1d5a,0 Apr 15 10:14:18 hsrvbkpt1 scsi: [ID 365881 kern.info] /pci@0,0/pci8086,340c@5/pci10df,fc42@0/fp@0,0/tape@w50014380032c1d5a,0 (st3): Apr 15 10:14:18 hsrvbkpt1 Apr 15 10:14:19 hsrvbkpt1 scsi: [ID 799468 kern.info] st2 at fp2: name w50014380032c1d60,0, bus address 2 Apr 15 10:14:19 hsrvbkpt1 genunix: [ID 936769 kern.info] st2 is /pci@0,0/pci8086,340c@5/pci10df,fc42@0,1/fp@0,0/tape@w50014380032c1d60,0 Apr 15 10:14:19 hsrvbkpt1 scsi: [ID 365881 kern.info] /pci@0,0/pci8086,340c@5/pci10df,fc42@0,1/fp@0,0/tape@w50014380032c1d60,0 (st2): Apr 15 10:14:19 hsrvbkpt1 Apr 15 10:14:26 hsrvbkpt1 scsi: [ID 799468 kern.info] sgen0 at scsi_vhci0: name g50014380032c1d58, bus address g50014380032c1d58 Apr 15 10:14:26 hsrvbkpt1 genunix: [ID 936769 kern.info] sgen0 is /scsi_vhci/medium-changer@g50014380032c1d58 Apr 15 10:14:26 hsrvbkpt1 tldcd[1097]: [ID 295976 daemon.error] TLD(1) [1097] robotic path /dev/sg/c0tw50014380032c1d5al1 does not exist Apr 15 10:14:26 hsrvbkpt1 last message repeated 1 time Apr 15 10:14:26 hsrvbkpt1 tldd[1093]: [ID 915677 daemon.error] TLD(1) unavailable: initialization failed: Unable to open robotic path Apr 15 10:14:27 hsrvbkpt1 avrd[1094]: [ID 920050 daemon.notice] st.conf configuration for r1_drive0 (device 0), name [HP Ultrium LTO 4], vid [HP Ultrium 4*], type 0x3b, block size 0, options 0x18619 (see st(7D) man page) Apr 15 10:14:27 hsrvbkpt1 sg: [ID 266374 kern.notice] Symantec SCSA Generic Revision: 3.7 Apr 15 10:14:27 hsrvbkpt1 avrd[1094]: [ID 262211 daemon.notice] st.conf configuration for r1_drive1 (device 1), name [HP Ultrium LTO 4], vid [HP Ultrium 4*], type 0x3b, block size 0, options 0x18619 (see st(7D) man page) Apr 15 10:16:28 hsrvbkpt1 tldcd[1097]: [ID 295976 daemon.error] TLD(1) [1097] robotic path /dev/sg/c0tw50014380032c1d5al1 does not exist Apr 15 10:16:28 hsrvbkpt1 last message repeated 1 time Apr 15 10:16:28 hsrvbkpt1 tldd[1093]: [ID 915677 daemon.error] TLD(1) unavailable: initialization failed: Unable to open robotic path Apr 15 10:18:30 hsrvbkpt1 tldd[1093]: [ID 947741 daemon.notice] TLD(1) going to UP state Apr 15 10:38:50 hsrvbkpt1 pseudo: [ID 129642 kern.info] pseudo-device: fcsm0 Apr 15 10:38:50 hsrvbkpt1 genunix: [ID 936769 kern.info] fcsm0 is /pseudo/fcsm@0 Apr 15 10:38:51 hsrvbkpt1 scsi: [ID 193665 kern.info] sd2 at mr_sas0: target 7 lun 0 Apr 15 10:38:51 hsrvbkpt1 genunix: [ID 936769 kern.info] sd2 is /pci@0,0/pci8086,340a@3/pci1000,9263@0/sd@7,0 ... And 'sgscan' or 'scan' are just reporting the two drives. The Robot is missing.

Have a look at the device address that the OS sees and the device name configured in NBU:

OS medium-changer: 50014380032c1d58
expected sg device:   50014380032c1d5a

Try to rebuild sg drivers:

cd /usr/openv/volmgr/bin/driver
# /usr/openv/volmgr/bin/sg.build all -mt <15> -ml <1>

Install the new sg driver configuration:

# /usr/bin/rm -f /kernel/drv/sg.conf
# /usr/openv/volmgr/bin/driver/sg.install

Check/verify config:

# /usr/openv/volmgr/bin/sgscan

I tried it but it put again "50014380032c1d5a" and 'sgscan' didn't show the Robot after the sg.install. I made the following: # cd /usr/openv/volmgr/bin/driver # /usr/openv/volmgr/bin/sg.build all -mt 15 -ml 1 # more sg.conf # Configuration file for SCSA Generic. # name="sg" class="scsi" target=0 lun=0; name="sg" class="scsi" target=0 lun=1; name="sg" class="scsi" target=1 lun=0; name="sg" class="scsi" target=1 lun=1; name="sg" class="scsi" target=2 lun=0; name="sg" class="scsi" target=2 lun=1; name="sg" class="scsi" target=3 lun=0; name="sg" class="scsi" target=3 lun=1; name="sg" class="scsi" target=4 lun=0; name="sg" class="scsi" target=4 lun=1; name="sg" class="scsi" target=5 lun=0; name="sg" class="scsi" target=5 lun=1; name="sg" class="scsi" target=6 lun=0; name="sg" class="scsi" target=6 lun=1; name="sg" class="scsi" target=8 lun=0; name="sg" class="scsi" target=8 lun=1; name="sg" class="scsi" target=9 lun=0; name="sg" class="scsi" target=9 lun=1; name="sg" class="scsi" target=10 lun=0; name="sg" class="scsi" target=10 lun=1; name="sg" class="scsi" target=11 lun=0; name="sg" class="scsi" target=11 lun=1; name="sg" class="scsi" target=12 lun=0; name="sg" class="scsi" target=12 lun=1; name="sg" class="scsi" target=13 lun=0; name="sg" class="scsi" target=13 lun=1; name="sg" class="scsi" target=14 lun=0; name="sg" class="scsi" target=14 lun=1; name="sg" class="scsi" target=15 lun=0; name="sg" class="scsi" target=15 lun=1; name="sg" parent="fp" target=0 lun=0 fc-port-wwn="50014380032c1d5a"; name="sg" parent="fp" target=0 lun=1 fc-port-wwn="50014380032c1d5a"; name="sg" parent="fp" target=0 lun=0 fc-port-wwn="50014380032c1d60"; name="sg" parent="fp" target=0 lun=1 fc-port-wwn="50014380032c1d60"; # /usr/bin/rm -f /kernel/drv/sg.conf # /usr/openv/volmgr/bin/driver/sg.install Copied files to /kernel/drv/amd64. Doing add_drv of the sg driver Removing old /dev/sg entries. Editing /etc/devlink.tab... Copying original /etc/devlink.tab to /etc/devlink.tab.04-19-11-07:23:49. Added entry in /etc/devlink.tab file. Made links in /dev/sg # /usr/openv/volmgr/bin/sgscan /dev/sg/c0tw50014380032c1d5al0: Tape (/dev/rmt/0): "HP Ultrium 4-SCSI" /dev/sg/c0tw50014380032c1d60l0: Tape (/dev/rmt/1): "HP Ultrium 4-SCSI"

I am not too familiar with Solaris x86.

I'm wondering if the the Solaris sgen driver is preventing the sg driver from using the medium changer.

There is also a Solaris patch that 'breaks' the sg driver - 127128-11 (x86), although you are not seeing the errors described in http://www.symantec.com/docs/TECH56850 .

Please try to disable/unload the Solaris sgen driver and retry sg.build and sg.install.