Ron Flory wrote:
> I have a lot of experience with bad/flaky USB/SDCards- often they seem
>just fine as the onboard controller conceals signs of creeping-death,
>until they suddenly take a nose-dive.
>
> I'm not sure about your case, but each time I run "e2fsck -v -c -y
>/dev/sde1" (note -v Verbose switch), the summary always reports "*****
>FILE SYSTEM WAS MODIFIED *****". So the filesystem IS being modified,
>but the media still mounts successfully in my case.
>
> Do you see the same issue if you try other SDCards or USB
>FlashDrives? Any difference if you format the media as plain ext2 vs
>ext4 FS? Any difference if you use "e2fsck -cc" (Write+Read/Verify)
>test? As asked earlier, does running f3probe, f3write, f3read produce
>anything interesting?
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.
I'm not directly formatting the card, rpi-imager does that, so choosing a
different filesystem is not reasonable. I am confident that the card has
the advertised capacity; SanDisk is not a fly-by-night vendor.
The e2fsck %done and elapsed time numbers did increment during the process
but were evidently reset on completion before I copied the output. That's
a different issue, not terribly important, but annoying.
--
Dave Close, Compata, Irvine CA +1 714 434 7359
dave@xxxxxxxxxxx dhclose@xxxxxxxxxxxxxxxxxx
"Arguing that you don't care about the right to privacy because you have
nothing to hide is no different than saying you don't care about free
speech because you have nothing to say." -- Edward Snowden
--
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
