• Content Count

  • Joined

  • Last visited

Everything posted by GeorgeP

  1. Yeah - I'll look at this again when I get chance but it's not a big issue for me now - I don't often need to type '£' in a text console :-) I may give that a go - I have a build environment set up in a VM (somewhere! ;-) ) Although I've done loads of headless/server stuff this is my first real venture into Armbian desktops. If you build a console image can you then install a choice of desktops from armbian-config or do you have to do it all manually? I saw the armbian-config option to boot from SPI flash but was a bit scared of trying it in case
  2. Thanks for the input. I was originally referring to a terminal window on the desktop. When I read your message I looked at /etc/default/keyboard and found all kinds of weirdness originated from I've no idea where!! I rebooted, ran armbian-config and re-entered all of my usual settings, rebooted again and it's now behaving (well - sort of!). My /etc/default/keyboard now looks like yours and a terminal window opened on the desktop now behaves correctly. If I open a console terminal (Ctrl-Alt-F2 say) then shift-3 still does something weird - it appears like it prints a has
  3. I built a system very similar to this one: The heatsink on the SATA hat does run hot but using the fan driver on the 'hat' and the code in the article (which drives the fan according to the SoC temperature) keeps everything running nicely. Welcome to Armbian 20.08.9 Buster with Linux 5.8.13-rockchip64 System load: 2% Up time: 8 days 2:59 Memory usage: 22% of 3.71G IP: 192.168.x.x CPU temp: 40'C Usage of /: 33% of 15G
  4. UK (ISO) Keyboard problem - terminal won't display a 'pound' As a long-time user of various flavours of Armbian on headless sytems (OrangePi, NanoPi ...) I couldn't resist installing it on my new Pinebook Pro. Well it works like a dream and I am just sooo impressed by all the work that has clearly been done - audio works fine, armbian-config had me set up booting from emmc with my rootfs on nvme SSD in no time at all. BUT - one weird problem that has me baffled... I'm so used to headless Armbian boards that setting up keyboard and localisation is
  5. I've no specific postgresql experience but I have found that the way Armbian handles logging to zram can mean that the log files either don't exist or can't be written. Generally the answer to situations like this is to try running the binary from a command prompt with the 'verbose' switch set, if it then runs OK, try to modify the sysctl files to enable logging.
  6. I can't help thinking that something isn't right with your hardware. Have you tried booting the bare board "normally" from an SD card? I'm running my OPi3 on what is quite an old build but it seems rock solid. If it ain't broke..... ___ ____ _ _____ / _ \| _ \(_) |___ / | | | | |_) | | |_ \ | |_| | __/| | ___) | \___/|_| |_| |____/ Welcome to Ubuntu Bionic with Armbian Linux 5.3.0-sunxi64 System load: 0.15 0.16 0.14 Up time: 69 days Memory usage: 38 % of 1993MB Zram usage: 5 % of 996Mb IP: CPU temp:
  7. 1: I'm running an OPi3 as a headless server and I have no issues whatsoever.... Welcome to Ubuntu Bionic with Armbian Linux 5.3.0-sunxi64 System load: 0.02 0.07 0.03 Up time: 55 days Memory usage: 36 % of 1993MB Zram usage: 5 % of 996Mb IP: 192.168.x.x CPU temp: 54°C Usage of /: 52% of 7.1G 2: I have no idea. If I wanted a media centre I'd just buy a TV-box
  8. Maybe people looking to run a stable system should just stop chasing the very latest of everything! This uptime of 42 days is only because of a local power outage, otherwise it's absolutely rock solid running snapd, nextcloud, mosquitto, node-red, grafana, .....
  9. Without any information on what error messages you see it is almost impossible to suggest what may be wrong. Are you using a good power supply? Have you tried a different supply? Have you tried a different SD card?
  10. Remember that the H6 boards are still very much in development stage. If you aren't prepared to lose some data then IMHO you should choose a more stable platform.
  11. What is your power supply? You say "if the light comes back....." so are you using some kind of solar power? Why do you not want the systems to run continuously? You will struggle to get any board to start reliably if the power supply voltage increases slowly and a poor power supply is the cause of most reliability issues with any sbc. If you do have a solar supply you need to use a controller which switches the supply off and on according to the battery voltage. I strongly suspect that this could be your problem rather than the OS. You can try Armbian which I have always found
  12. I have a NanoPi Neo4 running "Debian Buster with Armbian Linux 4.4.190-rk3399" and I don't see this problem. I see this in htop:
  13. I've just come across this same problem. I copied the two files 'fw_bcm43438a1.bin' and 'fw_bcm43438a1_apsta.bin' (I'm not sure if that second one is needed) from /lib/firmware/ap6212/ to /lib/firmware/rkwifi/ and rebooted and the wifi now works OK. My board is very much a 'test bed' at the moment so I'm happy to test any possible fixes. George
  14. I just bought a FriendlyElec NanoPi Neo4 having had loads of experience with Armbian on Allwinner (OrangePi) boards. My preferred method for getting boards "up and running" is simply to connect a serial terminal to the debug port and power on. I tried this with several Armbian Buster images and found that I couldn't log in as root on any of them. Checking the SD card on my laptop, the debug port (ttyFIQ0) was missing from /etc/securetty. Editing /etc/securetty and adding ttyFIQ0 on a new line at the bottom of the file and all is well and I now have Buster u
  15. This is working very well for me (only 5 days uptime due to local power outage - otherwise it "just works" :-)
  16. Thanks MaX, but now I already have what I need - thanks to some others' comments on my post :-)
  17. Now that the OPi3 has been moved into the Armbian downloads section there needs to be be a set of 'known-to-be-working' images made available while development on newer kernels and features continues. There will be a number of people buying the OPi3 as their first SoC board, trying the 'factory' images (as we have all done in the past ) and then coming here where they will currently find images labelled "Suitable for Testing" that will not boot. This is not a great first impression of Armbian for these people, who won't yet have the knowledge or experience to hold back upgrade pack
  18. Works perfectly for me - thank you @dziobak ___ ____ _ _____ / _ \| _ \(_) |___ / | | | | |_) | | |_ \ | |_| | __/| | ___) | \___/|_| |_| |____/ Welcome to Ubuntu Bionic with Armbian Linux 5.1.7-sunxi64 System load: 0.22 0.16 0.14 Up time: 44 min Memory usage: 17 % of 1997MB IP: CPU temp: 36°C Usage of /: 24% of 7.1G
  19. Aaarrrgghh!! How did I not find that Thank you!
  20. Thanks for the suggestion but I need to use Ubuntu for the things I want to test, and I don't have *ANY* earlier Ubuntu images, only Debian :-/
  21. Hi guys, I'm aware of the current issues with the OPi3 images not booting and for me I can't find any of the currently downloadable images that will boot. I just need to urgently test a couple of things - can anyone point me to a reasonably recent Ubuntu Bionic dev server image for the OPi3 that will boot/run? I have an "old" Armbian_5.78_Orangepi3_Debian_stretch_dev_5.0.7.img that runs just fine (as long as I don't upgrade it!) but I don't have any similar Ubuntu versions. Does anyone happen to know of an archive of old versions, or maybe have something tha
  22. Seeing the current issues I'm happy that I'm running an earlier build :-) Welcome to ARMBIAN 5.83 user-built Debian GNU/Linux 10 (buster) 5.0.9-sunxi64 System load: 2.14 2.11 2.06 Up time: 23 days Memory usage: 60 % of 1997MB Zram usage: 1 % of 998Mb IP: CPU temp: 56°C Usage of /: 27% of 7.1G Currently running PiHole, MQTT and SETI@Home :-D
  23. With my OPi3 powered from the 'genuine' power adaptor via the power jack I'm not seeing any voltage issues. On no load I see 5.2v at the USB sockets..
  24. Are you really considering building an madm RAID with USB drives? Technically it is possible but I doubt you'll get anything but problems with reliability. It's easier than you may think to compile yourself - check out If you're looking to 'play' with mdadm as a learning exercise then fine, but if you really value your data I'd suggest you should build a 'proper' raid using an x86 board and good quality SATA drives. On budget SoC boards I'd just rsync my precious data across several physical drives.