I tried 3 different USB readers as well as discovering that the built in card reader works just fine under Linux. I was hard pressed to keep it working for more than a few hours under windows, so had forgotten it was there!

Yes dmesg does seem to show it is functional upon insertion and reading.
I am now trying to reliably run a fsck on it under linux, I do not seem to have all the tools that are suggested on the web.

[1257191.630039] mmc0: new high speed SDHC card at address 59b4
[1257191.630340] mmcblk0: mmc0:59b4 00000 7.35 GiB 
[1257191.649111]  mmcblk0: p1
[1257192.028782] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

So the card is actually assigned to /dev/mmcblk0 then? I presumed it was in a card reader or something.

Did you try using dd and/or wipefs on /dev/mmcblk0? Use dmesg to confirm the block device after inserting the card and before attempting to wipe it.

I am still curious to know why they have failed. None of them have the "usbc" string scattered in the partition table, so it is not that, some Linux users have had failure upon either suspend or resume from suspend, but most of those saw the usbc string.

... but I still do not unerstand why I cannot force a full redo of the mbr and partitions. I think I am sending commands to do that, gparted reports that it has not failed. But the card is not cleared down ...

May be, the card has reached "end of life"? At this point the internal controller (inside the card) goes to "read-only" (this has nothing to do with any kind of mechanical switch on side of the card) and may be, he gives no information back about doing so. So the underlying operation-system oder any kind of software (like GParted) thinks, everything is fine and you'll get no errors here.

Best Regards, FM_81

This is the dmesg output:

[1257191.630039] mmc0: new high speed SDHC card at address 59b4
[1257191.630340] mmcblk0: mmc0:59b4 00000 7.35 GiB 
[1257191.649111]  mmcblk0: p1
[1257192.028782] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

At this stage I know I cannot trust the data on there, but I still do not unerstand why I cannot force a full redo of the mbr and partitions. I think I am sending commands to do that, gparted reports that it has not failed. But the card is not cleared down, I feel I need to understand this better otherwise I would just let it go and throw the cards away.
But before I come to that point I would like to understand what is and is not happening under the hood.

The dmesg dump is quite large, how much of it is needed? last 20 lines? last 50 or 100?

Remove the SD card then open a terminal and run this command (as root):

dmesg -w

Then insert the SD card and only post any new output that appears in the terminal after you insert the card.

The dmesg dump is quite large, how much of it is needed? last 20 lines? last 50 or 100?

I now have a handle on which bits of other kit seem to be functional, when it was 5 faulty and 1 good sd card I could not be sure where the fault lay.

and please provide dmesg and fdisk output as already requested.. probably crap cards/adapters/driver, but without logs, noone can tell for sure.

rolfie, not a miracle (who believes in miracles anyway?). if you read my previous comment, i had similar experience without windoze.
another kingston micro sd still works fine, so i just sent samsung one to recycle bin.. but yes, gparted/dd/utilities and/or sd card and/or adapter and/or driver is buggy. no miracle involved whatsover.

Part of the problem may be that they were partitioned on Windows, but gparted is supposed to be able to cope.

I have tried dd, gparted and wipefs:

lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0   1.8T  0 disk 
├─sda1        8:1    0  23.3G  0 part /
├─sda2        8:2    0     1K  0 part 
├─sda5        8:5    0   9.3G  0 part /var
├─sda6        8:6    0   976M  0 part [SWAP]
├─sda7        8:7    0  18.6G  0 part /tmp
└─sda8        8:8    0   1.8T  0 part /home
sdb           8:16   0 931.5G  0 disk 
├─sdb1        8:17   0   128M  0 part 
└─sdb2        8:18   0 931.4G  0 part /data
sdd           8:48   1   7.4G  0 disk 
└─sdd1        8:49   1   7.3G  0 part 
sr0          11:0    1  1024M  0 rom  
mmcblk0     179:0    0   7.4G  0 disk 
└─mmcblk0p1 179:1    0   7.3G  0 part 
mike:~$ sudo wipefs --all --backup /dev/sdd
wipefs: error: /dev/sdd: probing initialization failed: Device or resource busy
mike:~$ sudo wipefs --all --backup /dev/sdd
/dev/sdd: 2 bytes were erased at offset 0x000001fe (dos): 55 aa
/dev/sdd: calling ioctl to re-read partition table: Success
mike:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0   1.8T  0 disk 
├─sda1        8:1    0  23.3G  0 part /
├─sda2        8:2    0     1K  0 part 
├─sda5        8:5    0   9.3G  0 part /var
├─sda6        8:6    0   976M  0 part [SWAP]
├─sda7        8:7    0  18.6G  0 part /tmp
└─sda8        8:8    0   1.8T  0 part /home
sdb           8:16   0 931.5G  0 disk 
├─sdb1        8:17   0   128M  0 part 
└─sdb2        8:18   0 931.4G  0 part /data
sdd           8:48   1   7.4G  0 disk 
└─sdd1        8:49   1   7.3G  0 part 
sr0          11:0    1  1024M  0 rom  
mmcblk0     179:0    0   7.4G  0 disk 
└─mmcblk0p1 179:1    0   7.3G  0 part 

So is read the blocks, sdd is the one I want to clear, I run wipefs, and it still reports a partition and gparted then also reports a fat32 partition on it, am I missing something?

But (in my opinion) wipefs is a very powerfool tool and --backup gives the user a false sense of security by presenting a remedy/insurance of sorts to not having been thorough enough.

But it's not a "false" sense of security because the remedy actually works.

Why are you not providing the requested fdisk and dmesg output? Is this a wind-up? It's certainly winding me up...

Anyway good luck. I'm out.

Well, after the "Apply" has finished gparted re-reads the partitioning information for all the devices that are available. If then the same structures are presented for the SD card, then obviously the write operation wasn't successful. I would claim that gparted works quite well. And I would conclude that the involved HW isn't working correctly. If gparted displays that the SD card now is empty, then that is the information that came back from the HW.

What exactly means:

This would be some sort of miracle. Maybe SD card and reader are not compatible, or some sort of buffer is involved, or the SD cards are simply crap.

You seem to have tried dd also, also with no result.

If you sum up all these bits and bytes, what do you think about cards and reader?

rolfie

The bit I have a problem with is that gparted tells me it had success in deleting the partition, when it clearly didnt, if I unplug and then plug it in again, I can read the files straight away, no windows involved. Gparted ought to be looking deeper into whether the files are gone. I agree it was MS that started the mess with straying from the original standard. Since then the software ought to be able to look at both mbr tables as well as both partition tables and at least warn you in advance that things are not straightforward.

I have successfully used gparted quite a lot at home and at work, but this batch of sd cards is giving me problems, it might have been the cheap no-name card reader I had at the time of creating them? it could be the usb funnies that people have noted with the string usbc plastered into the mbr and partition tables.

When plugging in the SD card reader and the card itself: inspect dmesg for hints if the device is write protected.

To gparted: I am using gparted for many years and never had it fail. I started of with gparted life versions, still use them every now and then.

There may be a trap for the unexperienced user: you can prepare a lot of operations, but these are not executed on the real HW before you don't tick the apply button. Are you aware of this?

In addition I suggest to tick the Device Information box in the View menu. Gives you confirmation that you are working on the right device.

If that does not work the card may be defective.

rolfie

MS software is and has been for the longest time notorious for not adhering to established standards/rules.
To MS, if it works with their software and the drivers hardware OEMs write for their OSs, it is good enough.

The web is full of examples, the most annoying one being all the horribly written BIOSs Linux OSs have had to deal with for ages.
As long any crap ridden BIOS worked with a MS OS, it was Windows XX Certified.

Obviously, it was not an issue if it did not work with any other OS.
eg: a Linux based OS.

All PCs were/are still sold with a MS OS, whether you want/ed it or not, so what problem could there possibly be?

I doubt that gparted is lying to you.
It does not have a will of its own.  8^D

What is most probably happening is that the data gparted is reading from the drive does not conform to the established standard.
ie: whatever the MS software wrote on the drive is not written in such a way that gparted can understand it correctly.

Like they say: rubbish in, rubbish out.

Best,

A.