ext4 - data loss after power failure, and unable to recover

[bodhi.zazen]

Ubuntu 9.04 , system is (was) up to date, home partition is encrypted with ecryptfs

After a power failure I am unable to access the Ubuntu system, booting drops to busybox.

From a live CD :

[quote]root@ubuntu:~# fsck -y /dev/sda1
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
/dev/sda1: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway? yes

fsck.ext4: unable to set superblock flags on /dev/sda1
[/quote][quote]root@ubuntu:~# fsck /dev/sda1
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
/dev/sda1: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? yes

fsck.ext4: unable to set superblock flags on /dev/sda1[/quote][quote]root@ubuntu:~# fsck /dev/sda1
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
/dev/sda1: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? no

Clear journal<y>? no

/dev/sda1: clean, 138871/373152 files, 681246/1492029 blocks

root@ubuntu:~# fsck -y /dev/sda1
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
/dev/sda1: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway? yes

fsck.ext4: unable to set superblock flags on /dev/sda1[/quote][quote]root@ubuntu:~# fsck /dev/sda1
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
/dev/sda1: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? no

Clear journal<y>? yes

/dev/sda1 was not cleanly unmounted, 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

/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda1: 138871/373152 files (0.2% non-contiguous), 681246/1492029 blocks[/quote][quote]root@ubuntu:~# mount -t ext4 /dev/sda1 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

root@ubuntu:~# dmesg | tail
[ 1894.643462] JBD: recovery failed
[ 1894.643468] EXT4-fs: error loading journal.
[ 1894.645367] sd 0:0:0:0: [sda] 12582912 512-byte hardware sectors: (6.44 GB/6.00 GiB)
[ 1894.645385] sd 0:0:0:0: [sda] Write Protect is off
[ 1894.645387] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1894.645404] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 1894.645422] sd 0:0:0:0: [sda] 12582912 512-byte hardware sectors: (6.44 GB/6.00 GiB)
[ 1894.645432] sd 0:0:0:0: [sda] Write Protect is off
[ 1894.645434] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1894.645450] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA[/quote][quote]root@ubuntu:~# mke2fs -n /dev/sda1
mke2fs 1.41.4 (27-Jan-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
373152 inodes, 1492029 blocks
74601 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1530920960
46 block groups
32768 blocks per group, 32768 fragments per group
8112 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736

root@ubuntu:~# e2fsck -b 32768 /dev/sda1
e2fsck 1.41.4 (27-Jan-2009)
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/sda1: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
e2fsck: unable to set superblock flags on /dev/sda1

[Scott James Remnant (Canonical) (canonical-scott)]

Obviously one should expect data loss after a power failure, that's why we run fsck on boot.

However being unable to subsequently recover your filesystem is unfortunate: the "unable to set superblock flags" error is interesting. Ted, any ideas?

[uaneme (manostienen)]

Don't know if this is related but i'm trying to figure out why karmic is unable to create ext4 on several older drives (6.4 to 10 GB)

On the other hand, Jaunty installs just fine on those drives but when i boot up from a karmic live CD, then the karmic live CD is not able to read ext3 partition, it detects sda but not the actual partitions sda1 and the sda5 swap.

And another thing: when i want mount a drive that i tried to partition with the karmic installer (i386 desktop, alternat and server all the same) then those drives appear to have a bad superblock and are not accessible from ANY system (Ubuntu 8.04 to 9.10, windows xp, and even with tools like on the ultimate boot cd i'm not able to fix the bad superblock)

But for some magical reason that i don't understand, i can use a jaunty live CD and install ubuntu (while loosing all the data) and the bad superblock appears to be fixed.

And another thing... I also lost a partition on a external harddrive (also bad superblock..) ext3 partition that got lost while working with a ubuntu karmic install. I'm becoming a bit paranoia of these issues, and i hope it is just coincidence, but something tells me there is more to it and maybe i better go back to jaunty untill i see this fixed.

A personal note: i think it was a bad choice to choose for ext4 beta and grub2 beta together on this release. It works, but i doubt it's stability. And i'm missing an EASY way to CHOOSE during the install to use ext3 and grub0.95 INSTEAD of ext4 and grub2. Infact i would have preferred ext3 and grub0.95 still as default until ext4 and grub2 are out of beta and STABLE.
(a bit more like Debian)

Is this post enough to get this looked at or should i post a new bug report?

[Theodore Ts'o (tytso)]

Uaname, I'd suggest opening another bug report since the problem with not being able to see partitions with the karmic sounds like it may be a much more fundamental problem --- I suspect some kind of kernel issue where the Karmic kernel isn't compatible with your "older drives". You should specify in that new bug report what kind of drives they are --- SATA? IDE? (I suspect IDE) and what controller they are using. An output of the dmesg on boot of the Karmic kernel and the Jaunty kernel would also be useful. I'm guessing that your older drives are using IDE, and there is some kind of problem with the IDE driver that simply wasn't caught during testing, since it's been a number of years since computers have been sold with IDE, and so it's less likely that Ubuntu testers would have caught that problem.

As far as ext4 is concerned, it's out of beta as far as I'm concerned, and for desktop use it should be quite stable. There are some specific ext4 features which are in beta, but they aren't enabled by default. (More on one of them in a bit.) The "failed to set superblock flags" is an error that is normally caused by a corrupted journal file. My apologies for not looking at this sooner but the original bug report got lost in my inbox. If you still have the corrupted disk, I can probably help you recover it, but I'm guessing you've since reformatted the disk. If it's any comfort (and I doubt it will be), the exact same thing could have just as easily happened with ext3. The journal checksum feature is still in beta (and so it's not enabled by default), and that might have been able to detect the corrupted journal transaction and skip it, minimizing the damage.

Best regards,

-- Ted

[imperia (imperia777)]

Hello,

I've had power loss on my linux router. After I booted i've received the following error message:

fsck.ext3: unable to set superblock flags on /dev/hda9

Here is what I have tried so far:

mke2fs -n /dev/hda9
fsck.ext3 -b <superblock> /dev/hda9 (i tried all superblocks from mke2fs output)

the error message always is the same:

Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
fsck.ext3: unable to set superblock flags on /dev/hda9

I got this error on 3 of my partitions hda6 7 and 9.

Data is intact on all of them. Just this error message I am unable to fix.

Please help to fix this.
Thanks in advance,
Julian

[Stéphane Gourichon (stephane-gourichon-lpad)]

Had the same problem as imperia777 : data intact, error message and unable to fix it, (though no actual power failure).

Here's fsck output:

e2fsck 1.42.9 (4-Feb-2014)
myfsname: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway? yes

fsck.ext4: unable to set superblock flags on myfsname

Final verdict was: defective storage.
Data was transferred to a new storage medium with a new filesystem.
Problem solved.

As additional check, we made a copy from the defective medium to another and observed that fsck could run flawlessly on the sane medium.

Looks like fsck is extra cautious and checks if every operations indeed happened, which allowed it to spot the trouble.

Anyway, to say it again: "fsck.ext4: unable to set superblock flags on myfsname" meant (at least in my case): change your storage medium.
Thank you for your attention.