GeorgeP

Thanks for the reply. I don't need OMV and I have no real need for a 'bleeding edge' kernel. so I think I will probably get one of the boards and go for Armbian with the 4.9 kernel. What's the stuff about "getting rid of petitboot"? - Don't the Odroid boards boot direct from SD?

@DanielRuf I was thinking about getting one of these boards to put together a simple NAS for a friend but I would really need it to 'just work' - sadly I don't have the free time to tinker as much as I used to :-/ Do you know if the OEM supplied firmware (Ubuntu?) works OK? Thanks!

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 I screwed the SPI if it went wrong, leaving me having to learn how to fix a 'brick'. If I can boot from SPI to NVME I can then use the EMMC for something else :-) Thanks for all your input :-)

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 hash and then a CR - but for now that's not an issue I can afford time to look at. So it looks like I had some corruption in the keyboard settings file - and as I remember I did have the system shut down on me (flat battery) half-way through some configuration :-) Interesting that you say you are running 'groovy' - presumably that is now an option in the armbian build system? I've not built by own versions for some time. How does it run on the PBP?

I built a system very similar to this one: https://cgomesu.com/blog/Nanopi-m4-mini-nas/ 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

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 almost automatic to me - but can I get the PBPro keyboard to generate a 'pound' (GBP, '£') in a terminal window- no I cant!! I've set everything up as I think it should be - and every other key on the (ISO) keyboard is correct - but open a terminal window and shift-3 (which should be '£') displays nothing at all. Other applications (Firefox, LibreOffice ...) will display the £ just fine. Can anyone give me any clues??? Thanks!!

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.

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: 192.168.0.5 CPU temp: 51°C Usage of /: 50% of 7.1G

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

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, .....

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?

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.

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 to be 100% solid as long as you choose a stable version.

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:

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