linux-ext4 - e2fsck 1.39 bug report

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20061003004044.22788.qmail@science.horizon.com>
Date:	2 Oct 2006 20:40:44 -0400
From:	linux@...izon.com
To:	linux-ext4@...r.kernel.org
Subject: e2fsck 1.39 bug report

Yes, an actual bug.  e2fsck 1.39, taken from Debian binary e2fsprogs_1.39-1.

I had a drive eat itself in a new and interesting way, which corrupted the
first batch of inodes on the disk, leading to losing the root directry
and much gnashing of teeth.  All of the top-level directories ended up
attached under /lost+found.

(I'm a little mystified HOW this happened in the first place, given
that the system has mirrored drives, ext3 journaling, and ECC RAM, but
I neglected to have the logs go to a separate machine, so the history
of what happened after the hard drive started erroring is murky.
I suspect it wrote data to the wrong place.)

Anyway, after some ext2fs runs, I got a clean file system.  Before
starting on the nasty work of piecing together the system from what got
dumped in lost+found and the last backup, I ran e2fsck one more time
(with -f) just to be sure, and got a dozen of these:

Pass 2: Checking directory structure
Entry '..' in /lost+found/#4563658/1148529338.15087.science/usr/src/linux-2.6/ipc/.sem.o.cmd (1203943) has an incorrect filetype (was 1, should be 2)
Fix<y>? yes
Entry '..' in /lost+found/#4563658/1148490363.19043.science (4563661) has an incorrect filetype (was 1, should be 2)
Fix<y>? yes
Entry '..' in /lost+found/#4563658 (4563658) has an incorrect filetype (was 1, should be 2)
Fix<y>?

Note that the maildir file (with all the numbers) and .sem.o.cmd were both
originally files before this mess, but they got turned into directories.

I should have thought to e2image the file system before attempting
repair, but I didn't realize how bad it was going to be before I got
into it; sorry.

Not too big a deal, but I think a file system is not supposed to be marked
clean while containing detectable errors.

Two e2fsck feature requests:
1) A way to save a log of actions to a file.  If I can mount a tmpfs somewhere, or
   reformat a swap partition, I can use the list to see what needs to be restored from
   backup.
2) A way to say, in response to an interactive prompt, "yes, and fix all
   future problems of this type as well."  I'm quite happy to skip over
   dtime, and free block count problems, but I'd like to examine inodes
   getting cleared a little more carefully.
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html