pfeerick

It looks like there may also be an issue with the fact that the battery has a dedicated battery protection circuit, which will isolate itself from the outside world until the undervoltage lockout has been lifted... and since the AXP can't see it... you get a chicken-egg situation happening. Same stupid situation as the TP5100 lipo charge boards with protection circuitry... it needs power before it works, but when you first connect it stays off, so you need to bypass that protection to 'arm' it (hence why all the 'buy-your-own-battery' powerbanks all have a reset pinhole/switch in order to power them on when you first insert the batteries). By rights, you can cheat if you didn't have a charger or variable power supply handy, and hook up a pair of AA batteries (i.e. 3v) to the lithium battery for 5-10 seconds, and that would have given it the (gentle) kick it needed to dis-arm the low-voltage cuttoff. Obviously you need to get the polarity right, otherwise you're going to really hope you used thin wires so you can feel them heat up or smoke if you get it back to front!

On the Xenial Ubuntu image, the following worked (thanks martinayotte, I just fleshed out your suggestion): sudo systemctl disable bluetooth.service sudo systemctl stop bluetooth.service You'll see if you run systemctl status bluetooth.service afterwards that it is no longer active. Might I ask exactly why you were wanting to disable it? I have a CT running as a media/data/intranet web server also, and can't say I ever bothered doing anything with the bluetooth, so just left it how it was as it didn't seem to be hurting anything (other some unnecessary RF and power drain, I'm sure!)

lol... indeed! Fair enough, as long as its supposed to do that. Just was just expecting the automatic reboot and resize and It didn't happen, so I was about to report that it didn't work... but then I rebooted and realised it had resized. 3 months... so probably 5.25? Makes sense, as I think my other installs were 5.24, and they just auto rebooted. Colour is probably my fault... xterm instead of xterm-256colorr... although the toilet fancy board name colours were present. Edit: yup, that was it... 256 colour triggered the banner and reboot warning colour... that was all white, but I didn't think anything of it as the board name was in colour.

When did that change? I remember my pine64 and cubietruck doing an automatic reboot after running up the microSD for the first time, and the general documentation for Armbian still says (under common features): Although, as you say, it did say it on the Orange Pi when it booted (as I re-imaged it again to check)... I just hadn't seen that before, and it didn't stand out as it wasn't a different colour or anything. Warning: a reboot is needed to finish resizing the filesystem Please reboot the system as soon as possible

Apologies if this is documented/reported somewhere else, but I can't see anything on a quick forum search. I received two Orange Pi Zeros this morning, and eagerly downloaded the Orange Pi Zero flavour of Armbian (Xenial Legacy) and loaded it up on a good 8GB microSD. I then started using it, updating it, and suddenly realised that it only had a 1.4GB partition when it failed to finish updating due to insufficient space. I thought since I'd had some issues logging into it that I might have interrupted the first boot resize, so I re-imaged it, and loaded it up, left if five minutes, and then logged. No cigar... says it is still 1.4GB (1.4GB size, 1.2GB used, 201MB free on /dev/mmcblk0p1). On a whim, I then rebooted it, and now it says /dev/mmcblk0p1 7.2G size 1.2G used 6.0G free... so does 5.25 on the orange pi zero resize the fs on the first REBOOT, not first boot? Or is this new behaviour across the board? And something else which I think may be related... the welcome banner updates message is indicating [ 5 updates to install: apt-get upgrade ], whereas I know if I run apt-get update and reboot that it will change to [ 5 updates to install: apt-get upgrade ]... actually, one even better yet, it still says five updates to install after the reboot, but when I run apt-get update it wants to update 49 packages... so the background update check doesn't appear to be happening or even updating properly. Coincidence, configured differently to my other boards running Armbian, broken, or am I just being impatient?

I had this exact same issue, but on an ubuntu image (Armbian 5.25, Ubuntu 16.04, pine64) and checked the service status of apache2, and saw the following two errors - sorry, ends were trimmed by SSH scrollback history (2)No such file or directory: AH02291: Cannot access directory '/var/log/apache2/' for main (2)No such file or directory: AH02291: Cannot access directory '/var/log/apache2/' for error I decided to take it on face value, and created the directory, and what do you know... it worked! This was fresh after installing a new (l)amp stack via sudo apt-get install lamp-server^ on a fresh pressed and updated Armbian image. Stupid apache2! sudo mkdir /var/log/apache2

I don't know if we're still (mis)using this thread for posting feedback, but here goes... will edit post as I do more images/boards/tests... I aim to hopefully run a quick test say every two weeks or as requested. Board Branch Boot Ethernet WiFi HDMI Install Image/Date Performed by ----------------------------------------------------------------------------------------------------------- pine64 (2GB) Legacy/Xenial Yes Yes N/T Yes Yes 5.24.161221 pfeerick pine64 (2GB) Mainline/Xenial Yes Yes N/T No Yes 5.24.161221 pfeerick pine64 (1GB) Legacy/Xenial Yes Yes Yes Yes Yes 5.24.161221 pfeerick pine64 (1GB) Mainline/Xenial Yes Yes N/S No Yes 5.24.161221 pfeerick N/T - not tested N/S - not supported I presume by install you mean that the first-run install experience ran successfully? Also, I was going to try armbianmonitor -u to see if anything useful was logged re: HDMI not working on the mainline (or is there NO support for even the terminal there??), but I was rewarded with a "503 Over Quota" html source dump message when I tried... I didn't break it... promise! Hope everyone is enjoying their Christmas...

Or perhaps a tab reorder... i.e. change it to Quick start, Server, Desktop, Remarks, Hardware Info, Nightly Releases, Kernels (as relevant to the release, naturally). The quick start page already mentions SD quality and power supply concerns... so maybe a minor expansion of that of say one sentence and/or links to the full treatment? Then you get hit by the quick start first, and then have to go to the server or desktop tab to actually see the links to those releases?

@Igor: Um.... I know what a "Server" is, but wwhat's a "Dexsktop"... ? Quick start looks nice... my question as Mr Dumb User (knowing there is more stuff around) is where is the link to the board specific documentation from the board download page now?

I can relate to this... when I first came across the Armbian project after jumping on the ARM bandwagon again after being a RPi and CubieTruck user... with the corresponding "don't know nothing about ARM on linux" level of understanding (which is slowly improving due to the pain64... er, pine64).... I had a WTF!! moment when faced with the legacy and vanilla options, and did exactly what tk said... i though vanilla must be the better option, and then very quickly went back and downloaded the legacy image when I realised it probably wasn't the best option! :-O So the change in wording to mainline, addition of 'desktop|server' text where relevant, and the extra notes guiding on whether the user should be downloading the legacy or mainline flavour is very much appreciated. I agree, the cubietruck page is better than the clearfog one.. I now have (finally!!) a 2GB pine64, so will get to trying out the latest beta image on both of my boards shortly....

I can help for the Pine64...