Solaris

Sorry about the misleading info from raidctl. The resync was shown because I powered down the system removed one of the disks and powered it back on with a single disk to see whether the error stays. Somehow I was only able to boot when d0 was installed. Pulling d0 the system was not able to boot. I have now replaced the second disk d1 with a fresh disk, the raid seems is rebuilt but still the system shows the same error during boot. I have now removed d0 again and booted only with the new synced d1 disk but the same error is shown. Is there a possibility that there is a problem with the filesystem itself and this error is now also replicated to the new disk?

Well it's complaining about a media error but, sure, it could indeed be a corrupt sector(s) in the middle of a filesystem.

This is, of course, the root filesystem. Is this filesystem UFS or ZFS?

A full filesystem check would be a good idea. Get ready to write down any inode numbers it complains about (it might not come out with actual filenames if the filesystem is corrupt.

Do you have a backup? If not, you should take one because filesystem checking can destroy a filesystem faster than you can blink if there is significant corruption and it tries to correct it.

Of course, you will probably need to boot from DVD media to check a root filesystem.

Probably a good idea just to do a root filesystem check with a "no write" flag. That way you get to see what damage there is without the risk that it will try to fix it. It will show you the difference as to whether there is one file corrupt or one million files corrupt.

It's a UFS filesystem. I did a file system check and the results don't look good:



There is no recent backup available. The project team that is responsible for the server did not regulary backup the machine. This morning I tried to ufsdump the filesystem but this failed with a couple of errors. I do have a ufsdump from 2017. Maybe I try to restore this dump to the new disk just to check whether this works. If it doesn't there must be a hardware fault somewhere in the system as the disk is brand new.

That's not too bad on face value.

There's obviously a superblock located at block=16 but the system maintains other copies at other block locations

AFAIR, you should be able to specify an alternative superblock location and get it to fix the superblock (at least).

Google that, I'll look it up too, or probably another Sun expert on here will chip in. Don't do anything rash yet.

Yep, there's another copy of the superblock at block=32. (And there will be others).

The search for an alternative superblock failed because you spec'd NO WRITE. So it didn't even try.

Use the switch:

Code:

-o b=32

on the command line to use superblock at block=32.