fsck kills itself

[coffeysm]

Fellow gurus,

I have ran into a problem that is making me scratch my head.

I powered off a Sun Fire V210 (init 5), so I could install a video card, that went well. However when I powered it up my hard drive started to have problems.

It asked me to perform an fsck, so I performed an: fsck -y to scan all my file systems. When it scans the / drive I recieve the following errors:

-1 DUP I=17
0 DUP I=17
1 DUP I=17
2 DUP I=17
3 DUP I=17
4 DUP I=17
5 DUP I=17
6 DUP I=17
-1 DUP I=17
0 DUP I=17
EXCESSIVE DUP BLKS I=17
CONTINUE=yes

FSCK: WARNING: FOLLOWING COMMAND (PROCESS XXX) WAS TERMINATED BY SIGNAL 11 AND DUMPED CORE
FSCK -F UFS -Y /DEV/RDSK/C1T0D0S0

I am assuming it is having a problem with an inode or something, and am guessing I will probably have to do a restore but wanted to see if anyone else had any suggestions.

I have tried performing the fsck in single user mode and single user mode booted from the cd.

Any help would be great.

Thanks,
Steven

 

[bfitzmai]

Steve, I am sure you found this information also... Never seen this problem my self. Looks like the restore option is the way to fix this.

Cause of Excessive Dup Blocks:

Inode inode-number contains a block number block-number with a number lower than the number of the first data block in the file system or greater than the number of the last block in the file system. This error condition might generate the EXCESSIVE BAD BLKS error message in phase 1 if inode inode-number has too many block numbers outside the file system range. This error condition generates the BAD/DUP error message in phases 2 and 4.

EXCESSIVE DUP BLKS I=I (CONTINUE)
There are too many (usually more than 10) blocks claimed by other inodes.
Possible responses to the CONTINUE prompt are:


YES
Ignore the rest of the blocks in this inode and continue checking with the next inode in the filesystem. This error condition prevents a complete check of the filesystem. A second run of fsck should be made to recheck the filesystem.

NO
Terminate the program.


EXCESSIVE DUP BLKS I=N CONTINUE?
==================================

During phase 1, fsck(1M) found more than 10 duplicate (previously
claimed) blocks associated with the specified inode number.

With this many duplicate blocks, it might be preferable to
restore the filesystem from backup tapes.

For more informationon blocks, see the section on checking
filesystem integrity in the System Administration Guide, Volume
I. If you are using the AnswerBook, "bad blocks" is a good search
string.

 

[coffeysm]

bfitz,

Thanks but I did browse through that document and pretty much said what I figured. What made it worse was it was my root file system, and it is my management server (licenses, jumpstart/flashstart, big brother, etc...).

What I ended up doing was wiping out the system and rebuilding with a flash cd I have. Then I put Netbackup Client back on and restored all the information I needed. It is up and running now, but it was a long day....

Thanks for the response though.

 

[gman789]

One of my user accounts on a Solaris 8 server takes about 45 seconds to logon. All the other user accounts logon immediately. What would cause this problem?

gman789

 

[bfitzmai]

gman,
Could be something in the users shell specific rc file (.kshrc .cshrc). If the user has something in their path that no longer exists, the OS will try to make a link to that path until it times out. One thing you could try is have the user login under Command Line Login instead of CDE. Error messages may appear when he does that. Or, as root, su - <username> to see if there are any errors.