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
| ||
|
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.
Powered by blists - more mailing lists