I apologize for the delay in posting this summary. The problem I
encountered was actually two-fold, and I was waiting for Sun to
issue a Bug-ID.
It turns out that it wasn't necessarily the CD-Rom drive that my
system was "requiring" to boot, but rather, any UniPack device.
The new UniPack storage units provide for "auto-termination" of the
A special thanks to Kevin Thomas for recalling a similar problem
where a blown SCSI fuse was causing problems like this. His
experiences encouraged me to experiment with different peripheral
When "regular" desktop storage packs were attached with manual
termination, the system would not boot a patched kernel. Even a
patched 4.1.4 kernel running on another SS20 would not boot here.
Sun sent me another system board, which did allow me to boot
without a UniPack device attached to the SCSI chain. However, once
I reattached a UniPack device, the system again began to require
this type of "auto-termination." Despite the low levels of current
involved, it almost seems like the auto-termination of the UniPack
is causing some type of permanent change on the system board.
"Regular" Desktop storage packs and manual SCSI termination had no
effect -- what mattered was whether or not a UniPack device was
attached, either alone, or in conjunction with other SCSI devices.
Strangely enough, kernels built before the recommended patches were
applied did boot with and without the UniPack devices attached.
Another special thanks to Don Lewis for suggesting that patch
102436 might be adding to the difficulties.
Here's a brief table summarizing some of my findings:
UniPack UniPack UniPack
never installed, installed
installed but then
not installed | OK OK OK
installed | OK won't boot OK
There are several Bug-IDs associated with patch 102436, but none
address booting in particular, and since the the UniPack devices
are so new to the market, there isn't much information on them
I apologize for the length of this summary, but this is certainly a
new problem, and is easily reproduceable, so I imagine that others
will soon face the same problem(s).
Short term solutions: once a UniPack device is allowed to
auto-terminate the SCSI chain, leave it on the end of the chain to
terminate, or back out patch 102436.
My appreciation to all those who responded:
Kevin W. Thomas <email@example.com>
Don Lewis <firstname.lastname@example.org>
Bismark Espinoza <email@example.com>
Kevin Sheehan <Kevin.Sheehan@uniq.com.au>
Keith M Willenson <firstname.lastname@example.org>
Joe Pruett <email@example.com>
Clive Beddall <firstname.lastname@example.org>
The original question:
> I have a recently installed SS20 running 4.1.4.
> I installed from an external 4x (Sun) CD-Rom drive.
> Once the drive is removed though, only the original
> kernel with boot.
> None of the patched or unpatched kernels built after
> the initial install will bring the system up.
> From the boot sequence:
> [. . .]
> MMCODEC: manufacturer id 1, rev 2
> root on sd0a fstype 4.2
> swap on sd0b fstype spec size 102600K
> dump on sdob fstype spec size 102580K
> <----- this is where it
> le0: Twisted Pair Ethernet hangs!
> checking filesystems
> [. . .]
> If I remove the CD-Rom drive, the boot sequence hangs
> where I've indicated above, and the system will only
> boot with the original kernel..
> Despite the fact that the SCSI Bus is supposed to be
> self termination, I even tried hanging a terminator on
> the end, but that didn't work either.
> Any suggestions would be greatly appreciated, since I
> don't want to leave the CD Rom drive on this machine.
> That's why I bought an external drive in the first place. =)
> - Christopher Chin
> Christopher M. Chin (415) 543-7696 (voice)
> UNIX/Network Administrator (415) 896-1327 (fax)
> Advent Software, Inc.
> 301 Brannan Street chris@Advent.COM
> San Francisco, CA 94107-1849
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:53 CDT