Nick Posted March 10, 2016 Posted March 10, 2016 Does anyone else have to run testdisk regularly after writing Armbian images to SD cards? It may simply be that I've cycles through the 3 or 4 cards that I have here so many times now that they are all on their way out, but it certainly happens on more than 1 card. I've just tried the latest Git version and it's happens with both debootstrap and debootstrap-ng. I used dd in an ubuntu VM to write the SD cards using a USB SD card reader. Workflow: Build Armbian use dd to write image file to SD card Try SD card in *pi board, it fails with unsupported file system error EDIT: the actual error is "Failed to mount Ext2 filesystem" Insert SD card into USB reader and run testdisk, allow it to find the partition and re-write partition table Try SD card in *pi board again and everything boots perfectly. No more trouble until the next time I try and write an SD card. In the past I have seen the odd error regarding writing partition tables come out of the build system, but I don't see (or at least notice) it all of the time.
zador.blood.stained Posted March 10, 2016 Posted March 10, 2016 I had 3 prebuilt images in output/images (wheezy, jessie, trusty), just tested them with losetup. 1 of them (wheezy) resulted in this after partprobe: [ 384.054638] attempt to access beyond end of device [ 384.054649] loop0: rw=0, want=2578312, limit=2101248 [ 384.054663] attempt to access beyond end of device [ 384.054667] loop0: rw=0, want=2578312, limit=2101248 [ 384.054673] Buffer I/O error on dev loop0p1, logical block 322032, async page read other 2 are OK.
zador.blood.stained Posted March 10, 2016 Posted March 10, 2016 gdisk on this image file outputs this: Warning! Secondary partition table overlaps the last partition by 33 blocks! You will need to delete this partition or resize it in another utility. Edit: false alarm, this is due to gdisk converting MBR partition table to GPT.
Nick Posted March 10, 2016 Author Posted March 10, 2016 I'll do another build later with build logging turned on to see if I can capture the exact errors. It may be just my SD cards though they are a mix of Transcend and Kingston, so not the cheapest of cards. I was mostly wondering if anyone else had experienced something similar. I'll order some new cards as well soon and see if the problem goes away.
zador.blood.stained Posted March 10, 2016 Posted March 10, 2016 I would suggest testing images without writing them to SD cards with losetup and partprobe (to check if this is partition alignment error or something similar), and also checking at least 1 card with f3.
Nick Posted March 10, 2016 Author Posted March 10, 2016 Good point, I hadn't thought to test the image as well :-)
Nick Posted March 10, 2016 Author Posted March 10, 2016 I've just run testdisk on the .raw image file and then copied it to one of the SD cards that I've been using this evening. Same booting problem. No ext2 found. So I guess the problem is with my cards, the USB card reader or dd. I'm using bs=1M for dd could that be a problem? What is f3? I've not heard of that before.
zador.blood.stained Posted March 10, 2016 Posted March 10, 2016 Usually anything related to possible SD cards problems automatically summons @tkaiser here http://oss.digirati.com.br/f3/ I'm using bs=1M for dd could that be a problem? This shouldn't be a problem. By the way, what kernel and distribution are you testing? Are you experiencing error with one combination of OS release and kernel or with several different too? 1
Nick Posted March 10, 2016 Author Posted March 10, 2016 All of my builds at least for the last week of so have been built with the following ./compile.sh BUILD_DESKTOP=no RELEASE=jessie BRANCH=next PROGRESS_DISPLAY=plain PROGESS_LOG_TO_FILE=yes BOARD=bananapipro PROGRESS_DISPLAY=plain COMPRESS_OUTPUTIMAGE=no DEST_LANG=en_GB.UTF-8 EXTENDED_DEBOOTSTRAP=yes APT_PROXY_ADDR=nas-1.local I actually run a script that contains the above, so I know that it haven't changed due to typos etc. I'm playing with f3 now, I'll let you know how I get on
Nick Posted March 10, 2016 Author Posted March 10, 2016 F3 finally finished, here is the output sudo f3write /media/nick/a11ec933-f0e3-43bf-93bf-603f9e66ea49 Free space: 7.02 GB Creating file 1.fff ... OK! Creating file 2.fff ... OK! Creating file 3.fff ... OK! Creating file 4.fff ... OK! Creating file 5.fff ... OK! Creating file 6.fff ... OK! Creating file 7.fff ... OK! Creating file 8.fff ... OK! Free space: 16.00 MB Average writing speed: 3.87 MB/s nick@ubuntu-vm:~/hg/p158-linux-images$ sudo f3read /media/nick/a11ec933-f0e3-43bf-93bf-603f9e66ea49 [sudo] password for nick: SECTORS ok/corrupted/changed/overwritten Validating file 1.fff ... 2097152/ 0/ 0/ 0 Validating file 2.fff ... 2097152/ 0/ 0/ 0 Validating file 3.fff ... 2097152/ 0/ 0/ 0 Validating file 4.fff ... 2097152/ 0/ 0/ 0 Validating file 5.fff ... 2097152/ 0/ 0/ 0 Validating file 6.fff ... 2097152/ 0/ 0/ 0 Validating file 7.fff ... 2097152/ 0/ 0/ 0 Validating file 8.fff ... 14232/ 0/ 0/ 0 Data OK: 7.01 GB (14694296 sectors) Data LOST: 0.00 Byte (0 sectors) Corrupted: 0.00 Byte (0 sectors) Slightly changed: 0.00 Byte (0 sectors) Overwritten: 0.00 Byte (0 sectors) Average reading speed: 15.70 MB/s To me at least the output looks ok
zador.blood.stained Posted March 10, 2016 Posted March 10, 2016 Can you post full boot log when you get the error ( I.e. from serial console, though you will need to edit and recompile u-boot script prior to first boot).
Nick Posted March 10, 2016 Author Posted March 10, 2016 Yes sure, I'm looking at the apt-cacher issue at the moment, but the next time I have an image I'll post the output log. I'm guessing by changes you mean updating the kernels boot args to ttyS0,115200?
Nick Posted March 14, 2016 Author Posted March 14, 2016 Ok, I think I may have stumbled on the solution by accident last night, no surprises in that it looks like the cause was me being an idiot as usual... I use ctrl-r and bash's history alot and it would appear that sometimes I've been trying to write the .raw file to /dev/sdb1 instead of /dev/sdb. As expected the Pi fails to boot, my Kubuntu desktop can't mount the fs etc. etc. The interesting thing is that testdisk appears to be able to fix this up! I need to confirm all of this with a few more tests but if that's the case then not only problem solved, but also how awesome is testdisk!! 1
Jens Bauer Posted March 22, 2016 Posted March 22, 2016 I use ctrl-r and bash's history alot and it would appear that sometimes I've been trying to write the .raw file to /dev/sdb1 instead of /dev/sdb. As expected the Pi fails to boot, my Kubuntu desktop can't mount the fs etc. etc. FYI: Some cards (in particular, I'm thinking about Medion 32GB cards) do not allow writing to sector 0. You'd have to write to /dev/sda1 instead of /dev/sda in such cases (Sometimes it works for me, sometimes it doesn't; it seem to depend on the image; I haven't tried it with Armbian, though, as I've stopped using the 32GB card). Fortunately, this happened only on the 32GB cards; the 16GB cards work well for me. It's like the first sector(s) are protected somehow. SanDisk SD-formatter does not complain, when I use it for formatting any of the cards.
Recommended Posts