I have been trying to create an SDcard to use with an Raspberry Pi. The card is created using the rpi-imager program on Fedora (41) and that program reports the creation as successful. Later, after mounting the ext4 partition on the card under Fedora and doing two or three minutes of exploration, I encounter a bad block. So I unmount the partition and use e2fsck to locate any bad blocks and mark them:
e2fsck -y -c /dev/sdb2
But after that when I try to remount the partition, it seems that e2fsck has destroyed the filesystem!
# 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.
Checking dmesg, I see that the mount has tried several possible filesystem types without success, including several lines like, "EXT4-fs (sdb2): VFS: Can't find ext4 filesystem". Explicitly adding "-t ext4" to the mount does not help.
I've repeated this process, again getting success, including verification, from rpi-imager. This time I omitted the -c from the e2fsck command and was able to mount the partition after.
So it appears that asking e2fsck to check for and mark bad blocks causes it to destroy the superblock(s). Is there another explanation?
On 3/13/25 4:47 PM, Dave Close wrote:
I have been trying to create an SDcard to use with an Raspberry Pi. The card is created using the rpi-imager program on Fedora (41) and that program reports the creation as successful. Later, after mounting the ext4 partition on the card under Fedora and doing two or three minutes of exploration, I encounter a bad block. So I unmount the partition and use e2fsck to locate any bad blocks and mark them:
e2fsck -y -c /dev/sdb2
Is there any output? Maybe don't use the `-y` option for now.
On Thu, Mar 13, 2025 at 7:48 PM Dave Close dave@compata.com wrote:
I have been trying to create an SDcard to use with an Raspberry Pi. The card is created using the rpi-imager program on Fedora (41) and that program reports the creation as successful. Later, after mounting the ext4 partition on the card under Fedora and doing two or three minutes of exploration, I encounter a bad block. So I unmount the partition and use e2fsck to locate any bad blocks and mark them:
e2fsck -y -c /dev/sdb2
But after that when I try to remount the partition, it seems that e2fsck has destroyed the filesystem!
# 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.
Checking dmesg, I see that the mount has tried several possible filesystem types without success, including several lines like, "EXT4-fs (sdb2): VFS: Can't find ext4 filesystem". Explicitly adding "-t ext4" to the mount does not help.
I've repeated this process, again getting success, including verification, from rpi-imager. This time I omitted the -c from the e2fsck command and was able to mount the partition after.
So it appears that asking e2fsck to check for and mark bad blocks causes it to destroy the superblock(s). Is there another explanation?
Throw the old SDcard away, and use a new one. The old SDcard is clapped out.
I used to do a lot of testing of C and C++ libraries on ARM SBCs, like BeagleBoards, BananaPi's, Raspberry Pi's and WandBoards. The low resources (like 512 MB or 1 GB or RAM) and C++ compiler ensured I needed a swap file to build the libraries. I used to go through SDcards like they were dirty underwear. Once I started seeing filesystem errors I threw away the old card and used a new card with the board.
Jeff
I wrote:
I have been trying to create an SDcard to use with an Raspberry Pi. The card is created using the rpi-imager program on Fedora (41) and that program reports the creation as successful. Later, after mounting the ext4 partition on the card under Fedora and doing two or three minutes of exploration, I encounter a bad block. So I unmount the partition and use e2fsck to locate any bad blocks and mark them:
e2fsck -y -c /dev/sdb2
Samuel Sieb replied:
Is there any output? Maybe don't use the `-y` option for now.
The only output was a statement that no bad blocks were found.
Jeffrey Walton replied:
Throw the old SDcard away, and use a new one.
I intend to. But this isn't a problem with the card.
On Thu, Mar 13, 2025 at 8:29 PM Dave Close dave@compata.com wrote:
I wrote:
I have been trying to create an SDcard to use with an Raspberry Pi. The card is created using the rpi-imager program on Fedora (41) and that program reports the creation as successful. Later, after mounting the ext4 partition on the card under Fedora and doing two or three minutes of exploration, I encounter a bad block. So I unmount the partition and use e2fsck to locate any bad blocks and mark them:
e2fsck -y -c /dev/sdb2
[...] Jeffrey Walton replied:
Throw the old SDcard away, and use a new one.
I intend to. But this isn't a problem with the card.
It sure sounds like it (to me):
> Later, after mounting the ext4 partition on the card under Fedora and > doing two or three minutes of exploration, I encounter a bad block.
Jeff
On Thu, 2025-03-13 at 16:47 -0700, Dave Close wrote:
I have been trying to create an SDcard to use with an Raspberry Pi. The card is created using the rpi-imager program on Fedora (41) and that program reports the creation as successful. Later, after mounting the ext4 partition on the card under Fedora and doing two or three minutes of exploration, I encounter a bad block. So I unmount the partition and use e2fsck to locate any bad blocks and mark them:
e2fsck -y -c /dev/sdb2
But after that when I try to remount the partition, it seems that e2fsck has destroyed the filesystem!
If it failed during write, your e2fsck is just removing the bad sectors not magically repairing what ought to be there. You can only repair a filesystem if you can read failing data and replace it with undamaged data. And it sounds like the failures are in important places if that's happening.
You could have a cascading failure (not just static errors, but increasing ones). Some cards can self-repair, so you mightn't notice problems until the failures become severe, and external repair attempts could fight with internal ones.
A failing card is unreliable, it's not worth the grief.
I wrote:
Jeffrey Walton replied:
Throw the old SDcard away, and use a new one.
I intend to. But this isn't a problem with the card.
Samuel Sieb answered:
Are you sure? It does sound likely. e2fsck doesn't write without warning. I suggest testing it with the f3 tools.
"e2fsck -c" said it didn't find any bad blocks. If it didn't find any, why would it modify the card at all? "e2fsck -y" (by itself) did not report any problem.
I agree the card seems flaky and I've already ordered a replacement. But I remain concerned by the result of using -c; that doesn't seem related to the problems with the card since it claims not to have found any bad blocks.
On 3/13/25 10:05 PM, Dave Close wrote:
I wrote:
Jeffrey Walton replied:
Throw the old SDcard away, and use a new one.
I intend to. But this isn't a problem with the card.
Samuel Sieb answered:
Are you sure? It does sound likely. e2fsck doesn't write without warning. I suggest testing it with the f3 tools.
"e2fsck -c" said it didn't find any bad blocks. If it didn't find any, why would it modify the card at all? "e2fsck -y" (by itself) did not report any problem.
That's what I'm saying. It wouldn't have modified it at all.
I agree the card seems flaky and I've already ordered a replacement. But I remain concerned by the result of using -c; that doesn't seem related to the problems with the card since it claims not to have found any bad blocks.
Have you used this card before? Are you sure it's actually as large as it says it is? That's why I'm suggesting you test it with f3.
On Thu, 2025-03-13 at 22:05 -0700, Dave Close wrote:
"e2fsck -c" said it didn't find any bad blocks. If it didn't find any, why would it modify the card at all? "e2fsck -y" (by itself) did not report any problem.
Perhaps it didn't. If the card was failing, a read operation could be enough to trigger another failure. It wouldn't matter what was doing the read.
On 3/14/2025 6:34 AM, Tim via users wrote:
On Thu, 2025-03-13 at 22:05 -0700, Dave Close wrote:
"e2fsck -c" said it didn't find any bad blocks. If it didn't find any, why would it modify the card at all? "e2fsck -y" (by itself) did not report any problem.
Perhaps it didn't. If the card was failing, a read operation could be enough to trigger another failure. It wouldn't matter what was doing the read.
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?
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.
On Mar 15, 2025, at 07:26, Dave Close dave@compata.com wrote:
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.
Perhaps it isn’t the media but the SD card reader?
It could be that the device is going offline due to some hardware problem. Have you checked dmesg? While the badblocks operation is read-only, it does produce a lot of I/O operations on a new filesystem.
If the problem is fsck corrupting disks, that seems like a pretty major problem and you should file a bug.
On Fri, 2025-03-14 at 22:14 -0700, Dave Close 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.
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.
Reputable supplier for the card? (Even then, forgeries have gotten into normal supply chains, from time to time).
Failing card slot?
Failing card reader?
I would have first tried writing to the card with something other than what was used with the last problem, just to remove it from the equation.
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.
On Thu, 2025-03-13 at 16:47 -0700, Dave Close wrote:
Later, after mounting the ext4 partition on the card under Fedora and doing two or three minutes of exploration, I encounter a bad block. So I unmount the partition and use e2fsck to locate any bad blocks and mark them:
e2fsck -y -c /dev/sdb2
But after that when I try to remount the partition, it seems that e2fsck has destroyed the filesystem!
Gonna ask the obvious question, since I haven't noticed it get brought up:
Are you sure you have the file system you think you have?
-
Dave Close -
Jeffrey Walton -
Jonathan Billings -
Roger Heflin -
Ron Flory -
Samuel Sieb -
Tim