After several crashes during videos it seemed like a good idea to fsck root. Downloaded the latest systemrescuecd and ran it at boot. The error message was ‘bad magic number, corrupt superblock’ with a suggested command to try another superblock. That failed with the same message. Tried tune2fs to force fsck at boot and got the same message. The drive is less than 6 months old and the installed system is working more or less ok. The command I used was ‘fsck.ext4 /dev/sdc2’. What am I doing wrong?
Also, I don’t understand why the system is working with bad blocks.
I found a suggestion that you could try using an alternative Superblock. My example is using my /dev/sda3 partition and you can run this when the partition is mounted, but it can’t be fixed while it is mounted. I could even log in as root and unmount /home if I wanted to not use a rescue disk I suppose. Again, just as before, the partition can not be mounted to run fsck as root on it and the command dumpe2fs must be accessible:
/sbin/dumpe2fs /dev/sda3 | grep superblock
I get an output like this:
dumpe2fs 1.41.14 (22-Dec-2010)
Primary superblock at 0, Group descriptors at 1-29
Backup superblock at 32768, Group descriptors at 32769-32797
Backup superblock at 98304, Group descriptors at 98305-98333
Backup superblock at 163840, Group descriptors at 163841-163869
Backup superblock at 229376, Group descriptors at 229377-229405
Backup superblock at 294912, Group descriptors at 294913-294941
Backup superblock at 819200, Group descriptors at 819201-819229
Backup superblock at 884736, Group descriptors at 884737-884765
Backup superblock at 1605632, Group descriptors at 1605633-1605661
Backup superblock at 2654208, Group descriptors at 2654209-2654237
Backup superblock at 4096000, Group descriptors at 4096001-4096029
Backup superblock at 7962624, Group descriptors at 7962625-7962653
Backup superblock at 11239424, Group descriptors at 11239425-11239453
Backup superblock at 20480000, Group descriptors at 20480001-20480029
Backup superblock at 23887872, Group descriptors at 23887873-23887901
Backup superblock at 71663616, Group descriptors at 71663617-71663645
Backup superblock at 78675968, Group descriptors at 78675969-78675997
Backup superblock at 102400000, Group descriptors at 102400001-102400029
I could then try to use fsck as root on the unmounted partition with this command using the 32768 from the above information I found about /dev/sda3:
fsck -b 32768 /dev/sda3
Then, you could try to mount it as root to see if you get an error:
mount /dev/sda3 /mnt
Let me know if this is helpful in any way.
Thank You,
On 2011-05-14 21:36, mlmack wrote:
>
> After several crashes during videos it seemed like a good idea to fsck
> root. Downloaded the latest systemrescuecd and ran it at boot. The error
> message was ‘bad magic number, corrupt superblock’ with a suggested
> command to try another superblock. That failed with the same message.
> Tried tune2fs to force fsck at boot and got the same message. The drive
> is less than 6 months old and the installed system is working more or
> less ok. The command I used was ‘fsck.ext4 /dev/sdc2’. What am I doing
> wrong?
Are you sure that partition is of type ext4? Check it: “file -s /dev/sdc2”.
> Also, I don’t understand why the system is working with bad blocks.
Depends.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
file -s /dev/sdc2 returns /dev/sdc2: x86 boot sector, code offset 0x0. Whatever that means. fstab says it’s ext4
/sbin/dumpe2fs /dev/sdc2 | grep superblock returns
orca:/home/mlmack # /sbin/dumpe2fs /dev/sdc2 | grep superblock
dumpe2fs 1.41.11 (14-Mar-2010)
/sbin/dumpe2fs: Bad magic number in super-block while trying to open /dev/sdc2
Couldn’t find valid filesystem superblock.
What now?
At this point, if this were my drive, I would back up all important data to a different drive and reformat and/or reload openSUSE and try again. Of course, you can download and burn other boot disks like Gparted, which I have had some luck with, but in the end, if you find nothing else that helps, it is time to start over.
Thank You,
On 2011-05-15 06:06, mlmack wrote:
>
> file -s /dev/sdc2 returns /dev/sdc2: x86 boot sector, code offset 0x0.
> Whatever that means. fstab says it’s ext4
Recognition can fail if it also is a boot partition.
Anyway, if it is ext4 is very badly damaged. Backup and reformat.
If you suspect badblocks, run the SMART long test. If there are bad
sectors, overwrite the entire disk with zeros, and try again. Bad sectors
are to be expected, only a problem if they increase.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
Will try smart later. With 350 gigs of data, a repair is very desirable.
How do I overwrite with 0’s?
If you overwrite with zeros, the data will be gone…
& if I were you, I’d see that I get as much data of the disk as it will allow, write it to another disk, replace the current one. When bad blocks appear, more will follow.
Haven’t had time for smart yet. But…
fsck.ext4 says my system is screwed. systemrescuecd says my system is screwed. gparted says my system is fine. Whom am I to believe?
On 2011-05-15 20:36, Knurpht wrote:
> When bad
> blocks appear, more will follow.
Sometimes.
I had a disk with a bunch of badsectors and used it after that for several
years. 20e3 hours. No more bad sectors. It is not atypical.
However, if you dropped it on the floor while running, you will see the
number going up rapidly.
So, do a backup, and observe it carefully.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
On 2011-05-15 19:06, mlmack wrote:
>
> Will try smart later. With 350 gigs of data, a repair is very desirable.
> How do I overwrite with 0’s?
>
>
dd if=/dev/zero of=/dev/sdX bs=500M
Notice that this destroys all data and partition table. But, it also forces
remapping of all badsectors.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)