On Sat, Mar 15, 2025 at 6:26 AM Dave Close dave@compata.com wrote:
I received a new SanDisk "Extreme" 128 GB SD card today and used rpi- imager to put a new OS onto it. After completing successfully, I was able to mount the linux partition and make a backup copy onto a hard disk. But then...
# umount /mnt # e2fsck -c /dev/sdb2 e2fsck 1.47.1 (20-May-2024) rootfs: recovering journal Checking for bad blocks (read-only test): 0.00% done, 0:00 elapsed. (0/0/0 errdone rootfs: Updating bad block inode. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information rootfs: ***** FILE SYSTEM WAS MODIFIED ***** rootfs: 145349/332592 files (0.1% non-contiguous), 1130966/1330176 blocks # mount /dev/sdb2 /mnt mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error. dmesg(1) may have more information after failed mount system call.
So, again, "e2fsck -c" seems to destroy the superblock. In this case, I had no suspicion of any problem with the card; I only ran e2fsck to see if the same problem would occur. It did.
Did you verify that something did not remount it after you umounted it?
I have seen systemd "FIX" mounts and it "FIXES" them really fast.
I would have though fsck would have detected it being mounted and stopped you, but there may be cases were it does not.
And running fsck on a mounted fs does produce serious corruption.
Other thoughts: I think I saw a note that the ext2 module was removed (not sure when) and all ext fses would all use the ext2/3/4 driver. Maybe badblocks never worked in the newer driver.
You might check dmesg and see if it says anything about not supporting badblocks and that is the reason for the mount failure.