I have a Linux Mint 12 install on my laptop. Yesterday I powered it off like I always do and this morning when I started it I was greeted by an error screen.

(Translated from Swedish)

Fatal errors found upon checking the disk unit for /home

I was given the option to ignore, skip och manual recovery. I first tried ignore, which just narrowed it down to skip and manual recovery.

In manual recovery mode (a prompt as root) I tried fsck.ext4 -p /dev/sda3.

fsck.ext4: Device or resource busy while trying to open /dev/sda3
Filesystem mounted or opened exclusively by another program?

So I booted a live version of Linux Mint 12. The partition did not appear in nautilus like the other partitions. I tried fsck.ext4 -p /dev/sda3

fsck.ext4: Bad magic number in super-block while trying to open /dev/sda3

The superblock could not be read or does not describe a correct ext4
filesystem.  If the device is valid and it really contains an ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

I read a tutorial on the issue and typed mke2fs -n /dev/sda3

mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
4218880 inodes, 16852736 blocks
842636 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
515 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424

I chose a random number in that list, 294912, and typed e2fsck -b 294912 /dev/sda3

e2fsck 1.41.14 (22-Dec-2010)
One or more block group descriptor checksums are invalid.  Fix<y>? yes

Group descriptor 0 checksum is invalid.  FIXED.
Group descriptor 512 checksum is invalid.  FIXED.

/dev/sda3 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #1 (31743, counted=24413).
Fix<y>? yes

(then there's about 100 more of that but different groups)

Free blocks count wrong for group #465 (32768, counted=30402).
Fix<y>? yes

Free blocks count wrong (16541927, counted=13884226).
Fix<y>? yes

Free inodes count wrong for group #208 (8192, counted=8183).
Fix<y>? yes

(10 more of these)

Free inodes count wrong (4218869, counted=4214769).
Fix<y>? yes

/dev/sda3: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda3: 4111/4218880 files (2.1% non-contiguous), 2968510/16852736 blocks

I then mounted /dev/sda3 to /mnt. The files are encrypted using ecryptfs. I used ecryptfs-recover-private which gave me my files in /tmp. They seem non corrupted.

Why does my superblock "recorrupt" itself on boot? A quick S.M.A.R.T. test show that disk is OK, no bad sectors.

  • 3
    First, do a memory test. Memory goes bad sometimes, and bad memory can corrupt data in subtle or unsubtle ways. Boot into memtest86. Most recovery media have an option for that; if Mint's doesn't, get a Memtest86+ boot image. – Gilles Apr 15 '12 at 23:01
  • Good call. I'll do that tomorrow. – runfalk Apr 15 '12 at 23:51
  • Memtest86+ is unable to boot, just flashes by and crashes instantly. Then the computer just restarts. This happen regardless of configuration of memory sticks. The same Memtest USB boots just fine on my desktop. – runfalk Apr 16 '12 at 11:52
  • Co-author/co-maintainer of eCryptfs here. I'd just like to confirm that although you're using eCryptfs for file encryption, eCryptfs won't be corrupting your superblock. eCryptfs does not operate at the block device level. – Dustin Kirkland Apr 16 '12 at 18:37
  • I'm facing exactly the same behavior, a sudden corruption of my home partition...though, not on every boot but once in a few weeks. Nearly the same output is given by fsck. Ubuntu 11.04, 2.6.38-15-generic, Kingston SSDNow V 64GB, two partitions, root and home, home encrypted. I'm not totally sure, but I think the corruption occurs on shutdown, maybe a problem with ext4 journaling/buffering and the encryption system. So far no data loss, but totally annoying. – Bobby Sep 8 '12 at 19:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.