Summary: Problems with tapes and SunOS 4.1.4
------------------------------------------------------------------------------
Answer:
After verifying the dir's:
/dev
/usr/kvm/sys/scsi/targets/st_conf.c
and "Generic" kernal setup...
all looked in place...
probe-scsi-all the tape show's up...
where I blew it was I had the tape on a scsi address 2....
scsi 2 is not "tape" device in the generic kernal...
The generic kernal is configured for tape devices on scsi address
4,5,1 and 0...
I new that once...
Thanks for the input...
From: szh@zcon.com (Syed Zaeem Hosain)
From: "Raj Channa" <raj@admin37.admin.lehman.com>
From: "David L. Elliott" <delliott@src.umd.edu>
From: jeff@datapage.com (Jeff Greer)
From: Tom Gasaway <tdg@advtech.uswest.com>
------------------------------------------------------------------------------
ORIGINAL Question:
I have some questions on tape drives...I just installed 4.1.4 on a sparc
classic and the system can't see the tape drive...
The devices dir looks normal.
The tape drive is on scsi 4
The system boots with out an st0 bla...bla...
If I do a probe-scsi the system can find the tape drive. On system power
up the tape does do its diags....
Am I missing something real obvious or is this an issue with 4.1.4
------------------------------------------------------------------------------
Are you running the GENERIC kernel or did you build a new one? The
GENERIC kernel ought to see the drive at st0 with SCSI address 4. My
4.1.4 system works fine for my tape drive at address 4.
What kind of tape drive is it? One of the standard supported Sun ones
or some "unsupported by Sun" drive of some kind? You may need to add
some kernel support parameters to the st device driver params for
unsupported drives.
------------------------------------------------------------------------------
did you try probe-scsi-all ?
------------------------------------------------------------------------------
I'm still using 4.1.3, so this may be totally off the point... but...
When you rebuilt your /vmunix for the new system, did
/usr/kvm/sys/scsi/targets/st_conf.c
have an entry for the tape drive species you are using? Some drives are not
in the Sun-issued version of OS4.1.3, for instance I had to add mine--
/* Exabyte 4MM 4GB cartridge */
{
"Exabyte EXB-4200 4MM Helical Scan", 16, "EXABYTE EXB-4200",
ST_TYPE_EXB4200, 512,
(ST_VARIABLE | ST_BSF | ST_BSR ),
5000, 5000,
{ 0, 0, 0, 0 },
{ 0, 0, 0, 0 }
}
------------------------------------------------------------------------------
Here is the summary for my generic question about upgrading to SunOs 4.1.4.
Start with my original post.
I am preparing to upgrade two SUN systems to 4.1.4
Sparc IPC - Server - 4.1.3 - Openwin 3
Sparc II - Dataless client - 4.1.2 - cross mounts /usr/openwin3
/usr/share/man
I have read the "Upgrading to Solaris 1.1.1" docs and all the readmeS I
could find. Being that this is my first time upgrading/installing, I was
hoping to find "watch out for..." comments or advice in this endevour.
_______________________________________________________________________________
1) Do a full install instead of an upgrade
sunupgrade makes backup copies of some (not all) of the files it replaces
some folks have ended up with an aborted upgrade due to / and /usr filling
up with these backup copies.
2) Another suggestion to install from scratch followed by a restore of any
config files that may have been overwriten
3) Include the basic Sunwindows libraries, "SunWindow_Users". This will allow
use of Openwindows without the -nosunview option.
4) Another suggestion to watchout for config files being clobbered along with
the offer of a script to SAVE and UNSAVE these files. (Nico Garcia)
5) Suggestion to use local CD-ROM drive instead of remote.
6) Another caution about the / and /usr partitions becoming full during upgrade.
Along with a suggestion that the "upgrade" uinstall scripts disk size
calculations were extremely broken.
This is the offending distribution.
>Sun +may+ have fixed this, but I'd be careful ... My Sol 1.1.2 CDROM is:
>
> Part # 704-4662-10 <---- Mine is 804-4662-10
> Revision A 11/94 <---- Mine is the same
Thanks to the following folks for their input.
Ayrton Sargusingh (asargusi@sofkin.ca)
kim (kimc@w8hd.org)
Nico Garcia (raoul@mit.edu)
R A Lichtensteiger (rali@hri.com)
__________________________________________________________________
I would suggest making an online copy of /etc and /usr/etc. I did this and then
copied volatile files back. This saved time over restoring the needed config
files. Whatch out using "cp -R" command it did not work form me, I think it got
confused on linked files?
Althoug using a remote CD is a bit slower I did not find that it was at all difficult.
I would also suggest finding alternative boot methods in case the system doesn't
come back up after upgrading.
------------------------------------------------------------------------------
This is what we've got:
SunOS mailhub.a 4.1.4 1 sun4m
crw-rw-rw- 1 root staff 18, 1 Jan 6 10:19 /dev/rst1
crw-rw-rw- 1 root staff 18, 25 Jan 6 10:19 /dev/rst25
mt -f /dev/rst25 stat
Exabyte EXB-8500 8mm tape drive:
sense key(0x0)= no sense residual= 0 retries= 0
file no= 0 block no= 0
We did not have to patch the kernel for 8505 tape drives because
it was already built in.
And it seems to work OK for us.
------------------------------------------------------------------------------
> I checked dmesg and no st devices....
Then, since probe-scsi in the prom shows the device, I will claim that
your kernel is not really GENERIC then or one that has tape support at
that SCSI address! You ought to try and config and rebuild a new kernel
(configured with a tape device as I mentioned) anyway and see what
happens with it.
Also, with SunOS 4.1.4, the EXB8505 device is in the configuration
parameters files for the 'st' devices. With SunOS 4.1.3 or earlier, it
was not there since this was not a supported Sun device prior to that
rev of the OS. (For more information about what I am talking about, see
/sys/scsi/targets/st_conf.c).
------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:27 CDT