"Rick McElroy" <> wrote in message news:<7Aq0b.2097$>.. .
> I am attempting to load Solaris 8 onto a Seagate ST336704LW. After booting
> to the cdrom it places installation files on the disk and then reboots upon
> reboot I get the following error: Rebooting with command: boot
> /pci@1f,4000/scsi@3/disk@1,0:b
> Boot device: /pci@1f,4000/scsi@3/disk@1,0:b File and args:
> Trap 3e
>
> Any Ideas? Any help would be greatly appriciated.
If one does a search on Google, one finds a lot of people have had
problem this when booting.
More usefully, a web page on docs.sun.com titled "common messages and
troubleshooting guide" provides the answer (this link is just for
those beggining for T by the way, so look a link above if you have
another message).
http://docs.sun.com/db/doc/805-4036/6j3r3qb91?a=view
Given web documents seem to disappear quite often, I thought I'd cut
and paste Suns's explanation, so hopefully someone seraching in the
future on Google groups might find it, just in case Sun remove the
document.
That said, Sun are in my oppinion the best (by a very long way) of a
provider of technical information of any of the UNIX manufacturers. I
might well be biased somewhat, as I've owned Suns a long time (much
longer than boxes from IBM, SGI, HP, Dec etc), but I seem to have a
**lot** more of a fight to find information on boxes from IBM, SGI, HP
etc than I ever do with Sun.
One can obtain user + service manuals from the IBM, SGI, HP, Dec (then
Compaq, then HP), but I'm not aware of the parts breakdown, or tables
where you can find the right memory for each machine, or places where
you can click on a part number and see what machine(s) and operating
systems it is supported in.
An IBM server of mine has 6 LEDs in addition to a 32 (or so) character
LCD which gives a lot of information on exactly what that machine is
doing. Except the function of the LEDs is not documented anywhere I
can find, and despite my best efforts, I've never found anyone that
can tell me what those LEDs do (although I have found out what one
does by accident).
So I think Sun's support is excellent. Even providing documentation on
machines what can only be described (by me anyway) as doorstops. Sun
tend to leave old documentation around for all to use if they want.
Well done Sun.
I might have had a knock or two at Sun's free Binary Licence for
Solaris 9, but nobody can argue with the online support Sun provide
for all at zero cost.
Anyway, here is what I gleaned about the trap 5e. I'd suggest looking
at the Sun web site, rather than my cut and paste, in case it ever
gets updated. But if the document is ever removed, here is the
explanation.
Sorry the email is rather long, I could easily have replied with a
just a web link, but I think I have made a valid point or two.
Dr. David Kirkby.
---
Taken from
http://docs.sun.com/db/doc/805-4036/6j3r3qb91?a=view
TRAP 3E
Cause
Ultra system fails to boot with TRAP 3E. The system sometimes also
displays bad magic number errors.
This is caused by a bad superblock on the boot disk. Which, in turn,
could have beee caused by a SCSI configuration problem.
Action
To fix:
1. Check SCSI bus for illegal configuration, bad cables, and duplicate
SCSI addresses;
2. Boot from cdrom in single user.
OK boot cdrom -sw
3. Attempt to fsck(1M) boot disk. This will probably fail with a
superblock error.
# fsck /dev/rdsk/device
4. Find out locations of alternate superblocks. BE SURE TO USE AN
UPPERCASE -N. For example:
# newfs -N /dev/rdsk/c0t0d0s0
/dev/rdsk/c0t0d0s0: 2048960 sectors in 1348 cylinders of 19
tracks,
80 sectors 1000.5MB in 85 cyl groups (16 c/g, 11.88MB/g, 5696 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 24432, 48832, 73232, 97632, 122032, 146432, 170832, 195232,
219632,
244032, 268432, 292832, 317232, 341632, 366032, 390432, 414832,
439232,
463632, 488032, 512432, 536832, 561232, 585632, 610032, 634432,
658832,
683232, 707632, 732032, 756432, 778272, 802672, 827072, 851472,
875872,
900272, 924672, 949072, 973472, 997872, 1022272, 1290672, ...
5. Using an alternate superblock, fsck(1M) the disk. You may have to
try more than one alternate superblock to get this to
work. Pick a couple from the beginning, the middle, and the end.
# fsck -o b=<altblk> /dev/rdsk/c0t0d0s0
6. The boot block is probably bad too. Restore it while we are booted
from the cdrom.
# /usr/sbin/installboot /usr/platform/architecture/lib/fs/ufs/bootblk
/dev/rdsk/c0t0d0s0
7. Reboot the O.S. Should come up now.
# reboot