Following an unclean shutdown on an SD card based device, I took the SD card out to
fsck the root filesystem. This led to variations on the following:
e2fsck 1.43.1 (08-Jun-2016) /dev/sdc2: recovering journal Superblock needs_recovery flag is clear, but journal has data. Run journal anyway<y>? no Clear journal<y>? no e2fsck: unable to set superblock flags on /dev/sdc2
Here I've answered "no" both times but there is no sequence of yes/no that does not immediately lead to the same outcome.
The filesystem can be mounted and on casual inspection appears okay; it also works fine in the device, and that's the root filesystem (actually it turned out to be not quite fine, see comments; tldr some irretrievably corrupted directories).
dd'd the partition (8 GB) to a file, and tried fsck on that. Interestingly:
e2fsck 1.43.1 (08-Jun-2016) plush.rootfs: recovering journal Clearing orphaned inode 18290 (uid=0, gid=0, mode=0100644, size=34096) Clearing orphaned inode 18270 (uid=0, gid=0, mode=0100644, size=38916) Clearing orphaned inode 18250 (uid=0, gid=0, mode=0100644, size=1128076) Clearing orphaned inode 11411 (uid=0, gid=0, mode=0100644, size=293108) Setting free inodes count to 406127 (was 408580) Setting free blocks count to 1305622 (was 1347486) plush.rootfs: clean, 60209/466336 files, 604906/1910528 blocks (check after next mount)
fsck passed clean, the image can be mounted, and
fsck -f after that passes as well.
But the filesystem on the card from which the raw block copy image was created still has the same problem -- except that the
systemd-fsck which takes place during boot logs the filesystem as "clean". Subsequently though, a proper shutdown, taking the card out, and trying
fsck again from another box presents the same error.
Whenever the original is mounted on another machine, syslog notes:
kernel: EXT4-fs (sdc2): 4 orphan inodes deleted kernel: EXT4-fs (sdc2): recovery complete
Since I have it all backed up, I'm open to trying anything here. I could simply forget about this and reburn the partition from the apparently fixed image, but that does not seem like a very satisfactory solution, since it means assuming fsck cryptically failed at solving a minor looking problem.
I suspect this is going to turn into a "request for official documentation" question regarding stuff like needs recovery_flag (or just plain "What does this mean?" question), so any suggestions along those lines are appreciated.