• Content Count

  • Joined

  • Last visited

Everything posted by pfeerick

  1. I was just looking at that again because of another post, and noticed that on line 66 $capacity is lowercase, and on line 73 it's uppercase ($CAPACITY)? Aren't shell script variables case sensitive? Thus making it so the 8GB condition never fires???
  2. This NOT an etcher bug. A small image is written to a big (micro)SD card, and it is then resized on the first reboot. Sometimes there is a automatic reboot, other times it is left up to you. I believe it is something to do with whether resize2fs can do an online resize or not on different kernels?? (you can see the test here in the resize2fs script). When you logged into the CT for the first time, it probably have had the red text shown on this screenshot (which obviously for a OrangePi Zero, but never mind...). As the text indicates, and as Igor said... reboot! If you manually
  3. Hey @tkaiser... just so you know... the final v1.0.0 of Etcher removes the CRC as a *feature* of their dynamic end page. :-/
  4. Yeah, that's what I'm hoping we can do. I listed the part number in the desc on flickr, but didn't have any luck finding the datasheet, so hoping either TL can provide it, or someone else has luck finding it. I was thinking about bypassing the protection circuit, but it obviously was needed as something went wrong and the AXP didn't kill the juice. So I'd prefer a temperamental battery to a dead battery. Hopefully they add a bypass button in the future so that you can simply pop the back cover (or poke a toothpick through a hole) and plug in the power, and it should then be good.
  5. 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 powe
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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?
  13. @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?
  14. 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 mainli
  15. And why? Do really think I should break the excellent example set forward by our illustrious leader Lord Marcus? Who is an expert at everything (even when he isn't?)... And I had to shudder at the mention of Win32DiskImager... really great choice there! Well, the documentation is getting better... the software released page now actually mentions the existence of Armbian... but I am now fighting the battle of direct links to images, rather than the appropriate project/download pages.
  16. That's yet another thing that's nice about the Orange Pi PC 2... they've managed to bring out a ~US $20 board and still managed to spring for a 16MB SPI FLASH. I can see the downsides of having SPI on board though... I mean, I just know that if tkaiser had his way and it had been on the pine64, instead of booting it would say 'You sucker... you went and bought a pine64 didn't you! Well, you deserve what you get... nothing!' and refuse to boot ;-P Seriously though, to have the bootloader and a basic diagnostic system on board with every new board made would be the best thing for all, as tka
  17. Looks like we already know @tkaisers new year resolution (since 1 January 2017 seems to be a key date! ) : To force all SBC vendors to: include a FEL button to program the eMMC (if present on board); include onboard SPI NOR flash to make the end user / boot experience more robust; and stop using shitty zillion partition android images Did I miss any? My only concern would be the liklihood of failure... as they're all good goals in my opinion I find it really funny the argument... er, discussion... around the SPI NOR flash... essentially saying we need to re-invent the wheel, and adop
  18. lol... oops! the pine64 forum... er... the whole shebang... is now offline... looks like the pinebook is getting a little too much interest... and TL said the IT guys were all over it! :-O "It's not just you! http://forum.pine64.orglooks down from here." @hojnikb... true, but if you were running it with wanting that sort of throughput... I'd be worried about the batteries being able to do much more than short-term UPS work... as they'd have to carry the load of the pine64 and the attached hard drives (unless using externally powered drives, at which point why bother having a battery o
  19. Don't know how they're doing it... I read that from their exceptionally detailed(!) product page... Wildo... re: test results... so why wouldn't it be better using a H5 be better than the pine64 since you could stack up three native USB ports instead of 2 (when the OTG port is switched)? And still do something with the 4th?
  20. I might look at the Olimex one instead... especially because it can run windows(kidding!!!)... or more importantly seems to have some more sensible resolutions... 1376x768 and 1920x1080. I suppose this one should be interesting... at least there won't be a GbE issue this time as they fixed it by removing the ethernet! :-P So was that the hardware problems fixed... just the minor detail of crappy software?
  21. I can second Broadcomm and Atheros - I have a Atheros chipset in an old laptop... and it is rock-solid in reliability under both Windows and 'nix. And my Broadcomm-chipset router has yet to give me reason. IIRC, I used 8192cu's also for my RPis, and haven't had any issues with them once they connected... but that could stem partly from the more reliable router. My previous (non-broadcomm chipset) wifi router was good, except whenever my (then new-beaut) Wifi 802.11N capapable laptop jointed the network... it b0rked the whole network. :-/
  22. It might work just fine with Armbian (I haven't tried it myself as I haven't run the desktop beta - my intended use for the pine was always headless server stuff - but I believe you anyway) - but it will NOT work with the debian images for the pine64 (without using external repos, etc) - and it has nothing to do with them being crappy either - it's the clash between Mozilla's distribution requirements and Debian policies that were fault there. Debian Jessie does not, and has never shipped with firefox in it's repo. Starting with Debian Stretch, it will be available, and in the meantime, the ex
  23. Thanks for that tkaiser.... Very much appreciated. It looks like there is a nice 70 odd minute video on youtube to go with that, so that will be some interesting reading/watching on the weekend. Just want to try and get my heard around the whole DTS stuff as my previous dealings were with fex and that was only rudimentary - strictly copy and paste to do something like disable the blinding blinking lights on the Cubietruck. Never went any further with that, and I see the RPi and other boards have moved the DTS way. I'll certainly be sticking with Armbian on the pine64 as my primary OS, and I ha
  24. Ssssh! You weren't supposed to tell everyone... now they'll all be doing it so they can use their crappy glow in the dark microUSB cables!!! :-P
  25. I think it was a conversion glitch - it was supposed to be 0x1C (dec 28).