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 journalSuperblock needs_recovery flag is clear, but journal has data.Run journal anyway<y>? noClear journal<y>? noe2fsck: unable to set superblock flags on /dev/sdc2Here 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). I 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 journalClearing 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)A subsequent 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 deletedkernel: EXT4-fs (sdc2): recovery completeSince 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.
fsck won't fsck (unable to set superblock flags)
ext4;fsck;sd card