Solved UFS2 superblock failed

dark.initr0

dark.initr0

Good day to everyone!

Today after rebooting I've got such error

1.jpg


2.jpg


I have SATA drive ~10y old, dual boot with Windows (currenty I write from Windows).
Before today I haven't changed any settings or made any heavy disk writing operations. Just rebooted to load Windows and then back to FreeBSD.

I have tried to run fsck for /tmp
Code: 
fsck -f /dev/ada0s4e
and simple
Code: 
fsck
but nothing helped.
And tried to find solution on this forum, but unfortunately couldn't

Any ideas how to fix?
 
I have run commands for my /tmp
Code: 
newfs -N /dev/ada0s4e
then
Code: 
fsck_ffs -b 192 /dev/ada0s4e
three times 'yes' and solved problem

In general I understand command but I don't understand details and root of problem - will try to find out
 
dark.initr0 said:
I have SATA drive ~10y old, dual boot with Windows (currenty I write from Windows).
Click to expand...
I had something similar, although under linux.
My SATA drive was 4 years old, and I have dead written it.
Then I noticed I have bad blocks, due to dead cells.
I think something like that is also happening to your drive, considering the age it has now.
 
The WD3200AA (Western Digital Blue) is a 500GB spinning rust disk. Could have bad blocks, yes, but not due to dead cells.

I'd check the drive with smartctl(8), it has likely passed its lifetime and might need to be replaced.
 
SATA SSDs will show up as ada(4) too, any SATA disk will. You can see the drive's model number (WDC WD3200AAJS) in the log output.
 
If this is due to disk hardware failure, you would very likely see IO errors in dmesg or /var/log/messages, and you would see error counts in the smartctl output (not self test, look at the error counters). It could theoretically be an undetected and uncorrected disk error, but those are astronomically unlikely.

The real problem is likely PEBKAC, and the disk was probably corrupted by some user action. It would be nice to figure out exactly what that was, so the OP can learn to not do that again.

Old joke: "Doctor, it hurts when I do that". "Well, then stop doing it."
 
ralphbsz said:
The real problem is likely PEBKAC, and the disk was probably corrupted by some user action.
Click to expand...
That would certainly do it, or non-user related power outages. Flip the switch often enough and you're bound to end up with a bunch of filesystem inconsistencies.

/tmp is easy to fix though. Just nuke it, nobody cares what's in /tmp. Files in it aren't even guaranteed to survive a reboot.

Code: 
     /tmp/      temporary files commonly removed between system reboots; see
                clear_tmp_enable in rc.conf(5)
hier(7)
 
SirDice said:
/tmp is easy to fix though. Just nuke it, nobody cares what's in /tmp. Files in it aren't even guaranteed to survive a reboot.
Click to expand...
Is /tmp not generally mounted on a RAM disk on FreeBSD ?
If I do file /tmp it reports me to be a sticky directory.
In Linux everything I mounted as a RAM disk had the sticky bit on it set.
 
SDK Chan said:
Is /tmp not generally mounted on a RAM disk on FreeBSD ?
Click to expand...
Not by default, no. I often set it though. See the example in tmpfs(5).

SDK Chan said:
If I do file /tmp it reports me to be a sticky directory.
Click to expand...
The sticky(7) bit has nothing to do with being a memory or disk based filesystem. But if you mount a tmpfs(5) on /tmp you do need to take care of the correct permissions. On a disk based filesystem those permissions are written to the filesystem, on a tmpfs(5) filesystem too, but its contents will be entirely empty again when you first mount it, thus it will not 'remember' those permissions.

Code: 
tmpfs           /tmp            tmpfs   rw,mode=1777 0 0
 
You must log in or register to reply here.
Back
Top