arox Posted October 21, 2016 Posted October 21, 2016 My Samsung EVO 16 Gb SD card is dead. But in place of reporting errors, becoming inaccessible or anything, it just refuse to update content without reporting error. So I was able to flash an install image for my nanopi, verify that it contained a fs with an armbian distribution (because it was the previous content) and try to boot/install. I lost a huge amount of time to understand what was wrong : I tried to boot and FA neo board with a BPIm2+ uboot and kernel. I don't even know is the board has survived ...
tkaiser Posted October 21, 2016 Posted October 21, 2016 So I was able to flash an install image for my nanopi, verify that it contained a fs with an armbian distribution (because it was the previous content) and try to boot/install. That's the reason I switched over to Etcher completely: Since here a verify is mandatory which will save you huge amounts of time (the SD reader in my build host PC died a few months ago, took me 2 days to get the idea, in between an USB card reader was responsible for several failure burns so now I simply rely on Etcher and my MacBook's internal card reader -- also way faster). Maybe you got a counterfeit card and already exceeded the real capacity (you described the typical symptoms). Did you run F3 or H2testw already? 3
arox Posted October 21, 2016 Author Posted October 21, 2016 Maybe you got a counterfeit card That is of course the first question I asked myself. Nevertheless, the card was purchased at a reliable supplier and anyway there is no way at my disposal to check that. The fact is that I have over 30 years experience in system but was not prepared to face such a stupid problem : hardware pretending doing the job but not doing anything. I suspected the image, the fs options and the card reader before the card itself when I noticed that files created on fs disappeared after unmount/remount ! Anyway, I will now check /etc/os-release after flashing a card ... 1
tkaiser Posted October 21, 2016 Posted October 21, 2016 there is no way at my disposal to check that. Huh? Step 1) ALWAYS immediately check an SD card directly after purchase. It's easy. Just do it. Step 2) ALWAYS do a verify after burning an OS image to flash media. ALWAYS. Again: http://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card Checking single files won't help. I had strange symptoms (boot failures not always but often and later instabilities) when burning OS images with an USB SD card reader and bs=10M -- switching to bs=1M helped but I lost so much time that I simply said to myself: C'mon, don't be an idiot any more. Use Etcher instead since everytime you try to save time skipping thea verify you loose so much more time hunting bugs that are simply the result of a broken burning process. BTW: Regarding counterfeit SD cards there is no such thing like a 'reliable supplier' since fakes are sometimes inserted into supply chain pretty early. A re-seller gets 100 cards and 5 to 10 are fake. That's why step 1) above is that important. BTW 2: A verify as it's done by Etcher after burning an OS images also doesn't help when you got a counterfeit card. What most people don't understand is that the filesystem layout above the card's block/page management (the so called Flash Translation Layer FTL) is 100 percent abstracted. The only way to detect a fake or broken card is to completely overwrite it with known data patters and verify them at least once. 1
arox Posted October 21, 2016 Author Posted October 21, 2016 Huh? Step 1) ALWAYS immediately check an SD card directly after purchase. It's easy. Just do it. Step 2) ALWAYS do a verify after burning an OS image to flash media. ALWAYS. Again: http://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card Checking single files won't help. I had strange symptoms (boot failures not always but often and later instabilities) when burning OS images with an USB SD card reader and bs=10M -- switching to bs=1M helped but I lost so much time that I simply said to myself: C'mon, don't be an idiot any more. Use Etcher instead since everytime you try to save time skipping thea verify you loose so much more time hunting bugs that are simply the result of a broken burning process. BTW: Regarding counterfeit SD cards there is no such thing like a 'reliable supplier' since fakes are sometimes inserted into supply chain pretty early. A re-seller gets 100 cards and 5 to 10 are fake. That's why step 1) above is that important. BTW 2: A verify as it's done by Etcher after burning an OS images also doesn't help when you got a counterfeit card. What most people don't understand is that the filesystem layout above the card's block/page management (the so called Flash Translation Layer FTL) is 100 percent abstracted. The only way to detect a fake or broken card is to completely overwrite it with known data patters and verify them at least once. Well, you know the problem : we always are inpatients ! We should at least reread the number of block written and compare to image ... The fact is that I use a cheap usb stick to access cards and it takes much time to read/write images (I am also reluctant to use big capacity cards because it takes too much time). I haven't detected problems while using it to install bpiM2+ (although it might explain strange things). Nevertheless I don't keep track of what I use every SD card for (and cards are too tiny to be put a sticker). And now, the card is in such a state that I cannot create a new partition, alter an fs after mounting but it never reports a failure. Is that the symptom of exceeded capacity or worn out card ? Anyway, once you know that it might happen, it is very easy to check. I will be more careful from now ...
tkaiser Posted October 21, 2016 Posted October 21, 2016 And now, the card is in such a state that I cannot create a new partition, alter an fs after mounting but it never reports a failure. Is that the symptom of exceeded capacity or worn out card ? That's at least the symptom of a card reporting a capacity too high (fake/counterfeit card). The card's FTL has not the slightest idea about filesystems or partitions or anything else happening at the layers above (only possible exception: If the card would support DISCARD/TRIM and the block device driver also sends DISCARD calls to the FTL). That means for the card's controller it's simply new data that arrives (it's always new since overwriting doesn't happen, in case a sector (logical) should change its contents the affected pages will be marked as 'to be erased' and the changed data will be written to a new page (or more pages in case sector size is larger than page size). As part of the garbage collection then a background task on the card's controller will collect pages to erasable blocks and delete them to be available as new pages where stuff can be written to). So in case your card is just 4 GB in reality but the controller fakes 16 GB then the problems occur after 4 GB of data has been (over)written to the card since the controller happily accepts new writes but they'll never arrive in flash cells. Only way to fight this: ALWAYS immediately check an SD card directly after purchase. It's easy. Just do it. 1
Tido Posted October 21, 2016 Posted October 21, 2016 USB SD card reader and bs=10M -- switching to bs=1M helped but I lost so much time I always use bs=1M, how many seconds do you save by using bs=10M - in average an image has 2GB ?
nz1 Posted October 21, 2016 Posted October 21, 2016 I think etcher catches errors writing to the card while dd(on osx) will continue without reporting anything. Thats been my experience with two sdcards. Does anyone else notice that the etcher progress bar will make huge forward jumps and then seem to pause for a while? dd piped via pv just seems to write at a steady pace. My current guess is that etcher is communicating with the sdcard using some sort of flash api while dd possibly treats flash as just another cdrom that does not return write errors. I have skim read through some etcher programmer comments and they say something like they are using new code and not using dd code. They also say that dd has bugs.
arox Posted October 21, 2016 Author Posted October 21, 2016 My Samsung EVO 16 Gb SD card is dead. But in place of reporting errors, becoming inaccessible or anything, it just refuse to update content without reporting error. So I was able to flash an install image for my nanopi, verify that it contained a fs with an armbian distribution (because it was the previous content) and try to boot/install. I lost a huge amount of time to understand what was wrong : I tried to boot and FA neo board with a BPIm2+ uboot and kernel. I don't even know is the board has survived ... Well the board survived ... I am know trying to survive to debian and systemd : a mistake in /etc/network/interfaces and the system hang at boot ... 1
tkaiser Posted October 22, 2016 Posted October 22, 2016 I think etcher catches errors writing to the card Exactly and that's the reason I will only recommend Etcher from now on. It's absurd to waste time on 'bug reports' all the time that are caused by broken burning processes or SD cards. As soon as other burning tools implement a mandatory verify after burning I'm open for other suggestions again. 1
Ford Prefect Posted January 31, 2017 Posted January 31, 2017 Hi Although I agree with all that was said here I have something to say against Etcher: It install itself easily under Wxp without even asking for a location. But it doesn't work Moving it's huge directory on a NAS and running it with W10 64 bits without any installation seems OK.
Recommended Posts