Werner

Hi @JrRockeTer 
Do :
sudo apt install zram-config and reboot. 
That will increase your zram from 1024MB to 2048MB. There's a fault in the armbian zram-config. For 4GB ram it should create 2GB zram. But it by default creates 1GB. 

If you run on an NVMe, then create a big swap file (don't forget sudo, or use "su" before applying the commands :
 
fallocate -l 8G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile echo "/swapfile swap swap defaults 0 0" >> /etc/fstab
I'll check out Focal mainline now on the M4V2. Cheers.

If you have an NVMe installed anyways you should put the swap there since it is way faster than an eMMC.
Or investigate if there is a memory leak.

So.... ¯\_(ツ)_/¯

Hi wanted to say we had a really awesome swarm of hacking last weekend.
 
Also we got a bit distracted on cutting RC branch due to the infrastructure move.

This happens after upgrading armbian-firmware package and it is already fixed in master and will be part of v20.08 release.

right /usr/bin/qemu-arm-static /bin/bash -i requires the `binfmt_misc` kernel module... can you confirm your build vm has that module.

I literally replicated your issue by not having that module, and then switched to a kernel with that module, and built successful.  Please at least consider investigating the binfmt_misc module

As am I JR...
Armbian is such a huge project, with not many people working actively on it. So that's why these things happen. If it were Microsoft we should be p*ssed. But this is Armbian. Free software made for free.

As I said, for a reliable desktop with the M4V2, this is still the image to go for. https://dl.armbian.com/nanopim4v2/Bionic_legacy_desktop
There are many other issue's with Focal alone. Then using a mainline kernel with issue's. My bet is it will take about 6 months before that's fully functional. But as said before, I'm no dev. Just a dude trying things out
Good luck.
 

Interesting. This needs to be investigated.
 
 
https://armbian.atlassian.net/browse/AR-340

Interesting. This needs to be investigated.
 
 
https://armbian.atlassian.net/browse/AR-340

It's not your fault. It's a bug in the latest Focal release.
 
Yesterday I flashed the latest Focal release available on the website. Everything was working fine until I did a 'sudo apt-get update && sudu apt-get upgrade". After that the kernel updated and my wifi interface was gone.
 
Buster does not have this bug. So if you are going to reinstall, make sure to flash Buster. Otherwise every time you will run and 'upgrade'  it will destroy your wifi interface.
 
 

We have moved the forums to a new host with higher availability.  Caches may need to be cleared.  Hopefully performance will be better as well.   Please reply here to report any forum-related issues.

That could be an issue. This kind of upgrade is neither tested nor supported. If you have a chance try with a fresh image.
And always handy to have: armbianmonitor -u

Hi @NicoD  nice to see you and nice to watch the videos, there are 3 I have not seen yet ..
I don't know what caused the problems.. After talking to werner I recompiled the fancontrol C program and set it up as a service and I used the original power supply. The rebooting issue disappeared.
I think it is stable now but it gave me a lot of problems, I finally changed to SDDM instead of the default and changed to Ubuntu Mate..
Now it works just like I want it to BUT ; In the process I managed to lose my wlan0 device, which I posted about in another post.
Yesterday I donated some money to Armbian hoping to help on the support side.
 
And thanks to  @Werner who tried his best.
Have fun holidaying, I'm not venturing far this year!

Enjoy yourself

Hi guys! Fortunately I found a solution to the problem: Use a gigabit switch. 
 
Orange Pi 3 and Orange Pi 4 just work on switch with Gigabit technology fine and not with 10/100 interface. Orange Pi One works fine but as exposed in old topic it was fixed. I found after first update many scripts of NetworkManager modified, maybe there are flags and other scripts impacting on NetworkManager.

I fixed issue by adding "load_addr=0x45000000" to /boot/armbianEnv.txt

Yeah I know, saw the YT videos
 
Unfortunately there is not much documentation in that case. It is quite hard to keep track what are current issues, what has been solved, what is new and everything across literaly hundred boards...
Anyway what might be interesting for you is to check JIRA for open threads: https://armbian.atlassian.net/projects/AR/issues/
I could have mentioned that before.
 
Support terms are stated here:https://github.com/armbian/build#support
 
And no, I am no maintainer or developer. I am just a random guy that spends (sometimes too much) time in the forums and help others and collect information that might be useful for actual contributors.
The issue in general is that the team behind Armbian is way too small for the amount of work and can barely catch up with everything. This of course has some downsides and relying on the community to provide p2p support.

You're welcome!
Glad to hear you could make progess.
 
If you come across stuff that can be enhanced or patched and you would like to share with the community please do so. Armbian heavily relying on community contributions.

Thx for the PR.
 
You can also things like blacklisting the wifi module, using iwconfig wlan0 power off ...

Actually no, you do not have to. Though the performance seems slightly better with kernel >=5.6.x

Hi guys,
some months ago I implemented an Odroid C2 as readout controller for a scientific instrument.
Lot of people were kind and helped me with some problems with Armbian, especially eMMC and PWM.
 
Today, finally, we managed to have our instrument (two strings with several Odroid C2 and other stuff) deployed.
It is sitting now at 2628m depth in the Pacific Ocean, and will go operational the next days.
 
Here we are... I think I can announce the deepest Odroid so far (cry loud if I'm wrong :) )
In the picture you just can see the Titanium housing with two glass covers attached to the string.
 
Again, thanks for the fish :)
 
Michael

rien ne va plus. Code freeze day

OK I took a closer look in the patch directory ( which I should have done earlier ) .
Yet I found these patches ( below ), but till now I was convinced flag " EXTRAWIFI=no " would bypass these.
Anyway after removing these two I succeeded to build my first 5.8 image ( with most patches )
 
-wifi-4001-add-realtek-8723cs-kconfig-makefile.patch
-wifi-4002-add-realtek-8723cs.patch
 
:~/armbian/output/images$ ls -l total 674496 -rw-rw-r-- 1 root root 792723456 Jul 17 08:53 Armbian_20.08.0-trunk_Orangepioneplus_buster_dev_5.8.0-rc5_minimal.img -rw-rw-r-- 1 root sudo 137 Jul 17 08:53 Armbian_20.08.0-trunk_Orangepioneplus_buster_dev_5.8.0-rc5_minimal.img.sha -rw-rw-r-- 1 root sudo 19667 Jul 17 08:53 Armbian_20.08.0-trunk_Orangepioneplus_buster_dev_5.8.0-rc5_minimal.img.txt  
 
___ ____ _ ___ / _ \| _ \(_) / _ \ _ __ ___ _ | | | | |_) | | | | | | '_ \ / _ \_| |_ | |_| | __/| | | |_| | | | | __/_ _| \___/|_| |_| \___/|_| |_|\___| |_| Welcome to Armbian buster with Linux 5.8.0-rc5-sunxi64 No end-user support: built from trunk System load: 0.00 0.00 0.00 Up time: 1:50 Memory usage: 9 % of 986MB IP: 192.168.10.122 CPU temp: 51°C Usage of /: 18% of 3.5G  
 
:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 1: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 2: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 3: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms.  
root@orangepioneplus:~# lsmod Module Size Used by rfkill 32768 1 snd_soc_hdmi_codec 20480 0 snd_soc_core 180224 1 snd_soc_hdmi_codec snd_pcm_dmaengine 20480 1 snd_soc_core snd_pcm 114688 3 snd_soc_hdmi_codec,snd_soc_core,snd_pcm_dmaengine snd_timer 45056 1 snd_pcm snd 81920 4 snd_soc_hdmi_codec,snd_timer,snd_soc_core,snd_pcm soundcore 16384 1 snd zstd 16384 4 sunxi_cir 20480 0 sunxi_cedrus 36864 0 rc_core 53248 2 sunxi_cir videobuf2_dma_contig 24576 1 sunxi_cedrus v4l2_mem2mem 32768 1 sunxi_cedrus videobuf2_memops 20480 1 videobuf2_dma_contig videobuf2_v4l2 28672 2 sunxi_cedrus,v4l2_mem2mem dw_hdmi_cec 16384 0 dw_hdmi_i2s_audio 16384 0 videobuf2_common 53248 3 sunxi_cedrus,videobuf2_v4l2,v4l2_mem2mem videodev 249856 4 sunxi_cedrus,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem mc 53248 5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem panfrost 65536 0 sun8i_ce 28672 0 gpu_sched 32768 1 panfrost display_connector 20480 0 crypto_engine 20480 1 sun8i_ce zram 36864 3 realtek 24576 1 i2c_mv64xxx 24576 0 dwmac_sun8i 28672 0 mdio_mux 16384 1 dwmac_sun8i  
This means now things drill down to go thru the patches which need to be either removed or updated for kernel 5.8 ( and u-boot )

I guess they rebranded an armbian image which includes alternative drivers for xradio and added the temperature fix....

Finally good news!
Today (2020-07-14) for ubuntu bionic becomes available mesa update, following packages:
libegl-mesa0 libegl1-mesa libgbm1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libglx-mesa0 mesa-va-drivers mesa-vdpau-drivers
 
After that, xfce desktop on orangepi2e starts to work flawlessly with kernel 5.4.xx (in my case 5.4.51) again.
Exact versions of packages:
igor@orangepiplus2e:~/trash/mesa$ dpkg -l | grep 'mesa\|libgbm1' ii libegl-mesa0:armhf 20.0.8-0ubuntu1~18.04.1 armhf free implementation of the EGL API -- Mesa vendor library ii libegl1-mesa:armhf 20.0.8-0ubuntu1~18.04.1 armhf transitional dummy package ii libgbm1:armhf 20.0.8-0ubuntu1~18.04.1 armhf generic buffer management API -- runtime ii libgl1-mesa-dri:armhf 20.0.8-0ubuntu1~18.04.1 armhf free implementation of the OpenGL API -- DRI modules ii libgl1-mesa-glx:armhf 20.0.8-0ubuntu1~18.04.1 armhf transitional dummy package ii libglapi-mesa:armhf 20.0.8-0ubuntu1~18.04.1 armhf free implementation of the GL API -- shared library ii libglx-mesa0:armhf 20.0.8-0ubuntu1~18.04.1 armhf free implementation of the OpenGL API -- GLX vendor library ii mesa-utils 8.4.0-1 armhf Miscellaneous Mesa GL utilities ii mesa-va-drivers:armhf 20.0.8-0ubuntu1~18.04.1 armhf Mesa VA-API video acceleration drivers ii mesa-vdpau-drivers:armhf 20.0.8-0ubuntu1~18.04.1 armhf Mesa VDPAU video acceleration drivers