SD cards fail to mount properly on my Pandora

[diligentcircle]

This is a problem I had in the past which just started happening to me again yesterday. I have no idea what triggers it or why it happens. But what happens is that the SD cards (though not necessarily all of them; it's inconsistent) don't get mounted to the proper place. Rather than going to e.g. /media/mmcblk1p1 or /media/sdname, they get mounted to... well, a location that can't be properly typed out. Here is a demonstration of what the mounted location ends up looking like in a terminal window:

$ cd ..enpandora:/media/�PNG
julie-openpandora:/media$ ls
apps  ram  ?PNG???
julie-openpandora:/media$

EDIT: You can't see it because it's being filtered out, but there's another character in front of the dollar sign (where commands are entered), which in the terminal was being rendered at almost the same location.

I wasn't satisfied with knowing that the name contained a carriage return somewhere and a couple of characters that aren't normal, so I opened up Python to find out exactly what the directory name is. What I came up with is "/media/\x89PNG\r\n\x1a". So, the location the SD card is being assigned is the character with the hexadecimal value 89 (137 in decimal), then "PNG", a carriage return character, a line feed character, and finally a "substitute" character.

This very strange name doesn't entirely prevent the SD card from being used. Thunar is still able to do some things, like copy files around. But a lot of functions fail to work properly, and almost every application is unable to use it, probably because of all the special characters that shouldn't be there.

This only ever happens on the Pandora, to be perfectly clear. No other system I have ever used these SD cards in has ever had this problem.

It also sometimes does and sometimes doesn't happen on the Pandora with some SD cards. Yesterday, when I removed the SD card containing PNDs and put it back in a bit later, it started having the same problem, but when I shut down the system and started it up again later, it correctly became available in "/media/apps" ("apps" is the name of this particular card).

Another problem that has occurred: that strange location in /media remains even after removing the SD card it was assigned to, and remains even after a reboot. I imagine that this, or something related to it, is why I can't mount a different SD card which seems to be recognized normally.

This is with SuperZaxxon 1.73 update 1. I previously had the same problem a year or two ago with whatever version of SuperZaxxon I had then, though.

Does anyone know what could be causing this, or what sort of tests to run to find out the cause? And does anyone know how to fix it?

 

[Swordfish II]

I have had this issue. For me it was a corrupted SD card, usually the partition table. Used Gparted on it to rebuild he table and it solved the issue with no data loss.

I found that torrenting is what corrupts mine every now and then

 

[diligentcircle]

I guess that could be the cause, though I didn't do anything crazy. Just moved the SD card to my laptop, copied some things to it, unmounted it, and then returned it to the Pandora. But I have had a experience in the past with this card that I think was probably data corruption, so I wouldn't be surprised if it happened again.

So why would data corruption that doesn't affect any other system's ability to use the card properly have such a tremendous effect on the Pandora? It seems there must be something these other systems are doing to compensate that the Pandora isn't.

Something else I forgot to mention: is it normal for there to be a directory called "ram" in /media? I notice that it's said to contain 4 MB, which is about the same as an amount of free space in the SD card that has the problem (located at the start, prior to the actual FAT partition). I'm unable to remove this directory even as root because "Device or resource is busy". (I was able to remove the one associated with the actual partition of the problem card, though, and that seems to have solved the problem of not being able to use other cards.)

I'm not satisfied with just accepting that the card got corrupted some point; I'd like to know the why, as in why it got corrupted and, more importantly, why the Pandora reacts to the corruption the way it does (at least, assuming it really is corrupted). So for now, I'll use a different SD card and leave the problem SD card as it is in the hope that I can learn what's up later. If anyone knows what to look for, please let me know.

 

[lukey]

If you reboot with the SD Card inserted, it should be automountet to /media/mmcblkXpX.

 

[HelenF]

The mount point comes from the label of the partition, so if that label gets an odd character in it, it can have that effect. (Though I don't know why it would still work sometimes.)

Do your other systems choose the mount point the same way as the Pandora? If they do, maybe they filter out characters that can cause problems in a filepath.

When I change the label on an existing FAT32 partition using the GParted PND, it always seems to mess it up, so I avoid that now. I don't need to do it often enough to remember the command-line way so have to look it up every time.

 

[diligentcircle]

The mount point comes from the label of the partition, so if that label gets an odd character in it, it can have that effect. (Though I don't know why it would still work sometimes.)

The SD card it happened with this time doesn't have a label. Also, even when a card does have a label, the location the card gets has nothing to do with it. I don't use "PNG" in any of my SD card labels, and certainly don't use a Windows-style newline character.

Do your other systems choose the mount point the same way as the Pandora? If they do, maybe they filter out characters that can cause problems in a filepath.

My current main system is Debian. Before that, it was Trisquel.

No other GNU/Linux system I have used mounts external storage drives quite the same as the Pandora, but they all use labels if they're available and some other string if there is no label. On my Debian system, the SD card that caused the problem this time is found at "/media/julie/F009-64A5" when mounted ("julie" is my username, and "F009-64A5" is some sort of identifying name that has been chosen for the partition since there's no label).

When I change the label on an existing FAT32 partition using the GParted PND, it always seems to mess it up, so I avoid that now. I don't need to do it often enough to remember the command-line way so have to look it up every time.

I didn't do any partitioning on this card recently. In between it working correctly and failing on SuperZaxxon, the only actions I took were to move the SD card between my laptop and the Pandora, and modify the files on it.

 

[HelenF]

I didn't mean you put special characters in the label on purpose, but I've had labels get the wrong things in them before. Maybe you checked already, but could see if there's anything there with e.g.

sudo lsblk -o name,label

"\x89PNG\r\n\x1a" seems to be the PNG file signature.
http://libpng.org/pub/png/spec/1.2/PNG-Rationale.html#R.PNG-file-signature

 

[diligentcircle]

I think you misread. The SD card it happened to this time has no label. So the label which does not exist is not the problem.

Changing the label on an SD card affected by this does not fix the problem. It was one of the first things I tried last time it happened; the presence or absence of a label, and the label's contents if present, makes no difference.

"\x89PNG\r\n\x1a" seems to be the PNG file signature.

Indeed. The question is why SuperZaxxon is using this particular sequence of characters as the directory name for the SD card. To be perfectly clear, this exact same sequence of characters has been the directory name assigned to every SD card I have had this problem with. It does not vary at all.