I have a Sun Sparcstation 5 that was upgraded to Solaris 2.6 and since then the tape device drivers have disappeared. Short of re-installing the OS is there anything I can do?
I would do a dmesg ¦more and see if the device is listed there. If not, you can init 0 system and at the OK prompt do a boot -r , that is a reconfigure boot, it will search for all devices connected. I am assuming, of course, you did not add any devices to the scsi chain or change any scsi ID's. Also, make sure it's properly terminated and you don't have a TOTAL length of all cables on the same chain over 6 feet. If your cable length is too long, you should see scsi timeout and retry messages in /var/adm/messages. If all this fails, try a probe-scsi all (check the syntax, my memory fails) at the OK prompt. If it is not found at that level, the OS will not be able to see it. period. Hope this helps...
May I respectfully suggest that firstly; from the OK prompt try a probe-scsi-all see if the prom can see the scsi device if it can all is well, if it cannot check the cabling, scsi card and terminator. If the probe is good then generally I have found that 2.5.1 to 2.6 upgrades over-write the "st.conf" file thus even on a boot -r no device is seen or configured (if you are lucky it finds a device but lists it as a reel-reel tape. If the st.conf is over-written you will need to un-comment the correct tape drive entry in both sections of the st.conf (remove the # sign) then complete a boot -r for the kernel to be rebuilt with the scsi tape driver included from the st.conf
There is one other thing that I would like to mention that could be used prior to bringing the system down, (if it were a critical system). After validating/correcting the st.conf entries, rather than using a reconfiguring boot, first try:<br>
<br>
drvconfig; tapes <br>
<br>
This will accomplish all the updates to the dev & devices directories and create the proper switch table entries.<br>
<br>
Similarly,<br>
<br>
drvconfig; disks<br>
<br>
for disk drives. This is very valuable for disk/array migrations where reboots may not be an option.<br>
<br>
Murray
The following are the results of two commands you have mentioned. Pls give an idea on how to tackle the symbolic links problem (shown below)..
# drvconfig; tapes
Should only have symbolic links in /dev/rmt; /dev/rmt/0 is not a symbolic link
Should only have symbolic links in /dev/rmt; /dev/rmt/0mb is not a symbolic link
Could not create symlink /dev/rmt/0 because: File exists
Could not create symlink /dev/rmt/0mb because: File exists
# drvconfig; disks
#
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.