linux-ext4 - [Bug 196677] fsck.ext4: unable to set superblock flags, even after mounting ok

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

Message-ID: <bug-196677-13602-AbeEpv0OUC@https.bugzilla.kernel.org/>
Date:   Fri, 18 Aug 2017 02:24:31 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 196677] fsck.ext4: unable to set superblock flags, even after
 mounting ok

https://bugzilla.kernel.org/show_bug.cgi?id=196677

Adam Nielsen (a.nielsen@...kadi.net) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Adam Nielsen (a.nielsen@...kadi.net) ---
Just to follow up on this, after performing a couple of troubleshooting steps
suggested by Ted, it became apparent that the SD card containing the ext4
filesystem has become read only.

Writes succeed without error, but the original data is always returned
unmodified.

For the benefit of anyone else finding their way here, I was able to verify the
problem by making a copy of the filesystem on another device and running fsck
on the copy, which succeeded.

To avoid needing a lot of disk space for the copy, I used e2image to copy the
metadata into a sparse file:

$ e2image -r /dev/sdb2 sdb2.e2i
e2image 1.43.4 (31-Jan-2017)

$ fsck.ext4 sdb2.e2i
e2fsck 1.43.4 (31-Jan-2017)
sdb2.e2i: recovering journal
Setting free inodes count to 902960 (was 903626)
Setting free blocks count to 2918014 (was 2920347)
sdb2.e2i: clean, 69984/972944 files, 967554/3885568 blocks

This only took 180MB of on-disk space instead of the full 15GB.

So the underlying cause of this bug is a hardware failure on the SD card.  It
appears to have gone into some sort of failsafe read-only mode, but
unfortunately it doesn't reject write operations, it just discards them.  This
means the host (and also the user, thanks to caching) does not realise there is
a problem unless, like fsck, a program does a verify-after-write and reveals
the issue.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.