[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1172
  • Last Modified:

SUN server won't boot

We have a old Sun-Fire-V490 that wasn't behaving (couldn't su - to oracle user, just hung when trying to).  So we reboot it.  On reboot, the following messages are appearing at the console and we can't login.


WARNING: /pci@8,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8005446a34,4 (ssd13):
        Error for Command: write(10)               Error Level: Fatal
        Requested Block: 218112263                 Error Block: 218112263
        Vendor: HITACHI                            Serial Number: 50 0446A1113
        Sense Key: Not Ready
        ASC: 0x4 (LUN not ready), ASCQ: 0x0, FRU: 0x0
WARNING: /pci@8,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8005446a34,4 (ssd13):
        Error for Command: write(10)               Error Level: Fatal
        Requested Block: 218112256                 Error Block: 218112256
        Vendor: HITACHI                            Serial Number: 50 0446A1113
        Sense Key: Not Ready
        ASC: 0x4 (LUN not ready), ASCQ: 0x0, FRU: 0x0
WARNING: /pci@8,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8005446a34,4 (ssd13):
        Error for Command: write(10)               Error Level: Fatal
        Requested Block: 218112257                 Error Block: 218112257
        Vendor: HITACHI                            Serial Number: 50 0446A1113
        Sense Key: Not Ready
        ASC: 0x4 (LUN not ready), ASCQ: 0x0, FRU: 0x0
WARNING: /pci@8,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8005446a34,4 (ssd13):
        Error for Command: write(10)               Error Level: Retryable
        Requested Block: 218112263                 Error Block: 218112263
        Vendor: HITACHI                            Serial Number: 50 0446A1113
        Sense Key: Not Ready
        ASC: 0x4 (LUN not ready), ASCQ: 0x0, FRU: 0x0

The server has 2 local disks and 5 SAN LUNs, which were all apparently working fine prior to the reboot.  This appears to be a SAN HBA issue to me?

Anyone got any tips on troubleshooting this?
0
Crunched
Asked:
Crunched
  • 2
  • 2
2 Solutions
 
sentnerCommented:
Yes, that's a problem with one of the SAN LUNs on your Hitachi frame.  It's also possible that the HBA has gone bad.  Is the system set up to boot from SAN, or is it booting from internal disks?  

If it boots from local disk, I'd suggest booting to single user mode.  Drop it to the "ok" prompt and do:  boot -s

From there, you should at least be able to go in and modify the configuration to ignore that disk.  Or, you could disable one of the HBAs (I assume there are at least 2) and see if you can then access the device.
0
 
CrunchedAuthor Commented:
Unfortunately the same error repeats when I attempt to boot to single user mode.  The server isn't set to boot from SAN either, so I can't figure out why that is.  If I boot to single user from cd, I can select the disk through format.  I tried to fix the errored blocks, but to no avail:

format> repair
Enter absolute block number of defect: 218112263
Ready to repair defect, continue? y
Repairing hard error on block 218112263 (218112263)...ok.
The new block 218112263 (218112263) also appears defective.

Open in new window


I've asked our storage guys to see if there is an issue on the array, so we'll see what comes out of that.

How can I modify the config to get it to ignore that disk?
0
 
sentnerCommented:
You're not going to be able to run a repair on that if the device is bad.  But it looks as if you are able to at least get to the OS since you could run format.

Removing that disk from the configuration will require removing any mounted filesystems that it contains.  I don't know your setup, but a good place to start is looking at /etc/vfstab to see if anything mounts directly from that device.  It also could be part of a volume group, but there are several variations (vxvm, zfs, disksuite) so I would need more info to give advice.
0
 
CrunchedAuthor Commented:
Turned out to be a dud LUN config.
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now