Jordan messes up and rm -rf / instead of rm -rf /dev/sdb
XCalibur – the microSD in the stone
11–20 of 31 posts
Re: XCalibur – the microSD in the stone
#12I feel like there's some preface here that I'm missing.
Re: XCalibur – the microSD in the stone
#13Jordan messes up and rm -rf / instead of rm -rf /dev/sdb slapstick classic
Err, even 'rm -rf /dev/sdb' wouldn't do what they want...
Better to overwrite it completely with dd.
Re: XCalibur – the microSD in the stone
#14Of course, my stupidest hackathon project makes it to HN. Great.
Re: XCalibur – the microSD in the stone
#15Of course, my stupidest hackathon project makes it to HN. Great.
we out here!!!
Re: XCalibur – the microSD in the stone
#16Of course, my stupidest hackathon project makes it to HN. Great.
pontehbepr
Re: XCalibur – the microSD in the stone
#17Re: XCalibur – the microSD in the stone
#18Re: XCalibur – the microSD in the stone
#19Sounds hasty. There are so many layers between you and your SD card it is hard to know sometimes which ones are broken. Typically, if you can't use dd(1) to write to it, and the error dd(1) gives is not 'write protected media', then your card is essentially dead.
The interesting thing is that dd wouldn't even give us an error, but the write speeds were abysmal. Toward the end of the hackathon, we noticed that blocks would be corrupted here and there, while leaving other pieces of data (even entire MP3 files) intact.
I think we ended up pointing to issues with the SD card's bus as the most likely cause for the behavior we saw, but we weren't even certain about this.
Re: XCalibur – the microSD in the stone
#20Of course, my stupidest hackathon project makes it to HN. Great.
that night was the best 9 hours i wasted on something tbh