Description of problem: This bug has been opened to backport the following patches to RHEL5 e2fsprogs from upstream e2fsprogs 1.42.4, as discussed in the bugzilla 'https://bugzilla.redhat.com/show_bug.cgi?id=850803' comment 16. a ) commit 63b3913dbc0bc7cdf8a63f3bdb0c8d7d605e9a40 Author: Theodore Ts'o <tytso> Date: Sun Jun 10 23:35:43 2012 -0400 e2fsck: correctly propagate error from journal to superblock If the file system is mounted read-only after a file system error has been detected, the fact that an error occurred is written to the journal. This is important because while the journal is getting replayed, the error indication in the superblock may very well get overwritten. Unfortunately, the code to propagate the error indication from the journal to superblock was broken because this was being done before the old file system handle is thrown away and the file system is re-opened to ensure that no stale data is in the file system handle. As a result, the error indication in the superblock was never written out. To fix this, we need to move the check if the journal's error indicator has been set after the file system has been freed and re-open. Reported-by: Ken Sumrall <ksumrall> Signed-off-by: "Theodore Ts'o" <tytso> b ) commit 6d75685e2b76f4099589ad33732cf59f279b5d65 Author: Theodore Ts'o <tytso> Date: Thu May 31 19:19:02 2012 -0400 e2fsck: handle an already recovered journal with a non-zero s_error field If a file system was remounted read-only after a file system corruption is detected, and then that file system is mounted and unmounted by the kernel, the journal would have been recovered, but the kernel currently leaves the s_errno field still set. This is arguably a bug, since it has already propgated the non-zero s_errno field to the file system superblock, where it will be retained until e2fsck has been run. However, e2fsck should handle this case for existing kernel by checking the journal superblock's s_errno field even if journal recovery is not required. Without this commit, e2fsck would not notice anything wrong with the file system, but a subsequent mount of the file system by the kernel would mark the file system's superblock as needing checking (since the journal's s_errno field would still be set), resulting an full e2fsck run at the next reboot, which would find nothing wrong --- and then when the file system was mounted, the whole cycle would repeat again. I had seen reports of this in the past, but it wasn't until recently that I realized exactly how this had come about, since normally e2fsck would be run automatically before the file system is mounted again, thus avoiding this problem. However, a user using a rescue CD who didn't run e2fsck before mounting the a file system in this condition could trigger this situation, and unfortunately, with previous versions of e2fsprogs and the kernel, there would be no way out no matter what the user tried to do. Signed-off-by: "Theodore Ts'o" <tytso>
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux.
Downloaded the test image from bug 850803 and tested against e2fsprogs-1.39-37.el5 and e2fsprogs-1.39-35.el5 -37.el5 stopped and required manual run of e2fsck [root@ibm-x3550m3-06 bz885073]# rpm -q e2fsprogs e2fsprogs-1.39-37.el5 [root@ibm-x3550m3-06 bz885073]# ls -l total 35467112 -rw-r--r-- 1 root root 18141413376 Jun 26 13:02 10-sda3.image -rw-r--r-- 1 root root 18141413376 Jun 26 13:16 test.img [root@ibm-x3550m3-06 bz885073]# e2fsck -p test.img /: recovering journal / contains a file system with errors, check forced. /: Deleted inode 2242805 has zero dtime. FIXED. /: Inodes that were part of a corrupted orphan linked list found. /: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options) -35.el5 didn't stop [root@ibm-x3550m3-06 bz885073]# e2fsck -p test.img /: recovering journal /: Clearing orphaned inode 2243137 (uid=27, gid=27, mode=0100600, size=0) /: Clearing orphaned inode 2242888 (uid=27, gid=27, mode=0100600, size=0) /: Clearing orphaned inode 2242810 (uid=27, gid=27, mode=0100600, size=0) /: Clearing orphaned inode 2242806 (uid=27, gid=27, mode=0100600, size=0) /: Clearing orphaned inode 2242805 (uid=27, gid=27, mode=0100600, size=0) /: clean, 562706/4404224 files, 3872808/4429056 blocks Set to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1222.html