Nick

I couldn't get apt-cacher-ng to work, however I reinstalled apt-cacher on the NAS drive and deleted all of it's cached *.deb files. This time Armbian downloaded everything and built just fine. Thank you very much for your help and patience. I'll go back to looking at the SD card now. One day I might even get around to testing NFS boot ;-)

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?

According to the access log for apt-cache netbase is reported as a hit There is the following in apt-cachers error log: Thu Mar 10 22:44:11 2016|192.168.1.79|--- /usr/sbin/apt-cacher: Usage error Thu Mar 10 22:54:40 2016|info [13443]: Got another status line. Redirected?: HTTP/1.1 200 OK Date: Thu, 10 Mar 2016 22:54:40 GMT Server: Apache Last-Modified: Sat, 23 Jan 2016 13:19:39 GMT ETag: "242fc-52a00301b10c0" Accept-Ranges: bytes Content-Length: 148220 Thu Mar 10 22:54:41 2016|info [13448]: Got another status line. Redirected?: HTTP/1.1 200 OK Date: Thu, 10 Mar 2016 22:54:41 GMT Server: Apache Last-Modified: Sat, 23 Jan 2016 13:31:23 GMT ETag: "945-52a005a1140c0" Accept-Ranges: bytes Content-Length: 2373 However I have no idea what it means or if it is relevant? Edit: I've just tried browsing : http://nas-1.local:3142/httpredir.debian.org/debian/pool/main/n/netbase/netbase_5.3_all.debwith chrome and it happily downloaded the file. The file was also parsed by the package manager so it doesn't appear to be corrupt. Edit 2: I've just upgraded apt-cacher on the NAS to apt-cacher-ng and things are now even worse... [ o.k. ] Using custom apt-cacher-ng address [ nas-1.local:3142 ] [ o.k. ] Installing base system [ Stage 1/2 ] I: Retrieving Release I: Retrieving Release.gpg E: Failed getting release signature file http://nas-1.local:3142/httpredir.debian.org/debian/dists/jessie/Release.gpg [ error ] ERROR in function create_rootfs_cache [ debootstrap-ng.sh:164 ] [ error ] Debootstrap base system first stage failed [ o.k. ] Process terminated [ error ] ERROR in function unmount_on_exit [ debootstrap-ng.sh:526 ] [ error ] debootstrap-ng was interrupted [ o.k. ] Process terminated Again, I've tried downloading Release.gpg via chrome and all was fine.

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

So you did haha, I really should start paying more attention Sadly the build failed Possibly my fault? Or maybe because the NAS drive is running apt-cache and not apt-cache-ng? I'll try it again incase it was just a glitch

Hi zador.blood.stained, Your new APT_PROXY_ADDR option appears to work well with apt-cache running on my NAS drive. It might be worth mentioning in the documentation that :3142 is needed as well though, as the first time I tried I just provided the URL without the port. Funnily enough it failed haha. Second time around with the addition of the port and it appears to be running as it should.

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

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.

Good point, I hadn't thought to test the image as well :-)

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.

Thank you very much zador.blood.stained, I'm in the process of trying bootstrap-ng atm (just about to boot it) to I'll test the new proxy address option in a minute or two.

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.

I'm certainly interested in testing that as from what I have read it would speed up my testing hugely and also help with production programming as the board will be able to be booted VIA FEL and write it's own SD card . That said, baby steps, I'll try bootstrap-ng tonight and then I'll probably be back asking for help with FEL boot and NFS ;-) The override to force the build to system to use the NAS drive would be great, I can then setup the Armbian image using customize-image as required.

At the moment I have a Netgear NAS drive which is powered up 24/7 it's name is nas-1.local and it is running apt-cacher (could be upgraded to apt-cacher-ng if needed). Ultimately it would be great if both the build system (which I do run in a VM) and the physical boards, OPi, Banana Pi etc. look at nas-1.local for packages. But this is for the future it may be that the physical boards look at the NAS drive and the build system maintains it's own private cache. That wouldn't be the worst situation in the world. Ah you should have said ;-) I have an OPi PC, Banana Pi M1+ and a Banana Pi M2 that I can test on when I get 5 minutes :-)

I'm not sure if it needs to be changed or not for the moment, possibly yes as it would be great if the target boards could talk to the same server. But for the moment I wouldn't worry as I'm just experimenting. I've not used debootstrap-ng before so it will be interesting to play with it. Are you planning on deprecating debootstrap in favour of debootstrap-ng in the future or will you be keeping both around?

Thanks Zador I'll look at that tonight, I'm guessing that debootstrap-ng installs a local apt-cacher-ng then? Or does it look for one on the network?

I have a really slow internet connection and I'm doing alot of re-building Armbian and target systems etc. I have a copy of apt-cacher running on a local machine, I know how to configure it on target machines but I'm not sure how I would point the Armbian build system at it? At a guess I'm thinking that I probably need to modify debootstrap to create /etc/apt/apt.conf.d/90-apt-proxy.conf but wondered if anyone had any better ideas?

Because it has Super Cow Powers... Try apt-get moo and see what happens. Slightly more seriously, I don't see any advantage to aptitude for general use. apt-get and apt-cache are extremely powerful and if you can't be bothered to type then the key commands such as install, remove search etc. are available from the shorter apt command. e.g. apt install mc

Hi Zador, That is what I do at the moment, I have scripts for each board that call compile.sh with the appropriate options. I then use customize-image.sh later on to make further changes. For the moment everything works perfectly for me. I was just a little concerned for the future by this:

That's great news Igor, thank you. I realise that my use case covers about 1% of users, so to a large extent I just have to go with the flow, but having the ability to easily script around the bits that I don't want / need is one the the things that I love about Armbian :-)

Will it be possible to automate the guided tour at build time? I'm doing alot of work with scripts that call compile.sh with particular options and customize-image.sh to ensure that I have to do as little as possible when the image is first run. In a production environment ideally you want everything to have been tied down ahead of time and certainly not having to answer the same questions for each and every board. Not only does this introduce a time penalty, but also greater chance of one (or more) boards being mis-configured.

Is git installed at that point? Bear in mind that customize-image.sh uses tools installed in the target image NOT the hosts tools. Unless Armbian is already installing git you will most likely need to do something like this: apt-get -y install git git clone https://github.com/blindpet/MediaServerInstaller /root/HTPCGuides

Hi, what board are you trying to use? Nick Edit: Sorry, I have just seen the Banana Pro bit on the first line of your post. Are you compiling Armbian from scratch or using one of the image files from the website?

60 / 70 MHz would allow you to measure the frequency but probably wouldn't give you much of a square wave as it's too close to the frequency being measured. I wouldn't trust a 70MHz scope to display much more than a 35/40MHz signal as the Nyquist frequency is Fsample / 2. That said, I didn't think to measure / calculate the frequency at all, I just saw the awful wave. Had I thought to measure it I probably would have noticed that it was 50MHz. Just for reference, I've changed the Max frequency in the DTB file to 5MHz and everything is working brilliantly now, thank you very much.

Ahh that's where spi_test is, I tried looking for it but ended up at a page (I think on kernel.org) that just had a nice explanation of it instead :-( I'll try those changes, thank you. My scope is only 70MHz so I doubt it was able to do much with a 50MHz signal. The chip that I'm trying to talk to certainly wouldn't handle it! Thanks for the tip, I'll let you know how I get on :-)