Graham

Hi Igor, sorry but that's what I tried already a few days ago. All I appear to find is instructions on how to list the locales that are already installed (and I only see C) but I have not been able to find out how to download/install new locales I obviously have /usr/bin however the locale directory does not exist. OK, so the fastest way to find a solution is to first make an idiot of yourself, and then the solution pops up... I found this link where a similar question is asked, and followed the advice given in the answer there. When I ran the third command (after running the first two of course), a program popped up in the terminal window, where I was able to install and set my desired locale. Thanks guys for the point in the right direction. I have no idea why I was not able to find this before! https://serverfault.com/questions/301896/how-to-fix-locale-settings-in-debian-squeeze

Hi, this is a problem that has persisted on my Orange Pi H2+ Board (running Armbian) for quite some time now. At one stage I thought I had resolved the issue, but now since an update to some unrelated software, said software no longer works. I have tracked this back to the locale settings, which, for all intents and purposes, don't exist. I have tried a variety of fixes, such as trying to set Locale using the armbian-config , but Locale remains adamantly blank. I can SSH into the board (which is where I ran the arm config program, as well as the following commands). I tried dpkg-reconfigure locales but I only get told the following: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = "en_NZ.utf8", LC_PAPER = "en_NZ.UTF-8", LC_ADDRESS = "en_NZ.UTF-8", LC_MONETARY = "en_NZ.UTF-8", LC_NUMERIC = "en_NZ.UTF-8", LC_TELEPHONE = "en_NZ.UTF-8", LC_IDENTIFICATION = "en_NZ.UTF-8", LC_MEASUREMENT = "en_NZ.UTF-8", LC_TIME = "en_NZ.UTF-8", LC_NAME = "en_NZ.UTF-8", LANG = "en_US.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory dpkg-query: package 'locales' is not installed and no information is available Use dpkg --info (= dpkg-deb --info) to examine archive files, and dpkg --contents (= dpkg-deb --contents) to list their contents. /usr/sbin/dpkg-reconfigure: locales is not installed Finally, running locale -a I simply end up with the following: locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_COLLATE to default locale: No such file or directory C C.UTF-8 POSIX I have looked at your documentation too, and while I can find information on how to change to an alternative locale, there is no information as to how I go about INSTALLING missing locales. How do I fix this?

Hi Igor, I'm a bit confused here. When I follow the required links on the website, ARMbian takes me to a page (I'll use the Orange Pi Zero H2+ for example, but the other boards do the same, such as Zero H5) where it shows the board, and a couple of options for downloading ARMbian kernel. See my attached picture. I select the Ubuntu Server mainline kernel option, and download that, despite the fact it states "Testing" below. If this is not what I should be downloading, why does ARMbian bring me here in the first place? Where is the "legacy" code. PS to me when you say Legacy, that implies something obsolete/deprecated and no longer recommended for use. EG legacy hardware, the peoples legacy etc. implies something obsolete or left behind. I'm not the only one making this mistake if this is the case, as I know a few other people that have used ARMbian before, and they do the same thing. I think the "legacy" code should be retitled Current or Latest Stable Release etc. and there should be a big bold green button for download on the same page as the board, just my opinion. So back to my original question: Where do I locate the latest stable version of software for the Orange Pi Zero H2+ board?

