pfeerick
-
Posts
148 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by pfeerick
-
-
-
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 reboot and the file system hasn't been expanded... then there is a problem! 
-
-
1 hour ago, hojnikb said:
How about just lifting minimum voltage in AXP to above that of protection circuit ? This way, axp will cut off battery before internal protection can kick in. Or if you're brave enough, just remove protection from the battery all together and let axp do it's thing
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.
-
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):
QuoteFirst boot takes longer (up to few minutes) than usual (20s) because it updates package list, regenerates SSH keys and expand partition to fit your SD card. It might reboot one time automatically.
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?
-
This is a good idea. Everybody heard about Vanilla Kernel, but what is it. Mainline is a good expression.
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 like the cubietruck better, because it is more a general explanation, wereas with clearfog you go into a detail and with each update you might forget to change this wahtsorever.
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....
-
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.
-
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 tkaiser was pointing out. That was the same handy thing Dell did with all their machines - not only do you have the pretty blinking lights that via hardware give you POST diagnostics, but you could enter the on-board diagnostics and test all the hardware. It would be great if when you bought a new board you could plug it in, and without loading a SD card / flashing the eMMC, power the board up, hit ESC to skip the auto-boot sequence, type in 'diagnostics' or whatever, press enter, and then some basic diagnostics would be run - i.e. cpu stress test (hence also power supply test) memory, sd read / present, display test, etc. Then you'd know that everything was good to go. But that might be pushing the 16MB storage a bit, since you also want the boot-loader stuff? :-P I'll stop pipe-dreaming now...
oh, btw, @Christos... I'm one of the (occasionally) noisy ones who has moved pass most of the problems I had and still makes noise... so you might want to rethink that theory!
-
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 adopt a *similar* solution as to what the intel x86 uses with a BIOS... :-O -
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 on the pine64?). I was thinking more of the ability to shove ~40MB x 3 through to the GbE... yup... think we found the next bottleneck!
-
Don't know how they're doing it... I read that from their exceptionally detailed(!) product page... https://www.olimex.com/Products/DIY%20Laptop/
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?
What's the latter resolution? I thought they only want to go with 1366x768 (LVDS --> eDP)?
Anyway: Maybe you could do the micro community over there a favour and post http://web.archive.org/save/_embed/http://bundie.neterra.net:8080/a64/A64%20LCD使用说明书.pdf to the LCD subforum? So tinkerers who want to exceed the 800x480 currently know where to adjust values...
-
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?
-
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. :-/
-
- Firefox works without any problems on Armbian, that's simply since we install the armhf version by default on the desktop image since the arm64 version shows problems (this 'trick' can of course also be used to cure even the most crappy OS images for Pine64: on the broken Debian images from Pine wiki it's just 'apt-get purge firefox && apt-get install firefox:armhf' and those steps in between)
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 extended support release of firefox was backported to Debian Jessie as firefox-esr. Now, that is an issue - as the firefox-esr:arm64 appears to be broken for the pine64, and the firefox-esr:armhf package won't install without some serious massaging. Or being stubborn, ignoring the whole "old is good as is stable philosophy of debian" and jump onto the unstable bandwagon...
It's because of things like this I generally say... yeah, there's a workaround/bandaid, or you can go install Armbian and not look back! ;-)
The following packages have unmet dependencies: firefox-esr:armhf : Depends: libatk1.0-0:armhf (>= 1.12.4) but it is not going to be installed Depends: libdbus-glib-1-2:armhf (>= 0.78) but it is not going to be installed Depends: libgdk-pixbuf2.0-0:armhf (>= 2.22.0) but it is not going to be installed Depends: libglib2.0-0:armhf (>= 2.20.0) but it is not going to be installed Depends: libgtk2.0-0:armhf (>= 2.24.0) but it is not going to be installed Depends: libpango-1.0-0:armhf (>= 1.14.0) but it is not going to be installed Recommends: gstreamer1.0-libav:armhf but it is not going to be installed Recommends: gstreamer1.0-plugins-good:armhf but it is not going to be installed E: Unable to correct problems, you have held broken packages.
-
Since I've been asked via PM how to fiddle around with some missing bits with Pine64 and BSP kernel like battery calibration...
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 have made the jump to Armbian on my cubietruck also and am pretty happy with the performance/stability there also.
-
You technically can use microusb to power up the board, you just need to bridge the SY6280 chip
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
Thus making it so the 8GB condition never fires???
Pine64 - System (Booting Up) LED
in Pine A64
Posted
Yeah, sorry about the three day wait... we have had issues with human spammers (either that or bot spammers that are good at reading the latest google recaptchas) joining up and posting garbage on the forums. I asked for a first three moderated post queue, but instead we got a 8hr + 3d cooldown window. Not new user friendly, but it is working. I'm just concerned that it will also cut down on the number of new users who will join the forum, but my concerns fell on deaf ears.
You'll usually find somebody on the IRC chat though who can help, and the Armbian crew are very helpful also as you've found!
What do you consider a 'simple' image? A console one or a GUI (graphical interface) one? The Armbian builds are probably the best supported due to the automated build process keeping everything consistent, and you get console and GUI options OOTB (out of the box). ayufan has some builds for the pine64 now also (although I haven't tried them yet) which could be quite interesting also going forward, although it's console only to start with.