L5 SDXC format problem

hank · November 26, 2021, 3:51pm

The SDXC card (SanDisk Extreme UHS-I 256GB) for my L5 is reporting issues after formatting to ext4 (mkfs.ext4 -F -O ^64bit -L ‘’ /dev/xxx)

Formatting the card on my Librem 14 with PureOS runs into the same issue.

Is this to be expected (ext4 is not the ideal filesystem for flash memory) or does it indicate that the card is broken?

The error:
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.

Inserting the card into the SD-card reader results in a message:
"Unable to access “SD Extreme 256B”
“Error mounting /dev/xxx at XXX: wrong fs type, bad option, bad superblock on /dev/xxx, missing codepage or helper program, or other error”

Whe3zy · November 26, 2021, 4:11pm

I can tell ya that its NOT to be expected as my 256GB card is formatted to Ext4 and functioning.

What result do you get if your try to format with Gparted?

hank · November 26, 2021, 4:12pm

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.

Whe3zy · November 26, 2021, 4:21pm

See if this gets you on track link

It should work the same for ext4 as 2 & 3

hank · November 26, 2021, 4:30pm

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.

dcz · November 26, 2021, 8:06pm

This sounds like something wrong with the card. Maybe try testing it: https://www.tecmint.com/check-linux-hard-disk-bad-sectors-bad-blocks/

dos · November 26, 2021, 10:22pm

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.

dcz · November 27, 2021, 12:48am

Thanks, I was actually thinking of this but didn’t know any software. How does it perform detection? Write pseudorandom data and then compare?

dos · November 27, 2021, 1:04am

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

Quarnero · November 27, 2021, 3:29am

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.

hank · November 27, 2021, 9:07pm

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.


              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

dos · November 28, 2021, 1:39am

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.

Quarnero · November 28, 2021, 7:52am

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.”

IMO, very user friendly manual as well.

Quarnero · November 28, 2021, 9:30am

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).

hank · November 28, 2021, 10:53am

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.


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

Quarnero · November 28, 2021, 11:13am

I’d like to see here output of: sudo fdisk -l /dev/mmcblk0.

hank · November 28, 2021, 11:50am

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

Quarnero · November 28, 2021, 12:46pm

Yet output from very same microSDXC card is here:
sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 29.12 GiB, 31267487744 bytes, 61069312 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F26B7E11-B0BF-4E35-9CC6-FFB3A04992BE

Device 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.

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.

Quarnero · November 28, 2021, 12:53pm

@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.

dos · November 28, 2021, 1:40pm

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.