Again, thanks for your feedback and assistance guidol. I was a bit like a dog chasing his tail there for about a week. Finally, I did a fresh install of Raspbian Pi on the Orange Pi Zero H2+, and installed Pi-hole. The little SBC is now running perfectly, and has not had any problems. It has been running continuously for nearly a week. This is the same hardware (Power supply, Orange Pi board etc.) so definitely the problem is with ARMbian, I have proven that now (hopefully that helps someone, as for a long time there, I wasn't sure whether this was a Pi-hole/hardware/psu/ambient temperature problem). I'll make 2 comments in this regard. 1. I am fairly sure that ARMbian ran cooler by several degrees centigrade, and this may have to do with ARMbian's management of clock frequency under light load conditions (most of the time, Pi-hole is not doing very much). With ARMbian I sat at about 30 degrees C core frequency. With Raspbian (at approximately the same ambient temperature) the core levels off at about 38 degrees C. 2. I still prefer ARMbian, largely due to all the attention to detail that has been placed by the developers (CPU throttling, ARMbian monitor, ARMbian configuration tool for the Orange Pi zero boards etc.) I therefore look forward to when there is a fully stable version of ARMbian for the Orange Pi Zero H2+ (and the H5 for that matter!). Thanks for you efforts guys, you're doing a splendid job, and it makes a difference to many I'm sure.

Thanks for your assistance guidol. much appreciated.

Hi, Over the last couple of weeks, I have been trying to get Pi-hole working (and more importantly, stable) on the Orange Pi (along with the relevant Orange Pi zero H2+ ARMbian OS) without success. I realize that I am using "Tested" but as yet not marked "Stable" code, however I'm hoping this can help somebody here perhaps in terms of developing a stable OS for these little boards. I have rebuilt the SD card from scratch several time now. The SD card is of reputable make (Sandisk) and in fact I have tried two different cards, just in case this was a card issue. I'm using a reliable power supply, which I have verified by continuously monitoring it with my scope. I've had crashes during which the voltage never deviated even for nanoseconds, below 4.90V or above about 5.25V. IE the PSU is rock solid at 5V nominal. I initially suspected that temperature was an issue, as we had some very hot days here about 10 days ago, however the board crashed overnight, where ambient temperature was about 21 degrees, and the core never went above 27 degrees (according to OPi-monitor, which incidentally is a nice touch). As a test, I ran the board without Pi-hole on it, and just ARMbian and OPi-monitor running. I had done a full firmware upgrade as prescribed by ARMbian. The board ran flawlessly, including through some warmer days for more than 4 days. However when I installed Pi-hole (curl -L https://install.pi-hole.net | bash) and made sure it was fully up to date, which it was (pihole -up). Nothing else was modified or installed apart from this. The only configurations I had made, which I really don't see could cause the board to regularly crash, was to set a fixed IP address (sometimes using armbian-config, sometimes using nmtui, depending on what mood I was in during the re-install process) and set time zone to Pacific/Auckland (I live in New Zealand). These configuration changes were made also when I did the armbian standalone test for 4 days, immediately on install, not days later. Once when using dmesg, I saw in the log file that several times the cpu core was reported as being unresponsive for 22 or 23 seconds. Sorry, unfortunately I did not keep a copy of this, but I'll see if I can capture it again. Finally, when the crash happens, the board becomes totally unresponsive, and the heatsink temperature is noticeably warmer, indicating the Allwinner H2+ CPU is doing something. At this point even the debug serial port is unresponsive, and the only solution is to power down and reboot. Fortunately almost every time the board will reboot without severe corruption to the SD card. I am using an EXT4 format for the SD card which should hopefully improve recovery success over the old school FAT32 default. The crashes can happen anywhere between a couple of hours and half a day. I don't believe I have ever seen Pi-hole run for longer than about 14 hours on this board. Note I seriously doubt it has something to do with an issue with Pi-hole itself, as I am using stock standard code that many other people are using, but there must be some sort of race condition going on once it is up and running. Usually, just after installation, Pi-hole works perfectly. In fact I am typing this to you on my PC that is presently using the Pi-hole as its DNS server. DHCP is presently disabled, I am only using Pi-hole DNS capabilities (ad blocking, name resolving etc.) I have used DHCP functionality in Pi-hole as well before, but the crashes are the same. My only comment is that once when it crashed, it was not so obvious. The board appeared to be working, however I noticed that if I went to a new website full of adverts, the Pi-hole logs did not update and show that ads had been blocked. I realized at this point it had crashed or somehow become corrupted. Every other time though, the board has completely crashed with no web access to the board etc. This faulty setup should be pretty easy for you to replicate on your workbench. I'm curious to know what your findings are. If I can help any further, please do let me know. P.S I see that under the "Tested" editio of this ARMbian release, you state there is a kernel memory leak or something to that effect. To date, watching OPi-monitor, I have never seen any increase in memory usage over time. It sits rock solid at about 310MB. Regards, Graham

I am running it without any case at the moment, so quoted ambient temperature is the actual ambient air temperature around the board (about 26 degrees with moderately high humidity on some days). According to ARMbianmonitor and Pi-hole, temperature definitely never went over 60 degrees at the core. I confirmed by checking the tracking or trend data in ARMbianmonitor as well. I am using some little Aluminium heatsinks that I purchased off Aliexpress, and these work quite well. When I say an LED is flashing, I am referring to the RED LED. This LED usually never comes on, only the green one, which is why I had never seen it before. Suddenly, when my board starting having issues, the RED LED started flashing, but I still do not know what this means. I have been unable to find suitable documentation covering this LED, aside from the Orange Pi manufacturers stating it is a status LED. At this point I can only think it is my power supply, given it's cheap nature. This has not been evident on my Oscilloscope though, but with that said, I only left the scope monitoring for any sags or surges for a few hours, and the ambient temperature was closer to 24 degrees. More testing is required.

Hi, Firstly my thanks to the team for an outstanding job on ARMbian. I'm relatively new to this particular flavour, using it on my Orange Pi H2+ board with a few different builds under my belt now. Recently I have been having some troubles getting Pi-hole to work on the little Orange Pi board. Twice I have had it up and running perfectly, with full DNS and DHCP control of my home network, accommodating about 10 devices. However after about 6 - 12 hours of operation, they ceased to function. First time around I was not home to witness it, but when I returned later, the Allwinner chip was running pretty warm (around 60 degrees C core temp) and non-responsive, even to serial login. The board refused to boot too, and I ended up doing a full ARMbian / Pi-hole rebuild. Second time however when it did fail, the web (Pi-hole server) access seemed to not update etc. but the board appeared to still be running as DHCP was still covered just fine on the network. On reboot, I saw for the first time a red flashing LED. To be honest, I never even knew this was there until now. I did some research, and it appears that for other SBC's at least, this is a status indicator, and it is used to indicated a power supply fault. The manufacturers of the Orange Pi state this is a Status LED, but apart from that I can find no other information. It is connected to GPIO15 as I recall, so really it's under the control of ARMbian. So what does the red Status LED indicate if it starts flashing? Is there a flashing code (eg 1 flash per second = power problem, 2 flashes = stack overflow, whatever). I now have a 'scope monitoring the power line, and I'm going to do some closer analysis of power quality first, along with another fresh ARMbian rebuild. Unfortunately I think this time around the Ethernet port access circuitry may have been damaged, as I am no longer able to get the existing ARMbian build to access the network at all, whether set with DHCP or a static address. Back to using my Linksys router as DHCP server for the time being. I'll know later for sure (this evening) whether or not the board is damaged (assuming of course this is a power problem). The last few days have been exceptionally hot here, however the core never went above about 58 degrees C, but high ambient temperature was no doubt a contributing factor to my problems. I have a heatsink on the Allwinner device, but was trying to see if I can get away with a fanless build, which should be possible given the processing requirements of Pi-hole. The board is near idle most of the time. I realize this question is somewhat verbose, I'm hoping that it helps other people with similar problems/questions, or they may have some answers for me too.