NOTE - this psuedo-summary probably raises more questions than it
answers and is pretty long. IF you have work to do today, you'll
probably want to give it a miss...
A couple days ago I asked for help on how to set the SCSI id on a Seagate
hard drive. I unfortunately neglected to mention the platform on which the
disk was running. I got a lot of answers whcih I will try and summarize -
I can't thank you individually since my mail spool got blown away (I believe
this is called "forshadowing" ;-(
But, thanks to everyone that answered. Your help was much appreciated!
--------------------------------
Original Problem:
Machine: Netra (Ultra-1)
OS: Solaris 2.5.1
Disk: Seagate ST32430WC
I had a disk that sounded like it was going bad. Sun sent me a replacement.
I stuck the disk in the lower SCSI all-in-one slot and it came up as SCSI id 1.
(The top slot is SCSI id 0 though I had thought it would be 3. I tried to get
eeprom to tell me the value of sd-target but it wouldn't. Perhaps not a valid
option for this machine's boot PROM?) In any case, The new disk was easily
formatted and partioned as c0t1d0. I newfs'd each of the slices that needed
it it and then proceeded to do a dump and restore to the new disk from the
old disk. (Some of you may have noticed I forgot to fsck the new filesystems.
You are right. I am an idiot.) Since I had performed a level 0 dump of all
filesystems to tape the day before I didn;t worry too much and went ahead with
ufsdump 0uf - /dev/rdsk/c0t0d0s? | (cd /appropriate_filesystem xf -)
according to the man page. The final step was to make the new root bootable:
installboot /usr/paltform/sun4u/lib/fs/bootblk /dev/rdsk/c0t1d0s0
To make sure the machine would boot from the alternate root I tried:
boot disk1 kernel/unix -as
The machine booted but had problems mounting file systems. OK, no problem I
thought, this will work out when I switch the disks for real. So...I switch
the disks - the original goes in the lower bay (presumably scsi id 1) and the
new disk goes in the upper bay (presumably scsi id 0). Then I reboot...
Well, the machine does not boot. It reports that it is unable to boot from
the specified kernel. "Drat" (That is not exactly what I said at the time)
So I try:
boot disk0 kernel/unix
and the machine begins to boot. Whoa. I thought the SCSI id would change
automagically on the Ultra based on the bay the drive was in? Not on mine.
So I shutdown, pull the upper (new) drive and try to reboot. No problem,
boots fine. Filesystems mount as specified in vfstab (and they are all
spec'd as c0t0 so I believe the disk is still recognized as scsi id 0)
Running format after the machine comes up confirms: ...00/sd@0,0
So apparently the bay is NOT setting the scsi id as I thought. Ok, no
problem. I will start again and this time fsck the new filesystems before
doing the dumps and maybe all will be well. (ha!) For reasons unknown to
me, I decide to put the old (original) disk back in the upper bay. I shut
the machine down to the boot PROM, power off and move the disk to the upper
bay. Turn on the power, the machiness begins to bootstrap and voila':
ERROR: Your / and /usr partitions so badly hammered you can not boot.
Try reloading the OS from the cd rom or booting with boot -b to fix
the problem. (THis is, of course, paraphased)
It is now that I remember my sole 2.5.1 boot cd is 20 miles away at our
remote site on a bookshelf. Argh. So boot cdrom is not an option.
man boot and man kernel don't tell me what boot -b does but it doesn't
seem like I have a lot of options, so I try it. It makes no difference.
Machine refuses to boot.
HERE'S WHERE IT GETS INTERESTING....
Just for grins (what have I got to lose?) I pull the disk and place it
in the lower bay. THis is the original disk now in the lower bay.
POW - the machine boots fine. A few things are strange: Some people
(ok one person) has lost a couple text files placed on the machine
that day. ANother lost some mail from that day. Another (me) had
some mail messages show up for a second time and changes made to my
home directory (like, say, a new mh folder created with a bunch of
responses from the sun managers group on scsi id problems) disappear.
This sounds to me like it was late and I screwed up and dumped file
systems backwards (i.e. overwrote with the previous days dumps)
So...in conclusion (if you are still with me)...my machine boots fine
as long as the disk is in the lower bay. It will not boot with the
disk in the upper bay for the reason noted above. (I tried fscking
/ and /usr but that did not appear to help). The replacement disk
is not in the machine though it needs to be. I somehow managed to
turn what, in the past, has been a farily easy job, into a total
nightmare. Tonight I will try and verify everything that I have
just mentioned and make sure that I was not just REALLY tired.
Not sure what anyone will make of this - maybe just a little misery
loves company for you if you have problems tonight. ;-)
------------------
Andrew F. Mitchell afm@biotech.ufl.edu
Network Systems Administrator www.biotech.ufl.edu/~afm
UF Biotechnology Program (352) 846-1733
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:18 CDT