Re: [gentoo-user] SD memory card not erasing, even with dd.
William Kenworthy wrote: > ... >> This thread has been interesting tho. At least I know that a Sandisk >> card at least tries to fail in a way that I can get the data off that >> did get written to the card. Hey, that's a lot better than some I >> guess. :-D I've had some other brands that when they die, they dead. >> You get nothing at all. >> >> Dale >> >> :-) :-) >> > From memory (I found some articles describing what was happening when > investigating a while back) - its common with other brands too so > might be part of the specification - if it detects a failure, it > forces permanent read only mode to enable data recovery. Some cards > may be put back into write mode by software but not all and I wouldn't > trust it anyway. I have Kingston, Samsung and Sandisk cards - I > regard Samsung as very slightly better but not enough to go out of my > way and pay more for them. > > BillK > > > > I tend to buy Sandisk and Kingston as well. I'll add Samsung to my list tho. In the past, most have failed and I lose whatever was on the card. I think this is the first time one failed in this way. I guess it depends on how it fails tho. Dale :-) :-)
Re: [gentoo-user] SD memory card not erasing, even with dd.
... This thread has been interesting tho. At least I know that a Sandisk card at least tries to fail in a way that I can get the data off that did get written to the card. Hey, that's a lot better than some I guess. :-D I've had some other brands that when they die, they dead. You get nothing at all. Dale :-) :-) From memory (I found some articles describing what was happening when investigating a while back) - its common with other brands too so might be part of the specification - if it detects a failure, it forces permanent read only mode to enable data recovery. Some cards may be put back into write mode by software but not all and I wouldn't trust it anyway. I have Kingston, Samsung and Sandisk cards - I regard Samsung as very slightly better but not enough to go out of my way and pay more for them. BillK
Re: [gentoo-user] SD memory card not erasing, even with dd.
Mark Knecht wrote: > On Wed, Dec 29, 2021 at 12:15 PM Dale wrote: >> >> Those deer trail cameras are somewhat cheap, ish. Some of them don't >> even have a format option. I have a old camera that the IR sensor >> doesn't work on, it never knows something is there to take pictures of >> so it does nothing. Anyway, I use it to format cards with since most >> all trail cameras use the same format type and directory tree. One >> partition and vfat. Basically, it is really simple and not a lot of >> options. >> >> I use a card reader that hooks up via USB. It's one of those multi >> reader thingys. It's been a pretty good one but it isn't a real >> expensive one either. Given I got the data off and plan to trash it >> anyway, it's not worth recompiling a kernel, rebooting and then hoping >> it will have the right device thingys. >> >> This thread has been interesting tho. At least I know that a Sandisk >> card at least tries to fail in a way that I can get the data off that >> did get written to the card. Hey, that's a lot better than some I >> guess. :-D I've had some other brands that when they die, they dead. >> You get nothing at all. >> >> Dale >> >> :-) :-) >> > It's too bad that the little app I pointed you at doesn't work on your > setup. I'm going to look around for something more generic. > > Keep in mind that the 'failure', if that's what it is, could be in > your trail camera if it glitched and set the read only protection in > the card by accident, or possibly something happened in the USB > bridge. I think you'd possibly be better served in the long run by > sticking this SD in a plastic bag and saving it until we can find a > way to check it out more. Won't cost you anything to throw it away > next year. > > Happy New Year. Hope you get lots more fun trail camera pictures! > > Cheers, > Mark > > Yea, while I'm just curious, I was willing to try it if it would work. It could be that the camera did it but given the lack of features, I sort of doubt it. While some of my trail cameras have the format option, I don't think that one does. Anything is possible tho. It could have done it without intending to do it. I did have to do a complete reset a few days ago. It was acting a little weird. Reset seems to have fixed it. It runs off a 12 volt SLA battery and has been powered up for well over a year. It likely needed a reset anyway. lol I have six cameras out there. I also put out food stuff for the deer too. Range cubes, rice bran, mineral salt with other added minerals and vitamins and sometimes a old thing of lettuce or something. They come eat quite a lot especially at night. We have one deer that is only a 8 pointer but that thing is massive for this area. We guesstimate it weighs around 200 lbs. Could even be above that. A 175 lb deer is a big deer around here. Why it doesn't have a larger set of antlers, we have no idea because it should be at least a ten point if not a twelve. I guess he just doesn't have the right DNA. If you find something else, let me know. I'll hang on to the card for a while. I did put a big X on it with a marker tho. Dale :-) :-)
Re: [gentoo-user] SD memory card not erasing, even with dd.
On Wed, Dec 29, 2021 at 12:15 PM Dale wrote: > > Mark Knecht wrote: > > On Wed, Dec 29, 2021 at 10:14 AM Dale wrote: > >> Mark Knecht wrote: > >>> > So while rare, it's not just me. ;-) I've had cards fail by just plain > refusing not to mount at all, mounting read only and such. I've never > had one to fail like this tho. I guess if this was some sort of > sensitive files, I'd have to put it in a shredder or take a pair of > scissors to it. LOL > > I ordered 6 new cards as replacements. They came in yesterday. Like I > said, I wouldn't trust that card even if it started working again. So, > off to the trash the weird card goes. Now I just have to wonder why dd > and such didn't report problems. :/ > > Thanks to all for the info. Interesting. > > Dale > > :-) :-) > > >>> Actually, it's possible that it failed this way by design. What if the > >>> card recognized that it's in some sort of a wear out condition and > >>> just shut off new writes? One might see it as a failure but a > >>> different view is as a potential opportunity to retrieve data before > >>> it's gone. > >>> > >>> You might want to check out this tool: > >>> > >>> https://github.com/BertoldVdb/sdtool > >>> > >>> which advertises that it can view, set and reset the write protection > >>> status of an SD card. Can't hurt if you're committed to throwing the > >>> device in the trash can anyway. (Well, it could possibly hose your > >>> system if you use it incorrectly or if it has bugs, but that's true > >>> about all software, right?) ;-) > >>> > >>> But at least you could view the status of the card. > >>> > >>> Cheers, > >>> Mark > >>> > >>> > >> > >> I downloaded sdtool but I don't have the required devices in /dev to use > >> it. In the readme it says not to use /dev/sd* but to use /dev/mmcblk*. > >> It seems my card reader doesn't connect in a way for those to be > >> created. Would have been nice just to see what it does tho. I still > >> wouldn't trust it of course but being curious . . . . > >> > >> By the way, the card is a Sandisk which has a fairly good reputation. > >> It is possible that it failed in the best way it could. On the positive > >> side, it did fail in a way that the files could be recovered. That's > >> always a good thing. It's certainly better than failing with no way to > >> get the files. > >> > >> Dale > > OK, sorry it's not easy. I suppose now that you are using some sort of > > USB bridge for reading your SD cards? That probably makes it show up > > as a standard /dev/sd device like other USB drives. > > > > I may be wrong, and it might not help you, but I think /dev/mmc is > > enabled through the MMC_BLOCK option in the kernel, but even if you > > enable that it may not change things if you have a USB bridge in the > > way. > > > > On Windows there are some partition editors that show the state of > > these bits. I haven't looked for a standard Linux partition editor > > that does that but it's probably out there somewhere if you go > > hunting. > > > > If you own a DSLR that supports whatever size SD card you are using > > then it probably has a way to write protect cards while in the camera. > > However if it's just a web cam that you're using it probably doesn't > > but check the documentation. > > > > Good luck, > > Mark > > > > > > > Those deer trail cameras are somewhat cheap, ish. Some of them don't > even have a format option. I have a old camera that the IR sensor > doesn't work on, it never knows something is there to take pictures of > so it does nothing. Anyway, I use it to format cards with since most > all trail cameras use the same format type and directory tree. One > partition and vfat. Basically, it is really simple and not a lot of > options. > > I use a card reader that hooks up via USB. It's one of those multi > reader thingys. It's been a pretty good one but it isn't a real > expensive one either. Given I got the data off and plan to trash it > anyway, it's not worth recompiling a kernel, rebooting and then hoping > it will have the right device thingys. > > This thread has been interesting tho. At least I know that a Sandisk > card at least tries to fail in a way that I can get the data off that > did get written to the card. Hey, that's a lot better than some I > guess. :-D I've had some other brands that when they die, they dead. > You get nothing at all. > > Dale > > :-) :-) > It's too bad that the little app I pointed you at doesn't work on your setup. I'm going to look around for something more generic. Keep in mind that the 'failure', if that's what it is, could be in your trail camera if it glitched and set the read only protection in the card by accident, or possibly something happened in the USB bridge. I think you'd possibly be better served in the long run by sticking this SD in a plastic bag and saving it until we can find a way to check it out more.
Re: [gentoo-user] SD memory card not erasing, even with dd.
Mark Knecht wrote: > On Wed, Dec 29, 2021 at 10:14 AM Dale wrote: >> Mark Knecht wrote: >>> So while rare, it's not just me. ;-) I've had cards fail by just plain refusing not to mount at all, mounting read only and such. I've never had one to fail like this tho. I guess if this was some sort of sensitive files, I'd have to put it in a shredder or take a pair of scissors to it. LOL I ordered 6 new cards as replacements. They came in yesterday. Like I said, I wouldn't trust that card even if it started working again. So, off to the trash the weird card goes. Now I just have to wonder why dd and such didn't report problems. :/ Thanks to all for the info. Interesting. Dale :-) :-) >>> Actually, it's possible that it failed this way by design. What if the >>> card recognized that it's in some sort of a wear out condition and >>> just shut off new writes? One might see it as a failure but a >>> different view is as a potential opportunity to retrieve data before >>> it's gone. >>> >>> You might want to check out this tool: >>> >>> https://github.com/BertoldVdb/sdtool >>> >>> which advertises that it can view, set and reset the write protection >>> status of an SD card. Can't hurt if you're committed to throwing the >>> device in the trash can anyway. (Well, it could possibly hose your >>> system if you use it incorrectly or if it has bugs, but that's true >>> about all software, right?) ;-) >>> >>> But at least you could view the status of the card. >>> >>> Cheers, >>> Mark >>> >>> >> >> I downloaded sdtool but I don't have the required devices in /dev to use >> it. In the readme it says not to use /dev/sd* but to use /dev/mmcblk*. >> It seems my card reader doesn't connect in a way for those to be >> created. Would have been nice just to see what it does tho. I still >> wouldn't trust it of course but being curious . . . . >> >> By the way, the card is a Sandisk which has a fairly good reputation. >> It is possible that it failed in the best way it could. On the positive >> side, it did fail in a way that the files could be recovered. That's >> always a good thing. It's certainly better than failing with no way to >> get the files. >> >> Dale > OK, sorry it's not easy. I suppose now that you are using some sort of > USB bridge for reading your SD cards? That probably makes it show up > as a standard /dev/sd device like other USB drives. > > I may be wrong, and it might not help you, but I think /dev/mmc is > enabled through the MMC_BLOCK option in the kernel, but even if you > enable that it may not change things if you have a USB bridge in the > way. > > On Windows there are some partition editors that show the state of > these bits. I haven't looked for a standard Linux partition editor > that does that but it's probably out there somewhere if you go > hunting. > > If you own a DSLR that supports whatever size SD card you are using > then it probably has a way to write protect cards while in the camera. > However if it's just a web cam that you're using it probably doesn't > but check the documentation. > > Good luck, > Mark > > Those deer trail cameras are somewhat cheap, ish. Some of them don't even have a format option. I have a old camera that the IR sensor doesn't work on, it never knows something is there to take pictures of so it does nothing. Anyway, I use it to format cards with since most all trail cameras use the same format type and directory tree. One partition and vfat. Basically, it is really simple and not a lot of options. I use a card reader that hooks up via USB. It's one of those multi reader thingys. It's been a pretty good one but it isn't a real expensive one either. Given I got the data off and plan to trash it anyway, it's not worth recompiling a kernel, rebooting and then hoping it will have the right device thingys. This thread has been interesting tho. At least I know that a Sandisk card at least tries to fail in a way that I can get the data off that did get written to the card. Hey, that's a lot better than some I guess. :-D I've had some other brands that when they die, they dead. You get nothing at all. Dale :-) :-)
Re: [gentoo-user] SD memory card not erasing, even with dd.
On Wed, Dec 29, 2021 at 10:14 AM Dale wrote: > > Mark Knecht wrote: > > > >> > >> So while rare, it's not just me. ;-) I've had cards fail by just plain > >> refusing not to mount at all, mounting read only and such. I've never > >> had one to fail like this tho. I guess if this was some sort of > >> sensitive files, I'd have to put it in a shredder or take a pair of > >> scissors to it. LOL > >> > >> I ordered 6 new cards as replacements. They came in yesterday. Like I > >> said, I wouldn't trust that card even if it started working again. So, > >> off to the trash the weird card goes. Now I just have to wonder why dd > >> and such didn't report problems. :/ > >> > >> Thanks to all for the info. Interesting. > >> > >> Dale > >> > >> :-) :-) > >> > > Actually, it's possible that it failed this way by design. What if the > > card recognized that it's in some sort of a wear out condition and > > just shut off new writes? One might see it as a failure but a > > different view is as a potential opportunity to retrieve data before > > it's gone. > > > > You might want to check out this tool: > > > > https://github.com/BertoldVdb/sdtool > > > > which advertises that it can view, set and reset the write protection > > status of an SD card. Can't hurt if you're committed to throwing the > > device in the trash can anyway. (Well, it could possibly hose your > > system if you use it incorrectly or if it has bugs, but that's true > > about all software, right?) ;-) > > > > But at least you could view the status of the card. > > > > Cheers, > > Mark > > > > > > > I downloaded sdtool but I don't have the required devices in /dev to use > it. In the readme it says not to use /dev/sd* but to use /dev/mmcblk*. > It seems my card reader doesn't connect in a way for those to be > created. Would have been nice just to see what it does tho. I still > wouldn't trust it of course but being curious . . . . > > By the way, the card is a Sandisk which has a fairly good reputation. > It is possible that it failed in the best way it could. On the positive > side, it did fail in a way that the files could be recovered. That's > always a good thing. It's certainly better than failing with no way to > get the files. > > Dale OK, sorry it's not easy. I suppose now that you are using some sort of USB bridge for reading your SD cards? That probably makes it show up as a standard /dev/sd device like other USB drives. I may be wrong, and it might not help you, but I think /dev/mmc is enabled through the MMC_BLOCK option in the kernel, but even if you enable that it may not change things if you have a USB bridge in the way. On Windows there are some partition editors that show the state of these bits. I haven't looked for a standard Linux partition editor that does that but it's probably out there somewhere if you go hunting. If you own a DSLR that supports whatever size SD card you are using then it probably has a way to write protect cards while in the camera. However if it's just a web cam that you're using it probably doesn't but check the documentation. Good luck, Mark
Re: [gentoo-user] SD memory card not erasing, even with dd.
Mark Knecht wrote: > >> >> So while rare, it's not just me. ;-) I've had cards fail by just plain >> refusing not to mount at all, mounting read only and such. I've never >> had one to fail like this tho. I guess if this was some sort of >> sensitive files, I'd have to put it in a shredder or take a pair of >> scissors to it. LOL >> >> I ordered 6 new cards as replacements. They came in yesterday. Like I >> said, I wouldn't trust that card even if it started working again. So, >> off to the trash the weird card goes. Now I just have to wonder why dd >> and such didn't report problems. :/ >> >> Thanks to all for the info. Interesting. >> >> Dale >> >> :-) :-) >> > Actually, it's possible that it failed this way by design. What if the > card recognized that it's in some sort of a wear out condition and > just shut off new writes? One might see it as a failure but a > different view is as a potential opportunity to retrieve data before > it's gone. > > You might want to check out this tool: > > https://github.com/BertoldVdb/sdtool > > which advertises that it can view, set and reset the write protection > status of an SD card. Can't hurt if you're committed to throwing the > device in the trash can anyway. (Well, it could possibly hose your > system if you use it incorrectly or if it has bugs, but that's true > about all software, right?) ;-) > > But at least you could view the status of the card. > > Cheers, > Mark > > I downloaded sdtool but I don't have the required devices in /dev to use it. In the readme it says not to use /dev/sd* but to use /dev/mmcblk*. It seems my card reader doesn't connect in a way for those to be created. Would have been nice just to see what it does tho. I still wouldn't trust it of course but being curious . . . . By the way, the card is a Sandisk which has a fairly good reputation. It is possible that it failed in the best way it could. On the positive side, it did fail in a way that the files could be recovered. That's always a good thing. It's certainly better than failing with no way to get the files. Dale :-) :-)
Re: [gentoo-user] SD memory card not erasing, even with dd.
> > > So while rare, it's not just me. ;-) I've had cards fail by just plain > refusing not to mount at all, mounting read only and such. I've never > had one to fail like this tho. I guess if this was some sort of > sensitive files, I'd have to put it in a shredder or take a pair of > scissors to it. LOL > > I ordered 6 new cards as replacements. They came in yesterday. Like I > said, I wouldn't trust that card even if it started working again. So, > off to the trash the weird card goes. Now I just have to wonder why dd > and such didn't report problems. :/ > > Thanks to all for the info. Interesting. > > Dale > > :-) :-) > Actually, it's possible that it failed this way by design. What if the card recognized that it's in some sort of a wear out condition and just shut off new writes? One might see it as a failure but a different view is as a potential opportunity to retrieve data before it's gone. You might want to check out this tool: https://github.com/BertoldVdb/sdtool which advertises that it can view, set and reset the write protection status of an SD card. Can't hurt if you're committed to throwing the device in the trash can anyway. (Well, it could possibly hose your system if you use it incorrectly or if it has bugs, but that's true about all software, right?) ;-) But at least you could view the status of the card. Cheers, Mark
Re: [gentoo-user] SD memory card not erasing, even with dd.
William Kenworthy wrote: > > On 29/12/21 20:26, Michael wrote: >> On Tuesday, 28 December 2021 20:21:32 GMT Dale wrote: >>> Howdy, >>> >>> As some may recall, I have quite a few deer trail cameras that use SD >>> memory cards. On occasion some of the cards start acting weird. I've >>> got one that is really weird. Usually I just replace them but this one >>> is a bit of a puzzle I'd like to solve. When it stopped working, it >>> had >>> a dozen or so short videos on it that are about 30MBs on average. Some >>> color and large, some black and white night vision and fairly small. >>> When it stopped working, I tried to reformat the thing. The files >>> remained even after that. I then ran dd and zeroed the thing, files >>> still there even tho dd reported no problems. I then used this GUI >>> disk >>> program that tests memory cards and it claims the card is fine. It >>> writes files to it, reads them back. I also used it to reformat the >>> card. The original videos are still there. Today I decided to play >>> with it again. I ran this dd command on the stick. >>> >>> >>> root@fireball / # dd if=/dev/zero of=/dev/sdh bs=4K conv=notrunc >>> oflag=direct status=progress >>> 31907364864 bytes (32 GB, 30 GiB) copied, 3956 s, 8.1 MB/s >>> dd: error writing '/dev/sdh': No space left on device >>> 7791745+0 records in >>> 7791744+0 records out >>> 31914983424 bytes (32 GB, 30 GiB) copied, 3956.94 s, 8.1 MB/s >>> root@fireball / # >>> >>> >>> As you can see, no errors. It wrote zeros until it ran out of space. >>> Guess what, the original videos are still on the card. File listing: >>> >>> >>> root@fireball / # ls -al /run/media/dale/2140-2E00/DCIM/100MEDIA/* >>> -rw-r--r-- 1 dale users 0 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/.AAA >>> -rw-r--r-- 1 dale users 0 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/.BBB >>> -rw-r--r-- 1 dale users 14335272 May 2 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0823.AVI >>> -rw-r--r-- 1 dale users 50843576 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0824.AVI >>> -rw-r--r-- 1 dale users 53137560 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0825.AVI >>> -rw-r--r-- 1 dale users 18398504 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0826.AVI >>> -rw-r--r-- 1 dale users 18922808 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0827.AVI >>> -rw-r--r-- 1 dale users 18332888 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0828.AVI >>> -rw-r--r-- 1 dale users 18726200 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0829.AVI >>> -rw-r--r-- 1 dale users 18332920 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0830.AVI >>> -rw-r--r-- 1 dale users 18005288 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0831.AVI >>> -rw-r--r-- 1 dale users 17612088 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0832.AVI >>> -rw-r--r-- 1 dale users 17153336 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0833.AVI >>> -rw-r--r-- 1 dale users 16694584 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0834.AVI >>> -rw-r--r-- 1 dale users 0 May 6 2018 >>> /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0835.AVI >>> root@fireball / # >>> >>> >>> >>> The zero byte files are broken, my first clue way back that the card >>> needed replacing. I see no errors in dmesg or messages. Usually the >>> cards produce errors and it remounts read only. Not in this case tho. >>> Mount info: >>> >>> >>> root@fireball / # mount | grep sdh >>> /dev/sdh1 on /run/media/dale/2140-2E00 type vfat >>> (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=43 >>> >>> 7,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro, >>> >>> uhelper=udisks2) root@fireball / # >>> >>> >>> >>> In the past, I've at times been able to copy the files off other cards >>> going bad but it stays read only. Reformating fails etc etc. >>> Sometimes, it just plain doesn't work. Almost always tho I get a error >>> of some kind in messages or dmesg if not both. This one tho, it's just >>> plain weird. No errors but nothing removes the files either. Oh, I've >>> checked the lock button. It's not locked. It is shown that way in >>> dmesg as well. >>> >>> >>> [2592841.808336] sd 10:0:0:2: [sdh] Write Protect is off >>> >>> >>> >>> Obviously I'm not going to trust this thing. It will end up in the >>> trash but, does this make sense to anyone else? Of all the ones I've >>> worn out, this is the only one that behaves this way. I'd at least >>> expect the format to fail or it only mount read only. At least some >>> sort of error anyway. >>> >>> Thoughts? >>> >>> Dale >>> >>> :-) :-) >> I don't think I've come across something like this before. In my >> case data is >> lost, occasionally irretrievably. >> >> I suppose something has switched blocks on the SD as immutable, >>
Re: [gentoo-user] SD memory card not erasing, even with dd.
On 29/12/21 20:26, Michael wrote: On Tuesday, 28 December 2021 20:21:32 GMT Dale wrote: Howdy, As some may recall, I have quite a few deer trail cameras that use SD memory cards. On occasion some of the cards start acting weird. I've got one that is really weird. Usually I just replace them but this one is a bit of a puzzle I'd like to solve. When it stopped working, it had a dozen or so short videos on it that are about 30MBs on average. Some color and large, some black and white night vision and fairly small. When it stopped working, I tried to reformat the thing. The files remained even after that. I then ran dd and zeroed the thing, files still there even tho dd reported no problems. I then used this GUI disk program that tests memory cards and it claims the card is fine. It writes files to it, reads them back. I also used it to reformat the card. The original videos are still there. Today I decided to play with it again. I ran this dd command on the stick. root@fireball / # dd if=/dev/zero of=/dev/sdh bs=4K conv=notrunc oflag=direct status=progress 31907364864 bytes (32 GB, 30 GiB) copied, 3956 s, 8.1 MB/s dd: error writing '/dev/sdh': No space left on device 7791745+0 records in 7791744+0 records out 31914983424 bytes (32 GB, 30 GiB) copied, 3956.94 s, 8.1 MB/s root@fireball / # As you can see, no errors. It wrote zeros until it ran out of space. Guess what, the original videos are still on the card. File listing: root@fireball / # ls -al /run/media/dale/2140-2E00/DCIM/100MEDIA/* -rw-r--r-- 1 dale users0 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/.AAA -rw-r--r-- 1 dale users0 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/.BBB -rw-r--r-- 1 dale users 14335272 May 2 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0823.AVI -rw-r--r-- 1 dale users 50843576 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0824.AVI -rw-r--r-- 1 dale users 53137560 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0825.AVI -rw-r--r-- 1 dale users 18398504 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0826.AVI -rw-r--r-- 1 dale users 18922808 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0827.AVI -rw-r--r-- 1 dale users 18332888 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0828.AVI -rw-r--r-- 1 dale users 18726200 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0829.AVI -rw-r--r-- 1 dale users 18332920 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0830.AVI -rw-r--r-- 1 dale users 18005288 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0831.AVI -rw-r--r-- 1 dale users 17612088 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0832.AVI -rw-r--r-- 1 dale users 17153336 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0833.AVI -rw-r--r-- 1 dale users 16694584 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0834.AVI -rw-r--r-- 1 dale users0 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0835.AVI root@fireball / # The zero byte files are broken, my first clue way back that the card needed replacing. I see no errors in dmesg or messages. Usually the cards produce errors and it remounts read only. Not in this case tho. Mount info: root@fireball / # mount | grep sdh /dev/sdh1 on /run/media/dale/2140-2E00 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=43 7,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro, uhelper=udisks2) root@fireball / # In the past, I've at times been able to copy the files off other cards going bad but it stays read only. Reformating fails etc etc. Sometimes, it just plain doesn't work. Almost always tho I get a error of some kind in messages or dmesg if not both. This one tho, it's just plain weird. No errors but nothing removes the files either. Oh, I've checked the lock button. It's not locked. It is shown that way in dmesg as well. [2592841.808336] sd 10:0:0:2: [sdh] Write Protect is off Obviously I'm not going to trust this thing. It will end up in the trash but, does this make sense to anyone else? Of all the ones I've worn out, this is the only one that behaves this way. I'd at least expect the format to fail or it only mount read only. At least some sort of error anyway. Thoughts? Dale :-) :-) I don't think I've come across something like this before. In my case data is lost, occasionally irretrievably. I suppose something has switched blocks on the SD as immutable, probably a controller having a hiccup. You could try blkdiscard to erase blocks directly - but I haven't tried this on an SD. I also haven't tried to know if it will work at all hdparm's secure deletion. However, the best option is to see if the OEM offers a reset app for this particular card and use that. I have a few SD cards as OS disks on raspberry pi, odroids etc. One has your symptoms like yours - read only when it says its in write mode.
Re: [gentoo-user] SD memory card not erasing, even with dd.
On Tuesday, 28 December 2021 20:21:32 GMT Dale wrote: > Howdy, > > As some may recall, I have quite a few deer trail cameras that use SD > memory cards. On occasion some of the cards start acting weird. I've > got one that is really weird. Usually I just replace them but this one > is a bit of a puzzle I'd like to solve. When it stopped working, it had > a dozen or so short videos on it that are about 30MBs on average. Some > color and large, some black and white night vision and fairly small. > When it stopped working, I tried to reformat the thing. The files > remained even after that. I then ran dd and zeroed the thing, files > still there even tho dd reported no problems. I then used this GUI disk > program that tests memory cards and it claims the card is fine. It > writes files to it, reads them back. I also used it to reformat the > card. The original videos are still there. Today I decided to play > with it again. I ran this dd command on the stick. > > > root@fireball / # dd if=/dev/zero of=/dev/sdh bs=4K conv=notrunc > oflag=direct status=progress > 31907364864 bytes (32 GB, 30 GiB) copied, 3956 s, 8.1 MB/s > dd: error writing '/dev/sdh': No space left on device > 7791745+0 records in > 7791744+0 records out > 31914983424 bytes (32 GB, 30 GiB) copied, 3956.94 s, 8.1 MB/s > root@fireball / # > > > As you can see, no errors. It wrote zeros until it ran out of space. > Guess what, the original videos are still on the card. File listing: > > > root@fireball / # ls -al /run/media/dale/2140-2E00/DCIM/100MEDIA/* > -rw-r--r-- 1 dale users0 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/.AAA > -rw-r--r-- 1 dale users0 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/.BBB > -rw-r--r-- 1 dale users 14335272 May 2 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0823.AVI > -rw-r--r-- 1 dale users 50843576 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0824.AVI > -rw-r--r-- 1 dale users 53137560 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0825.AVI > -rw-r--r-- 1 dale users 18398504 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0826.AVI > -rw-r--r-- 1 dale users 18922808 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0827.AVI > -rw-r--r-- 1 dale users 18332888 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0828.AVI > -rw-r--r-- 1 dale users 18726200 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0829.AVI > -rw-r--r-- 1 dale users 18332920 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0830.AVI > -rw-r--r-- 1 dale users 18005288 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0831.AVI > -rw-r--r-- 1 dale users 17612088 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0832.AVI > -rw-r--r-- 1 dale users 17153336 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0833.AVI > -rw-r--r-- 1 dale users 16694584 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0834.AVI > -rw-r--r-- 1 dale users0 May 6 2018 > /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0835.AVI > root@fireball / # > > > > The zero byte files are broken, my first clue way back that the card > needed replacing. I see no errors in dmesg or messages. Usually the > cards produce errors and it remounts read only. Not in this case tho. > Mount info: > > > root@fireball / # mount | grep sdh > /dev/sdh1 on /run/media/dale/2140-2E00 type vfat > (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=43 > 7,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro, > uhelper=udisks2) root@fireball / # > > > > In the past, I've at times been able to copy the files off other cards > going bad but it stays read only. Reformating fails etc etc. > Sometimes, it just plain doesn't work. Almost always tho I get a error > of some kind in messages or dmesg if not both. This one tho, it's just > plain weird. No errors but nothing removes the files either. Oh, I've > checked the lock button. It's not locked. It is shown that way in > dmesg as well. > > > [2592841.808336] sd 10:0:0:2: [sdh] Write Protect is off > > > > Obviously I'm not going to trust this thing. It will end up in the > trash but, does this make sense to anyone else? Of all the ones I've > worn out, this is the only one that behaves this way. I'd at least > expect the format to fail or it only mount read only. At least some > sort of error anyway. > > Thoughts? > > Dale > > :-) :-) I don't think I've come across something like this before. In my case data is lost, occasionally irretrievably. I suppose something has switched blocks on the SD as immutable, probably a controller having a hiccup. You could try blkdiscard to erase blocks directly - but I haven't tried this on an SD. I also haven't tried to know if it will work at all hdparm's secure deletion. However, the best option is to see if the OEM offers a reset app for
[gentoo-user] SD memory card not erasing, even with dd.
Howdy, As some may recall, I have quite a few deer trail cameras that use SD memory cards. On occasion some of the cards start acting weird. I've got one that is really weird. Usually I just replace them but this one is a bit of a puzzle I'd like to solve. When it stopped working, it had a dozen or so short videos on it that are about 30MBs on average. Some color and large, some black and white night vision and fairly small. When it stopped working, I tried to reformat the thing. The files remained even after that. I then ran dd and zeroed the thing, files still there even tho dd reported no problems. I then used this GUI disk program that tests memory cards and it claims the card is fine. It writes files to it, reads them back. I also used it to reformat the card. The original videos are still there. Today I decided to play with it again. I ran this dd command on the stick. root@fireball / # dd if=/dev/zero of=/dev/sdh bs=4K conv=notrunc oflag=direct status=progress 31907364864 bytes (32 GB, 30 GiB) copied, 3956 s, 8.1 MB/s dd: error writing '/dev/sdh': No space left on device 7791745+0 records in 7791744+0 records out 31914983424 bytes (32 GB, 30 GiB) copied, 3956.94 s, 8.1 MB/s root@fireball / # As you can see, no errors. It wrote zeros until it ran out of space. Guess what, the original videos are still on the card. File listing: root@fireball / # ls -al /run/media/dale/2140-2E00/DCIM/100MEDIA/* -rw-r--r-- 1 dale users 0 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/.AAA -rw-r--r-- 1 dale users 0 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/.BBB -rw-r--r-- 1 dale users 14335272 May 2 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0823.AVI -rw-r--r-- 1 dale users 50843576 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0824.AVI -rw-r--r-- 1 dale users 53137560 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0825.AVI -rw-r--r-- 1 dale users 18398504 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0826.AVI -rw-r--r-- 1 dale users 18922808 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0827.AVI -rw-r--r-- 1 dale users 18332888 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0828.AVI -rw-r--r-- 1 dale users 18726200 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0829.AVI -rw-r--r-- 1 dale users 18332920 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0830.AVI -rw-r--r-- 1 dale users 18005288 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0831.AVI -rw-r--r-- 1 dale users 17612088 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0832.AVI -rw-r--r-- 1 dale users 17153336 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0833.AVI -rw-r--r-- 1 dale users 16694584 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0834.AVI -rw-r--r-- 1 dale users 0 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0835.AVI root@fireball / # The zero byte files are broken, my first clue way back that the card needed replacing. I see no errors in dmesg or messages. Usually the cards produce errors and it remounts read only. Not in this case tho. Mount info: root@fireball / # mount | grep sdh /dev/sdh1 on /run/media/dale/2140-2E00 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2) root@fireball / # In the past, I've at times been able to copy the files off other cards going bad but it stays read only. Reformating fails etc etc. Sometimes, it just plain doesn't work. Almost always tho I get a error of some kind in messages or dmesg if not both. This one tho, it's just plain weird. No errors but nothing removes the files either. Oh, I've checked the lock button. It's not locked. It is shown that way in dmesg as well. [2592841.808336] sd 10:0:0:2: [sdh] Write Protect is off Obviously I'm not going to trust this thing. It will end up in the trash but, does this make sense to anyone else? Of all the ones I've worn out, this is the only one that behaves this way. I'd at least expect the format to fail or it only mount read only. At least some sort of error anyway. Thoughts? Dale :-) :-)
