PiCore v11 on a RasPi3 with 256GB Flash...

[CentralWare]

I have a few dozen Pi which we've used a labs down to "oooh, pretty lights!" (lol!) but until today no need to use an SDXC.
Samsung 256GB "EVO" microSD, tested in half a dozen different ways to make sure it wasn't a flaky chip, tried another for kicks, has an odd outcome when installing PiCore.


1. Using Etcher (and Imager 1.4 and just manually creating a 128MB partition and formatting FAT32 and copying over the PiCore files) the image is sent to the uSD card.
    Boots like expected.  onboot.lst is emptied so mmcblk0p2 is free to dismount.  Reboot.
2. Using FDisk, partition 2 is deleted and re-created to full capacity type 83 (used Parted, too - same results.)  Reboot (just for giggles!)
3. fdisk -l shows both partitions as expected, so I launch sudo mkfs.ext2 /dev/mmcblk0p2 and catch a few Z's - takes quite a while to format.
Upon completion, /dev/mmcblk0 is partitionless!!! Triple checked; we're not accidentally using /dev/mmcblk0 - it's entered properly.


Any clues to this mystery? EXT2 was chosen to limit unnecessary polling onto the uSD card, didn't try other formats.


Thanks!

[curaga]

Either a bug somewhere, or you have fake chinese cards. The chinese fakes use a smaller flash and report a bigger one, it wraps internally so later writes overwrite earlier ones. This camoflages it being fake for long enough the seller can disappear.

[CentralWare]

@curaga

     Is the fake flash thing still going on?  (I remember when that first hit the streets; people were all up in arms thinking ALL flash drives were bogus, but I didn't realize it was still a 'thing'.)

• I ran EXT3 on a 128GB flash; it seemed successful.  I have yet to format it as EXT2 and/or EXT3 on the 256's as I didn't want journals, but at least we have a reference point.
• I ran EXT2 on the original 256GB, it did act as though its internal mapping recycled, wiping out the partition tables when EXT does its itable init.  So... changed tactics!
• I'm running EXT2 with nodiscard and lazy_itable_init on another 256GB at the moment, This should prevent the "all zeros" format and see what's what, then I plan to DD dummy images to the flash storage to see where it fails (no drive space left), which "should" be ~256GB - if so, I'll repeat the process with the original 256 and see if it's got wrapping issues.  If these EXT2 formats all fail, I'll run the same with a couple 128's and 64's to see if maybe EXT2 itself might have a hidden problem under specific criteria.

Take care and have a great weekend!

[curaga]

The way the fakes work, you won't get "no space left". It just silently overwrites parts. You test them by writing unique data, as big as the drive, then read it all back and verify it matches.

If you expect a mke2fs bug with that exact size, repeat your steps on a file on your hd.
dd if=/dev/zero of=/mnt/sda1/myfile bs=1 count=....
# partition the file like you did your SD card
# mke2fs the partition (I don't remember the specifics to loop device partitions, but either that or "qemu -hda /mnt/sda1/myfile -cdrom Core-current.iso -m 256 -boot d" will work

[CentralWare]

Considering the fact I have a good number of these 128's and 256's to go through, your note regarding "no space left" may work to my advantage on a real machine as Pi/USB2... yeah, something that slow should be deemed road-kill! I have a few 7 port USB3 hubs and should be able to simultaneously fdisk, format (lazy/nodiscard) and using a 500GB hard drive, fill it with, say, 300GB of 1GB /dev/RANDOM files and clone the files onto the flash drives. Here's my plan of attack:

• If the fdisk/format fails, toss the chip into the research bin (and find the receipt!)
• If the 128 or 256 errors out (no space, for example) at less than 90% expected capacity, off to the bin
• If the 128 or 256 can hold more than 10% of expected capacity... the bin's getting fuller!
• For the remainder, for each file on the SD card, diff check against the file on the HDD, bin the failures.

Actually, that's not a bad plan for all the chips (SDHC) we got in with that batch... It's hard to believe E2 has an issue