linux-ext4 - [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 Oct 2009 23:02:34 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards

http://bugzilla.kernel.org/show_bug.cgi?id=14354

--- Comment #69 from Brian Rogers <brian@...w.org>  2009-10-16 23:02:32 ---
I have an idea for anyone who gets this problem on a clean reboot. Do what it
takes to reproduce the problem, then quit to single-user mode (sudo telinit 1)
and try to remount root as read-only:

mount -o ro,remount /

If you can't do this because the filesystem is busy, look for and kill any
process that might have a file open for writing. Remounting as read-only does
not seem to be forcible, as the command appears to succeed, but you still have
write access. So it's a good idea to 'touch /blah' to make sure you've turned
off write access.

Plan A. If you've successfully remounted as read-only, run 'e2fsck -f' on your
filesystem. If you had no errors on the filesystem before, but you do now, you
know the errors were introduced during the session. If there are no errors on
this check and you never get the corruption on the next boot after doing this,
it's probably a problem with data not getting flushed by the time the system
reboots.

Plan B. If you can't remount as read-only and can't find a process responsible
for that to kill, run sync, then 'e2fsck -fn' on the partition and report the
results.

I just did a dist-upgrade on my desktop machine running Karmic and the standard
Karmic 2.6.31 kernel, and I was going to do the above before rebooting, but had
to resort to plan B because I couldn't remount / as read-only. Even after sync,
e2fsck warned that it was skipping journal recovery, and it reported errors.

Ted, is it to be expected that e2fsck would find a journal recovery necessary
and see errors even if the filesystem was still mounted rw, but had been synced
and no write access had taken place since the sync? I know no writing had taken
place because I could run sync after the drive had spun down, and it wouldn't
spin up again. Yet e2fsck continued to report the same result.

I did 'reboot -f' after this to avoid any script shenanigans and used
'init=/bin/bash' on the next boot so I could manually examine the situation.
When my root fs was been mounted read-only, it replayed the journal, then there
were no errors on 'e2fsck -f'.

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
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