SCSI TROUBLESHOOTING SUN SYSTEMS
SCSI Errors in /var/adm/messages.
This is a brief description of how the scsi protocol communicates and how scsi errors come up in the /var/adm/messages file.scsi = Small Computer Serial Interface. Scsi devices connect to the host system via a host adapter. The host adapter is the actual connector and chip that interfaces the scsi bus to the system board. Both the host adapter and the scsi devices themselves have chipsets built in which allow them to control how they communicate on the bus, as opposed to the host system or bus controlling the communication.
In very simple terms for the scsi protocol there are 2 types of communicators, the initiator and the target. The initiator will wait for the scsi bus to become available, then arbitrate the bus by sending a one byte address over the bus of the device it wishes to address(target). Once the target is able to accept the request, it puts a busy signal on the bus and controls the communication until the request is met for the initiator. Target devices such as disks, and tape drives have the ability to queue requests. Some of the Sun Storage arrays also have memory specifically used to cache requests to devices. The purpose of queuing or caching scsi requests is to allow the bus to be available for other requests, while the device in question is able to fulfill the request from the initiator.
If there is a problem with either the initiator, or the target device when trying to fulfill a scsi request, then one of the devices will send a check condition over the bus. The other device will then respond with a sense key code or error message that tells why the request could not be completed. The response to the check condition is what the syslog process logs to the /var/adm/messages file.
Scsi errors that show up in the /var/adm/messages file will include the physical device path of the device that is reporting the problem. When reviewing the contents of the /var/adm/messages file, the idea is to use the chronological structure of the file to try and trace the life cycle of the problem.
The /var/adm/messages output follows the basic format that follows:
Feb 15 10:30:21 jnjeps1 unix: ID[SUNWssa.soc.link.5010] soc9: port 0: Fibre Channel is OFFLINE
The structure of the above line is:
Date / Time stamp of the messages; Feb 15 10:30:21 (Uses 24 hour format).
Hostname of problem system; jnjeps1 (The name in /etc/nodename).
Software level reporting problem; unix: (UNIX = the kernel)
Instance of device reporting problem; ID[SUNWssa.soc.link.5010] soc9: port 0:
Actual error message; Fibre Channel is OFFLINE
The line below is the next entry in the file and notes the same device coming back online.
Feb 15 10:30:22 jnjeps1 unix: ID[SUNWssa.soc.link.6010] soc9: port 0: Fibre Channel is ONLINE
The physical device path is constructed by the power on self test that is run by the open boot prom at power up. The physical device path uses a hierarchal structure. The hierarchal levels in the device path are separated by forward slashes, and define the different chipsets that make up the path to the device in question. The information below, for interpreting device paths excludes the following PCI based systems, (Ultra 5/10, 30, 60, 80, 220, 250, 420, and 450) systems. The differences for reading the device path on those PCI based systems is covered in the section titled scsi on the PCI platform.
The first level describes the system board level chip that addresses the host adapter.The second level describes the scsi type(narrow / wide / fast / ultra / single ended / differential), and address (onboard or sbus expansion card), of the host adapter that the connects the device to the system.The information described by the third level is dependent upon the type of enclosure that the scsi device is housed in.
Below is an example of a scsi device path from an Enterprise 6x00 system
/sbus@6,0/SUNW,fas@1,8800000/sd@3,0
The first level of the device path
/sbus@6,0
describes the system board level chip that addresses the host adapter. In this case the board level chip is an sbus controller chip at address 6,0.
The second level of the device path
/SUNW,fas@1,8800000
describes the type(fas), and address (@1) of the host adapter that the connects the device to the system.
The third level of the device path
/sd@3,0
describes the device itself, in this case a scsi disk (sd)at target 3, logical unit number 0.
Below is an example of the device path for a disk in an A5000 storage array connected to an Enterprise 6xxx system.
/sbus@2,0/SUNW,socal@2,0/sf@1,0/ssd@w210000203726d8b7,0
The first level of the device path
/sbus@2,0
describes the system board level chip that actually addresses the host adapter. In this case the board level chip is an sbus controller chip at address 2,0.
The second level of the device path
/SUNW,socal@2,0
describes the type(socal), and address (2,0) of the host adapter that the connects the device to the system.
The third level of the device path
/sf@1,0
describes the particular interface on the host adapter that the device is connected to, (1,0)
The fourth level of the device path
/ssd@w210000203726d8b7,0
describes the disk itself, in this case the disk has a unique id called a world wide number.
Below matches the chip names in the device path with a description of what the chip is.
iommu =System board level. Sun4m systems used the (Input Output Memory
Management) chip to control access to all scsi devices, either onboard
or in an sbus expansion slot.
Sbus = (Sun bus) System board level chip called sysio chip that controls to
access to the host bus adapters that follow in the device chain.
Esp = Host bus adapter level. Uses the narrow (50 pin) scsi controller, both
single ended, and differential bus. The esp driver supports the Emulex
family of esp SCSI chips (esp100, esp100A)..
fas = Fast bus adapter level. Uses the wide (68 pin) SCSI controller, single
ended only. The fas driver supports the Qlogic FAS366 SCSI chip.
feps = FEPS ASIC is a Fast Ethernet, Parallel Port, and Fast Wide SCSI
controller. The SCSI Channel consists of SCSI DVMA and FAS366.
Isp = Host bus adapter level. Uses the wide (68 pin) differential, and single
ended SCSI controllers. The isp driver supports the Qlogic ISP1000 SCSI
chip on SBus and the ISP1040B SCSI chip on PCI bus.
glm =Host bus adapter level. Uses wide (68 pin) UltraSCSI differential, and single
ended SCSI controllers. The glm driver uses the Symbios 53c875 SCSI chip.
soc =Host bus adapter level. Serial optical channel chip used for Sparc Storage
Array (SSA 1xx, 2xx) series disk arrays.
socal =Host bus adapter level. Serial optical channel arbitrated loop chip used in
the A5xxx, and fiber version of the A3500 storage arrays.
sf =Host bus adapter level. The interface to the actual fiber module used in
the A5xxx, and fiber version of the A3500 storage arrays.
pln =Host bus adapter level. The interface to the actual fiber module used in
the Sparc Storage Array (SSA 1xx, 2xx) series arrays.
sd =Device level, the driver used by scsi disks.
ssd =Device level. the driver used by Sparc Storage Array disks.
st =Device level, the driver used by scsi tape devices.
Scsi on the PCI platform.
The PCI based systems (Ultra 5/10, 30, 60, 80, 220, 250, 420, and 450) all use PCI as the onboard bus. The scsi host adapter will be at the second level of the device path for these systems. This means that the first level of the device path on these systems will always start with /pci@#. The # in a normal device path would be a number representing the board level chip that addresses the PCI slot in question. The following is an example of a "standard" scsi device path for a PCI based system:
/pci@1f,4000/scsi@3/sd@0,0
The device path below represents the path to a disk inside of an A5xxx storage array:
/pci@1f,2000/SUNW,ifp@1/ssd@w22000020371785ba,0
Below matches the chip names in the device path with a description of what the chip is. These names pertain to the (Ultra 5/10, 30, 60, 80, 220, 250, 420, and 450) systems.
pci = System board level. Peripheral component interconnect, parent bus on pci
based systems.
scsi = Host adapter level. Small computer systems interface. This will always
be the second level of the device path on pci based systems.
ifp = Host adapter level. the chip on the pci expansion card that interfaces
between the host adapter and the A5xxx storage array.
With the following exceptions, all Sun systems have a scsi adapter on the system board;
ELC (end of life) SunRay (Corona), JavaStation, and the Ultra 5/10
The "onboard" scsi controller is where the system looks to address internal devices. for all but a few sun systems. There will be an external adapter to the onboard scsi interface. The onboard bus can be accessed directly with no need to add additional scsi expansion cards.
All of the current Sun systems implement single ended scsi on the onboard bus. The following guidelines should be applied to the onboard scsi bus:
HVD devices will not work on the single ended onboard scsi bus.
Is not recommended to mix scsi types (narrow / wide) or scsi speed (fast / ultra) on the onboard scsi bus. Mixing scsi type on the onboard bus could be detrimental to system performance, or even render a system incapable of booting Solaris.
The matrix below defines the onboard scsi bus for Sun systems.
System Type
Onboard Bus Type
Path for onboard bus
Sparc Station2
SCSI 2 10 mbs narrow (50 pin)
Sparc Station IPX
SCSI 2 10 mbs narrow (50 pin)
Sparc Station Classic /LX
SCSI 2 10 mbs narrow (50 pin)
/iommu@0,10000000/sbus@0,10001000/espdma@/4,8400000/
Sparc Station 10
SCSI 2 10 mbs narrow (50 pin)
Sparc Station 5
SCSI 2 10 mbs narrow (50 pin)
/iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/
Spacr Station 4
SCSI 2 10 mbs narrow (50 pin)
/iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/
Sparc Station 20
SCSI 2 10 mbs narrow (50 pin)
/iommu@0,10000000/sbus@0,10001000/espdma@5,8800000/
Sparc Server 1000 / 1000E
SCSI 2 10 mbs narrow (50 pin)
Sparc Server 2000 / 2000E
SCSI 2 10 mbs narrow (50 pin)
Ultra 1
SCSI 2 10 mbs narrow (50pin)
/sbus@1f,0/SUNW,fas@e,8800000
Ultra 1 Enterprise
SCSI 2 20 mbs wide (68
/sbus@1f,0/SUNW,fas@e,8800000
Ultra 2
SCSI 2 20 mbs wide (68 pin)
/sbus@1f,0/SUNW,fas@e,8800000
Ultra 2 Enterprise
SCSI 2 20 mbs wide (68 pin)
/sbus@1f,0/SUNW,fas@e,8800000
Ultra 150
SCSI 2 20 mbs wide (68 pin)
/sbus@1f,0/SUNW,fas@e,8800000
Ultra 3x, 4x, 5x, 6x
SCSI 2 20 mbs wide (68 pin)
/sbus@3,0/SUNW,fas@3,8800000
Ultra 5 Device Paths
PCI Slot #1 /pci@1f,0/pci@1/<device>@1
PCI Slot #2 /pci@1f,0/pci@1/<device>@2
PCI Slot #3 /pci@1f,0/pci@1/<device>@3
Internal disk /pci@1f,0/pci@1,1/ide@3/dad@0,0
Internal CDROM /pci@1f,0/pci@1,1/ide@3/atapicd@2,0
Ultra 10 Device Paths
PCI Slot #1 /pci@1f,0/pci@1/pci@1/<device>
PCI Slot #2 /pci@1f,0/pci@1/pci@2/<device>
PCI Slot #3 /pci@1f,0/pci@1/pci@3/<device>
PCI Slot #4 /pci@1f,0/pci@1/pci@4/<device>
Internal Disk /pci@1f,0/pci@1,1/ide@3/dad@0,0
Internal CDROM /pci@1f,0/pci@1,1/ide@3/atapicd@2,0
Ultra 30,NETRA t 1100 Device Paths
40 mbs Ultra wide (68 pin)
PCI Slot #1 /pci@1f,2000/<device>@1
PCI Slot #2 /pci@1f,4000/<device>@2
PCI Slot #3 /pci@1f,4000/<device>@4
PCI Slot #4 /pci@1f,4000/<device>@5
Internal Disk /pci@1f,4000/scsi@3/sd@0,0
Internal CDROM /pci@1f,4000/scsi@3/sd@6,0
External SCSI Port /pci@1f,4000/scsi@3/<device>
Ultra 60,220R,NETRA t 1120/1125 Device Paths
40 mbs Ultra wide (68 pin)
PCI Slot #1 /pci@1f,2000/<device>@1
PCI Slot #2 /pci@1f,4000/<device>@2
PCI Slot #3 /pci@1f,4000/<device>@4
PCI Slot #4 /pci@1f,4000/<device>@5
Internal Disk /pci@1f,4000/scsi@3/sd@0,0
Internal CDROM /pci@1f,4000/scsi@3/sd@6,0
External SCSI Port /pci@1f,4000/scsi@3,1/<device>
Ultra 80,420R,NETRA t 1400/1405 Device Paths
40 mbs Ultra wide (68 pin)
PCI Slot #1 /pci@1f,2000/<device>@1
PCI Slot #2 /pci@1f,4000/<device>@4
PCI Slot #3 /pci@1f,4000/<device>@2
PCI Slot #4 /pci@1f,4000/<device>@5
Internal Disk /pci@1f,4000/scsi@3/sd@0,0
Internal CDROM /pci@1f,4000/scsi@3/sd@6,0
External SCSI Port /pci@1f,4000/scsi@3,1/<device>
Ultra Enterprise 250 Device Paths
40 mbs Ultra wide (68 pin)
PCI Slot #0 /pci@1f,4000/<device>@5
PCI Slot #1 /pci@1f,4000/<device>@4
PCI Slot #2 /pci@1f,4000/<device>@2
PCI Slot #3 /pci@1f,2000/<device>@1
Internal Disk Slot #0 /pci@1f,4000/scsi@3/sd@0
Internal Disk Slot #1 /pci@1f,4000/scsi@3/sd@8
Internal Disk Slot #2 /pci@1f,4000/scsi@3/sd@9
Internal Disk Slot #3 /pci@1f,4000/scsi@3/sd@a
Internal Disk Slot #4 /pci@1f,4000/scsi@3/sd@b
Internal Disk Slot #5 /pci@1f,4000/scsi@3/sd@c
Internal CDROM /pci@1f,4000/scsi@3/sd@6,0
External SCSI Port /pci@1f,4000/scsi@3,1/<device>
Ultra Enterprise 450 Device Paths
40 mbs Ultra wide (68 pin)
PCI Slot #1 /pci@6,4000/<device>@4
PCI Slot #2 /pci@6,4000/<device>@3
PCI Slot #3 /pci@6,4000/<device>@2
PCI Slot #4 /pci@6,2000/<device>@1
PCI Slot #5 /pci@1f,2000/<device>@1
PCI Slot #6 /pci@4,2000/<device>@1
PCI Slot #7 /pci@4,4000/<device>@4
PCI Slot #8 /pci@4,4000/<device>@3
PCI Slot #9 /pci@4,4000/<device>@2
PCI Slot #10 /pci@1f,4000/<device>@4
Internal CDROM /pci@1f,4000/scsi@2/sd@6,0
External SCSI Port /pci@1f,4000/scsi@2/<device>
As a rule is not a good idea to remove devices from the onboard bus when the system is up. This could cause the system to hang.
Most systems are configured with an internal CDROM, at least one disk, and possibly a tape drive.
With the exception of the Ultra 5 / 10, and the Netra T1xx systems, the internal CDROM is set to scsi id 6.
On the Ultra 5 / 10, and the Netra T1xx systems, the CDROM will be set to scsi id 2.
With the exception of the E3x, 4x, 5x, and 6x systems, the internal disks will be set to scsi id zero, or three.
On the E3000 system, there are ten internal disk slots on a scsi bus. The disk addresses are determined by the slot number the disk resides in.
On the E3500 system, there are eight internal disks on a socal bus. The disk addresses are determined by the slot number the disk resides in. The disks also have unique identifiers called the world wide number.
The scsi id of the internal disks on the E 4x,5x, and 6x systems can be configured on the disk board.
On the Enterprise 3x,4x,5x, and 6x systems, the onboard scsi bus terminates via the i.o. board in slot 1. It is a mandatory configuration rule that the external interface to the onboard scsi bus for the i.o. board in slot 1 be terminated. A terminator is the only officially supported device on that connector in that board slot.
The probe-scsi command probes the onboard bus only, use the probe-scsi-all command to probe all the scsi buses of the system.
Before using the any probe or test commands, the registers on the system boards must be cleaned to so that the commands will run.
Set the following openboot variables before attempting to run any probe or test commands from the openboot prom.
From the ok prompt:
setenv auto-boot? false
reset-all (on Ultra systems).
reset (on systems other than Ultra).
The probe and test commands should then run successfully.
On most Sun systems,the onboard scsi bus is referred to logically as controller0,(c0).
On E4x, 5x, 6x, system it is possible for the internal scsi device to end up on a controller other than 0.
The starting point for troubleshooting the onboard bus is to get the bus to a minimum configuration.
A minimum configuration constitutes either the internal CDROM on the bus by itself, or a single disk on the bus by itself, with no devices attached externally to the onboard bus. If the onboard bus consists only of external devices, then there should be only one external device attached (preferably a bootable device).
With the bus at a minimum configuration use the probe-scsi command to see if the openboot prom finds the devices as expected.
If the devices do show up as expected then go to the process of elimination troubleshooting section.
If the devices for the internal bus do not show up as expected after the bus is at a minimum configuration then determine if there is another scsi device that is compatible with the bus that can be used for testing. If the second device used for testing is not seen, then there is either a connection problem, or the onboard controller is bad.
With the exception of the E3x,4x,5x, and 6x systems, there is no external terminator required for the onboard scsi bus.
There is no onboard scsi bus in the Ultra 5/10 systems. The internal devices are on an ide bus. To probe the internal buses on the Ultra 5 / 10 systems, use the probe-ide command.
If the devices attached to the onboard bus show up as expected:
Then the Solaris environment has to be told to add device entries to access the device. Use boot -r from the ok prompt to add the device entries for the Solaris environment to access the device.
Determine which scsi bus the problem is showing up on by analyzing the device path from the errors in /var/adm/messages.
Below is a brief explanation of how to read Solaris device paths. There are two types of device paths, the logical path, and the physical path.
Logical paths are created by Solaris for devices that can be configured for specific usage.
Logical device entries for disks are stored in the /dev/dsk, and /dev/rdsk directories. The entries in these directories are links that point to the /device directory. The /devices directory is simply a hierarchical structure constructed to reference the different root level chipsets found in the system.
Physical device paths are the paths created by the open boot prom at power up. Solaris ultimately accesses the devices via the physical device path.
The device path uses the standard Solaris hierarchical device path. The levels of the hierarchy are separated by forward slashes. Reading from left to right, the first level in the device path is called the root node, and identifies what type of bus is addressed. The second level references the next chip in the path to the device which is usually a board level chip. The third level references the host adapter, this is the chip on the board that interfaces to adapter of the device.
Check the cables, Are the cables seated, are there any bent pins? Try to get a part number off of the cable.
Process of elimination, Add the first device, then run probe-scsi, if everything is still ok, then add the next device and run probe-scsi, repeat this process, until the problem device is found, or until the all the devices are added.
When adding new devices get the following information concerning the device being added:
Are there non Sun devices involved in the configuration.
If there are non Sun devices in the configuration:
use probe-scsi-all
If probe-scsi-all sees the device, then we know that the openboot prom recognizes the firmware on the device. Instruct the customer on using boot -r to configure the device into the appropriate Solaris device pathing. This is as far as we can go for supporting 3rd party devices.
If the device is not seen by probe-scsi-all, validate the configuration of the scsi bus with the steps defined in section.
If boot -r does not configure the 3rd party device into the Solaris device path, then the customer will need to contact the vendor of the device to determine if there are any specific configuration parameters needed for the device.
SUN SCSI ERRORS
Boot device: /iommu/sbus/variable/variable/sd@3,0
This message always appears at the beginning of rebooting. If there is a problem,
the system hangs, and no other messages appear. This condition is caused by
conflicting SCSI targets for the boot device, which is almost always target 3.
The boot device is usually the machine's internal disk drive, target 3. Make sure
that external and secondary disk drives are targeted to 1, 2, or 0, and do not conflict
with each other. Also make sure that tape drives are targeted to 4 or 5, and CD
drives to 6, avoiding any conflict with each other or with the disk drives. You can
set a device's target number using pushbutton switches or a dial on the back near
the SCSI cables. If the targeting of the internal disk drive is in question, check
it by powering off the machine, removing all external drives, turning the power on,
and running the probe-scsi-all or probe-scsi command from the PROM monitor.
giving up
This message appears in the SCSI log to indicate that a read or write operation
has been retried until it timed out. With SCSI disk the timeout period is usually
30 seconds; with tape the period is usually 20 attempts. Timeout periods are
generally coded into the drivers.
Check that all SCSI devices are connected and powered on. Make sure that SCSI
target numbers are correct and not in conflict. Verify that all cables are no
longer than six meters, total, and that all SCSI connections are properly terminated.
The scsi_log(9F) routine usually displays messages on the system console and in the
/var/adm/messages file. Run the dmesg(1M) command to see the most recent message
buffer.
No such device or address
This can occur when a tape drive is off-line or when a device has been powered off or
removed from the system.
For tape drives, make sure the device is connected, powered on, and toggled on-line (if
applicable). For disk and CDROM drives, check that the device is connected and powered on.
With all SCSI devices, ensure that the target switch or dial is set to the number where
the system originally mounted it. To inform the system of a change to the target device
number, reboot using the -r (reconfigure) option.
This message results from I/O to a special file's subdevice that either does not exist or
that exists beyond the limit of the device.
The symbolic name for this error is ENXIO, errno=6.
SCSI bus DATA IN phase parity error
The most common cause of this problem is unproved hardware. Some SCSI devices for the
PC market do not meet the high I/O speed requirements for the UNIX market. Other possible
causes of this problem are improper cabling or termination, and power fluctuations. Data
corruption is possible but unlikely to occur, because this parity error prevents data
transfer.
Check that all SCSI devices on the bus are Sun approved hardware. Then verify that all
cables are no longer than six meters, total, and that all SCSI connections are properly
terminated. If power fluctuations are occurring, invest in an uninterruptible power supply.
SCSI transport failed: reason 'reset'
This message indicates that the system sent data over the SCSI bus, but the data never
reached its destination because of a SCSI bus reset. The most common cause of this
condition is conflicting SCSI targets. Data corruption is possible but unlikely to occur,
because this failure prevents data transfer.
Verify that all cables are no longer than six meters, total, and that all SCSI connections
are properly terminated. If power surges are a problem, acquire a surge suppresser or
uninterruptible power supply.
A machine's internal disk drive is usually SCSI target 3. Make sure that external and
secondary disk drives are targeted to 1, 2, or 0, and do not conflict with each other.
Also make sure that tape drives are targeted to 4 or 5, and CD drives to 6, avoiding any
conflict with each other or with disk drives. If the targeting of the internal disk drive
is in question, power off the machine, remove all external drives, turn the power on, and
from the PROM monitor run the probe-scsi-all or probe-scsi command.
If SCSI device targeting is acceptable, memory configuration could be the problem,
especially for machines with the sun4c architecture. Ensure that high-capacity memory
chips (such as 4MB SIMMs) are in lower banks, while lower-capacity memory chips (such as
1MB SIMMs) are in the upper banks.
Note that SPARC systems do not always support third party CDROM drives, and might generate
a similar "unknown vendor" error message. Check with the CDROM vendor for specific
configuration requirements.
Some third party disk drives have a read-ahead cache that interferes with Solaris device
drivers. Make sure that any existing read-ahead cache facility is turned off.
For more information on SCSI targets, see the section on device naming conventions in the
Solaris 1.x to Solaris 2.x Transition Guide. If you are using the AnswerBook, "scsi targets"
is a good search string.
Soft error rate (retries = int) during writing was too high
This message from the SCSI tape drive appears when Archive tapes generate too many soft
(recoverable) errors. It is followed by the advisory "Periodic head cleaning required and/
or replace tape cartridge" message. Soft errors are an indication that hard errors could
soon occur, causing data corruption.
First clean the tape head with a cleaning tape as recommended by the manufacturer. If that
doesn't work, replace the tape cartridge. You might need to replace the tape drive if the
problem still occurs with new tape cartridges.
The SCSI bus is hung. Perhaps an external device is turned off.
This message appears near the beginning of rebooting, immediately after a
"Boot device: ..." message, and then the system hangs. The problem is conflicting SCSI
targets for a non-boot device. Having an external device turned off is unlikely to cause
this problem.
See the message "Boot device:
/iommu/sbus/variable/variable/sd@3,0" for a solution.
TRAP 3E
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
been caused by a SCSI configuration problem.
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