GParted on my Ubuntu machine reported:
dumpe2fs: Corrupt extent header while reading journal super block
Unable to read the contents of this file system!
Because of this some operations may be unavailable.
The cause might be a missing software package.
That machine has e2fsprogs 1.45.5 installed, so the missing software should not be the cause.
Thanks for the suggestion.
Last night I ran e2fsck on the SD card and tried to switch to other (backup) superblocks. None of those worked.
Then I ran badblocks -swv on the volume and it reported a lot of bad blocks.
I then formatted the SD card on a Windows 10 machine to extFAT and that finished almost instantly without reporting any issues. (Which probably means that Windows does not do a thorough check.) So that made me slightly insecure about sending the card back to the retailer because they probably only understand Windows/OSX error messages.
Now I know I should reasonably expect the card to work with ext4 and the SD card is probably malfunctioning. I will give it one more go with f2fs and if that fails I will send the card back to the shop to trade it with a new one.
Thank you for the help so far.
This sounds like something wrong with the card. Maybe try testing it: https://www.tecmint.com/check-linux-hard-disk-bad-sectors-bad-blocks/
When it comes to SD cards, f3 (especially f3probe) will likely be a better tool for the job: https://fight-flash-fraud.readthedocs.io/en/latest/introduction.html
I’m using a 256GB card on my Librem 5 formatted with ext4 with no issues.
Thanks, I was actually thinking of this but didn’t know any software. How does it perform detection? Write pseudorandom data and then compare?
I think it’s doing various things since it’s able to detect and report several types of fraudulent cards, but I don’t know the details (it even guesses internal cache size, so the method seems pretty involved). I’m always testing any new cards with it and found a few counterfeit ones; it was able to “fix” some of them to work at least with the (severely lower than advertised) actual capacity, so I didn’t have to instantly throw them away 
In short, before any formatting (outside of Windows10), of your SDXC card, please try this one, should help (I guess):
Afterwards just go back to GParted (if not used something within CLI).
EDIT: Of course you’ll need to create new partition table, and new partition(s), before any chosen formatting of this brand new partition(s). And also, sorry that I forgot what is not self-explanatory, please sudo umount /dev/sdb1, when SDXC card inserted within Librem 5 / before executing above command.
Interesting suggestion. f3read is still running on the (F2FS-formatted) volume, but the output is kind of bleak. I guess that at this stage I expect that the SD card is completely currupted since badblocks already reported a lot of bad blocks. I will return it to the shop.
# f3read /media/hank/eccdf37e-a863-44c3-b3a4-57b020dd7eab/
F3 read 7.2
Copyright © 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.
SECTORS ok/corrupted/changed/overwritten
Validating file 1.h2w … 1483/ 2095669/ 0/ 0
Validating file 2.h2w … 0/ 2097152/ 0/ 0
Validating file 3.h2w … 0/ 2097152/ 0/ 0
Validating file 4.h2w … 0/ 2097152/ 0/ 0
The most interesting tool from that suite is f3probe, it usually can quickly identify the exact type of fraudulent card and tell you the actual usable capacity that’s available there.
Many thanks for your advice! And although f3probe never used from my side (but will be ASAP), I’m already sure that it is indeed very welcomed tool (for when needed purpose): “Different from f3write/f3read that works on the file system of the drive, f3probe works directly over the block device that controls the drive.”
Well, in accordance with this link, perhaps every SanDisk Extreme UHS-I 256GB 1st visible partition starts on 49152 sector (24MB) and therefore you’d likely need to achieve (before trying to change its original format type) following state of your microSDXC, as explained within linked article: “once that is finished the drive should be totally unallocated.”
Just by looking at one particular screenshot confirms above 24.00MB (File System: Other) description: https://www.iflash.xyz/wp-content/uploads/2014/03/Rebuild_MBR.jpg
P.S. Quality control of SanDisk products isn’t something that should be questioned here (although Extreme series of affordable price range).
According to f3probe the card is counterfeit of type limbo. Which means: The drive starts with one segment of good blocks and finishes with one segment of bad blocks. The vast majority of fake drives are of this type. If fake drives didn’t have internal caches, a single write to the last block would spot these drives.
# sudo f3probe --destructive --time-ops /dev/mmcblk0
F3 probe 7.2
Copyright © 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.
WARNING: Probing normally takes from a few seconds to 15 minutes, but
it can take longer. Please be patient.
Bad news: The device `/dev/mmcblk0’ is a counterfeit of type limbo
You can “fix” this device using the following command:
f3fix --last-sec=64768965 /dev/mmcblk0
Device geometry:
Usable size: 30.88 GB (64768966 blocks)
Announced size: 250.00 GB (524290048 blocks)
Module: 256.00 GB (2^38 Bytes)
Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
Physical block size: 512.00 Byte (2^9 Bytes)
Probe time: 1’55"
Operation: total time / count = avg time
Read: 579.7ms / 2197 = 263us
Write: 1’55" / 2241 = 51.3ms
Reset: 0us / 0 = 0us
I’d like to see here output of: sudo fdisk -l /dev/mmcblk0.
I just mailed the card back to the shop for reimbursement. So, sorry I can’t give you the fdisk output.
However, as f3probe is destructive it would have probably indicated that there no longer was a partition table on the card.
I don’t think that from the link you quoted we can conclude that the first partition should start on sector 499152. Anyway, that is something fdisk should advise you on when creating a new partition.
In my reading of your quoted article it merely erases the MBR, then creates a new partition table and ends with creating a new partition. This can be achieved by using free tools coming with PureOS:
Erase the MBR (Master Boot Record) and the partition table with dd:
dd if=/dev/zero of=/dev/xxx bs=512 count=1
Create a new partition table and new partition with fdisk or GParted
sudo fdisk -l /dev/mmcblk0Device Start End Sectors Size Type
/dev/mmcblk0p1 2048 34815 32768 16M unknown
/dev/mmcblk0p2 34816 61069278 61034463 29.1G unknown
from where I can conclude that there exist two partitions (1st one or 16M one is somehow “encrypted”, controlling 2nd one, made within/during needed initiation format inside of my Android based navigation device). On top of its gpt partition table.
sudo umount /dev/mmcblk0p1 −− note that there is no output/reaction.
sudo umount /dev/mmcblk0p2
umount: /dev/mmcblk0p2: not mounted.
sudo f3probe --destructive --time-ops /dev/mmcblk0
F3 probe 8.0
Copyright © 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.
WARNING: Probing normally takes from a few seconds to 15 minutes, but
it can take longer. Please be patient.
Good news: The device `/dev/mmcblk0’ is the real thing
Device geometry:
Usable size: 29.12 GB (61069312 blocks)
Announced size: 29.12 GB (61069312 blocks)
Module: 32.00 GB (2^35 Bytes)
Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
Physical block size: 512.00 Byte (2^9 Bytes)
Probe time: 1’43"
Operation: total time / count = avg time
Read: 566.2ms / 4815 = 117us
Write: 1’39" / 4192321 = 23us
Reset: 0us / 1 = 0us
My thought/question is did you umounted both partitions (as I suppose you are still having problematic 24M or so /dev/mmcblk0p1 over there), before proceeding to f3probe command? Did you executed sudo f3fix --last-sec=64768965 /dev/mmcblk0 command? Did you created a new empty DOS partition table, or GPT one?
If so, only sudo dd if=/dev/zero of=/dev/xxx bs=524288 count=1 would help with this particular microSDXC card (not the bs=512), when unmounted.
@hank, no this was just wrong conclusion of yours. Both partitions were still there (in accordance with my previous post), even after executing: sudo f3probe --destructive --time-ops /dev/mmcblk0.
Your output indicates a 32GB card. @hank’s card was supposed to be 256GB, but turned out to be just 32GB in reality. I’m not sure what you’re trying to achieve with further questions, f3probe output seems pretty conclusive to me.
Good catch, I see your question as valid (something to learn from), therefore expected, just expected that @hank removes that “in reality” /dev/mmcblk0p1 visible partition (related to output from Ubuntu post in this thread),
Anyway, f3probe looks like very helpful tool. Today I’ve used it for the very first time, just happened thanks to your recommendation.
While related output was based on lower F3 probe 7.2 version, probably obsolete if used with 256GB SDXC card. And while: “Without option –destructive, one would see a line “Probe finished, recovering blocks. . . Done” in the previous output to let the user know that f3probe has recovered all blocks in the drive to their original state.” or
“The problem with this approach is that drives are still getting bigger, and counterfeiters may, in the future, be able to profit with fake drives whose real capacity are large enough to fool these partial tests. This problem is not new.” or
“The option –destructive instructs f3probe to disregard the content of the drive to speed up the test.” or
“When a drive is not fake, f3probe writes about half of its size, or 2GB, whichever is smaller.” or
“You should not easily settle down for a fake drive, fight back and get your money back! Doing so will help you and others. If you are still reading this section, you already realized that you own a fake drive, and would like to be able to use it without losing data.”
as author explained here, containing other relevant points related (like f3probe /dev/mmcblk0) to this thread: https://fight-flash-fraud.readthedocs.io/_/downloads/en/stable/pdf/