schwar3kat

This topic may be of interest.  It sounds similar to your issue.  Perhaps ask how what they solved it and if it fixes the HDMI and WiFi. 
Perhaps you can get the DTB from them and try it on your board.
Seems that there might be other boards with the same issue...  if this is the same issue.  
It seems that there are different variants of the boards, and that AXP805 regulator control is different.
 
I see a solution for the above problem for a different board here.  It's a device tree change to use i2c instead of RSB.
https://github.com/armbian/build/pull/3964
 

@Gabriel Zanetti
I got it to work on an orange pi zero 2 but you need to compile your own image. The can bus needs to be activated in the kernel:
 
 ./compile.sh BOARD=orangepizero2 BRANCH=legacy RELEASE=bullseye BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=yes COMPRESS_OUTPUTIMAGE=sha,gpg,xz
 
After the kernel configure menu comes up activate CAN in the network section and take a deep dive into the sub menus to activate usb can adapter gs_usb
 
This works with candelight as well as klipper USB CAN bridge.

It has been diabolically difficult to identify this issue.   Good news is that it is not a build issue, and it's not a reversion of the lan0 bug.   I have flashed around 100 images and done countless power-downs and reboots.  Each time I thought that I was making progress, more testing disproved it.    The initial workaround did seem to resolve the issues, but they still occur if enough reboots are done.   Even older builds have the issue if enough reboots are done.  It seems that newer builds are just more sensitive to the issue.

At one point I thought that there were two different issues for Debian and Ubuntu builds because the fixes were different, but more testing proved that the fixes didn't stick permanently.  Symptoms are also variable, from the more common intermittent drop-outs and slow-downs to the less common total loss of lan0 NIC or total loss of networking. 
 
In my environment, the issues can be completely eliminated by disabling IPv6.  Using armbian-config to do this does not work!  
The armbian-config method adds lines to /etc/sysctl.conf but unfortunately this does not disable IPv6.
Ipv6 must be disabled by adding extraargs="ipv6.disable=1" to armbianEnv.txt.

The cause seems like it might be related to the resolvconf-pull-resolved.service and NetworkManager and RTL8153B, and is intermittent, but once it has stopped working correctly, it is problematic to get it working again without a power-down (on Ubuntu, apt-get --reinstall install resolvconf then reboot fixes it temporarily). 

I suspect that my IPv4 NAT environment is sometimes confusing resolvconf or some other networking component on this board and leaving somethings in networking in a corrupt state.  I don't have the same issue with my H5 and H3 boards.

I will change the work-around instructions to reflect my findings.

I experienced this issue tons of times in the past while working on tvbox support, mostly it was happening after freeze/reboot during kernel boot.
 
As far as I can remember I took a look and there was an armbian service which was rewriting armbianEnv.txt at startup (maybe to update usb quirks?), in fact the order of keys in armbianEnv.txt sometimes changes.
I suspect that when, for a reason or another, the cache is not correctly wrote to flash, armbianEnv.txt gets corrupted.
Recently it didn't happen anymore to me, to be honest.
 
 

Jammy boots up fine: http://ix.io/41zg
apt upgrade & reboot was fine too
Armbian_22.05.3_Nanopi-r4s_jammy_current_5.15.48.img.xz
 
Bullseye boots up fine: http://ix.io/41zi
apt upgrade & reboot was fine too
Armbian_22.05.3_Nanopi-r4s_bullseye_current_5.15.48.img.xz
 
 
Tests performed with 32GB Sandisk Extreme V30 U3 A1
Images written and verified with USBimager 1.0.8

If you downloaded an Armbian image, did you do an integrity check?
https://docs.armbian.com/User-Guide_Getting-Started/#how-to-check-download-integrity
 
Did you verify the image when you flashed it to the SD?
https://docs.armbian.com/User-Guide_Basic-Troubleshooting/#writing-images-to-the-sd-card

I forgot that I had made a copy of the fs of the corrupted Pine64 SD.  This is what's in armbianEnv.txt:
/var/log.hdd/alternatives.log {
    monthly
    rotate 12
    compress
    delaycompress
    missingok
    notifempt:
    create 644 root root
}
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
-------------------------------------------------------------------------------------------------
The first part of this content matches the content in the file /etc/logrotate.d/alternatives
 
Most of the files in /etc/logrotate.d are also corrupted with only 'alternatives' seemingly intact.

Many have streams of  \00\00\00\00\00\ ... appended and many are truncated.
 
There is an empty file named 'sedd3SIEh'.

'apport' has been overwritten with the missing part of armbianEnv.txt as follows:
verbosity=1
bootlogo=false
console=both
disp_mode=1920x1080p60
overlay_prefix=sun50i-a64
rootdev=UUID=3e9afe94-8407-4434-9be6-9528

It's as if the sed command went haywire.
 
/etc/logrotate.conf is also corupted, truncated and a string of \00\00\00.. appended.

Ditto on a Pine64 running Buster or Bullseye (can't remember which). 
I thought it must have got corrupted somehow, but it's just a spare that I have so It didn't bother me.  I noticed that it looked like /var/log/ stuff and thought that it was peculiar.
I took the opportunity to try the new Jammy instead and forgot about it until I saw this post.

Hello Disctanger.
Have you measured the speeds that you get with OEM's officially supplied software, if the OEM supplies any?
 
It been my experience that some 'open source' OEM's quote the theoretical maximum specs if hardware and software were optimized.
Some OEM's provide very limited support for their 'open source' boards, and rely on the community to optimize the software and even the hardware.
If this is one of those OEM's, then it's up to the community (people like you) to optimize the software (or even the hardware). 
You can search these forums to see if anyone has found solutions, and sometimes someone might answer with a suggestion or a solution. 
The Armbian build system is an ideal platform for you to develop solutions, providing an easy way to apply patches and stream improvements into the build via Github pull requests.

I took a look at your logs, and I didn't spot anything obvious. Perhaps someone more familiar with your board will turn up.
Good luck
 

Hello,
 
Thanks for reporting this, it should now be resolved.  Please do let us know if you see any further issues.
 
Cheers!

Close the session or use sudo -k which forces a time out.
More info in this link https://askubuntu.com/questions/1195719/how-do-i-force-sudo-to-ask-for-a-password-each-time-when-a-specific-command-is

Sudo users by default supply their own password for authentication, rather than the password of the target user. After authentication, and if the configuration file (typically /etc/sudoers) permits the user access, the system invokes the requested command.  https://en.wikipedia.org/wiki/Sudo.

When you ran the command 'sudo passwd', you were changing the password for the root user, not the user invoking sudo (you were acting as root when you changed the password).

It has been diabolically difficult to identify this issue.   Good news is that it is not a build issue, and it's not a reversion of the lan0 bug.   I have flashed around 100 images and done countless power-downs and reboots.  Each time I thought that I was making progress, more testing disproved it.    The initial workaround did seem to resolve the issues, but they still occur if enough reboots are done.   Even older builds have the issue if enough reboots are done.  It seems that newer builds are just more sensitive to the issue.

At one point I thought that there were two different issues for Debian and Ubuntu builds because the fixes were different, but more testing proved that the fixes didn't stick permanently.  Symptoms are also variable, from the more common intermittent drop-outs and slow-downs to the less common total loss of lan0 NIC or total loss of networking. 
 
In my environment, the issues can be completely eliminated by disabling IPv6.  Using armbian-config to do this does not work!  
The armbian-config method adds lines to /etc/sysctl.conf but unfortunately this does not disable IPv6.
Ipv6 must be disabled by adding extraargs="ipv6.disable=1" to armbianEnv.txt.

The cause seems like it might be related to the resolvconf-pull-resolved.service and NetworkManager and RTL8153B, and is intermittent, but once it has stopped working correctly, it is problematic to get it working again without a power-down (on Ubuntu, apt-get --reinstall install resolvconf then reboot fixes it temporarily). 

I suspect that my IPv4 NAT environment is sometimes confusing resolvconf or some other networking component on this board and leaving somethings in networking in a corrupt state.  I don't have the same issue with my H5 and H3 boards.

I will change the work-around instructions to reflect my findings.

Thanks.  I will check later, when I get home from work.

Orangepi Zero Plus - published images work.

Armbian_22.05.1_Orangepizeroplus_bullseye_current_5.15.43.img.xz
Armbian_22.05.1_Orangepizeroplus_focal_current_5.15.43.img.xz
Armbian_22.05.1_Orangepizeroplus_jammy_edge_5.17.11.img.xz

Issues now resolved
orangepi-r1plus-lts - no issues observed.

Tested:
Armbian_22.05.1_Orangepi-r1plus-lts_bullseye_current_5.15.35.img.xz
Armbian_22.05.1_Orangepi-r1plus-lts_focal_current_5.15.35.img.xz
Armbian_22.05.1_Orangepi-r1plus-lts_jammy_edge_5.17.5.img.xz

iperf on both Ethernet interfaces produced expected results.

Maybe I'm doing something wrong, but after switching to the right branch, it still helps me :
 
./compile.sh LIB_TAG="v22.05"
 
without this key, the system itself switches back to the master branch 
 
ps I would suggest for future discussion, get rid of this parameter in scripts and use a "dumb branch switching system" (i.e., do not check which branch the system is on and use the current one, without auto-switching, or just issue a message, but do not switch without "user permission").

Let me explain how CI should build images. I am generating packages with a regular build train:
https://github.com/armbian/build/actions/runs/2360625136
 
It generates all kernel packages, firmwares, desktops and all u-boot + board bsp. Then i put packages to the nightly build repository which currently contain (should contain) latest packages made from v22.05 branch and labelled this way too. Next I use a script "Build images" and choose extra parameters:
- build RC images (stable is identical, just they are placed to /archive instead of /rc)
- which runners will be used (not relevant build performance tweak)
- which is the source branch (v22.05 in this case)
 
Now there are all sorts of problems possible:
- error reporting is not the best and we can easily have false positive build. Corruption can happen if some runners goes out of memory or space. Happens from time to time.
- yesterday i have deleted repository by mistake and i need to recreate it (no technology in place at that storage)
- i have many troubles with local lan due to failed attempt of refactoring
- NAS often timeouts and build has to be re-done
- Github is unstable when providing Docker images, when starting Runners, CI because of that is not 100% reliable
- all this process is still half manual 
 
 
In short term, no. Long term - start learning Github actions. We need to cleanup the code and have more people that can jump up and fix troubles if they arise. Code complexity is going up and most of the code there is completely without any proper commenting or history. It was ad-hoc on ad-hoc on ad-hoc ... its time to get things in some order.

Simply doing git clone on the repository and then using "git checkout v22.05" should do the trick. With git branch you can then check on which branch you are.

orangepi-r1 - no issues observed.

Tested:
Armbian_22.05.1_Orangepi-r1plus-lts_bullseye_current_5.15.35
Armbian_22.05.1_Orangepi-r1_focal_current_5.15.35
Armbian_22.05.1_Orangepi-r1_jammy_edge_5.17.5

iperf on wifi and both Ethernet interfaces produced expected results.

orangepizeroplus - no issues observed.

Tested:
Armbian_22.05.1_Orangepizeroplus_bullseye_current_5.15.35
Armbian_22.05.1_Orangepizeroplus_focal_current_5.15.35
Armbian_22.05.1_Orangepizeroplus_jammy_edge_5.17.5
 
iperf on wifi and Ethernet interfaces produced expected results.

RK3328 Orangepi r1plus lts seems to have reverted to broken LAN0 Ethernet behavior similar to before the commit
Enable rockchip64: XHCI HCD USB TRB ENT quirk for RK3328 #3763
I can't immediately see what the cause is.  The patch works and quirk is included in the dtb.
Same as before, it can be mitigated by disabling tx offload.
I've reset AR1172 to in progress,
 

I'm building from the armbian-next branch for testing and I'm finding the experience quite unfamiliar and a little annoying.   It does seem faster though.

Orangepizeroplus (H5) built successfully for current, jammy and the image produced worked. I suspect that other flavors will build okay for testing.
but it errored after building the image [] Error occurred [ code 23 at /root/build-armbian/rc/build/lib/functions/logging/runners.sh:134

Orangepi-r1plus-lts (rockchip64 RK3328) built successfully for current, jammy.  No build errors.

Orangepi-r1 (H2) build system failed near the end.  019.000.create_board_package.log
--> 🛠1272: 1319406 - 1319406 - 1319406: ehBE: debug: Running family_tweaks_bsp [ sunxi ]
--> 🧽 1272: 1319406 - 1319406 - 1319406: ehBE: trap: main_trap_handler [ ERR and 1 trap_manager_error_handled: ]
The annoying 6.8 MiB html log file is a pain to parse. 

I guess that the build system enhancement issues will be picked up and dealt with separately and should probably not have bugs logged by SBC testers, or should I be logging bugs?

Can I switch off the time wasting and annoying markdown / html logging behaviour?
I don't want caterpillars, butterflies ants, bunches of leaves and comic explosions that don't make anything clearer and are unnecessary annoyances that don't play nicely with my tools.
LOG_ENABLE_EXTENSION=no, didn't do it.
Is it possible to keep the split .tmp files on error / build fail?

That's a patch, not an actual dts.  That patch modifies a Make file and creates a dts file.  The patch is part of a much larger build.  You can see an extra line being added into the Make file, (used to compile the new dts along with other dts's).  This is similar to the way Armbian build would do it, with one of the build scripts actually doing the compiling of all of the dtb's.

A possible way to do this would be to set up Armbian build and add the patch into build/patch/kernel/rockchip64-current.
You would need to manually modify the make part to match the Make file in /build/cache/sources/linux-mainline/linux-5.15.y/arch/arm64/boot/dts/rockchip.
Or a better way would be to use the CREATE_PATCHES=yes build option which would stop the build and allow you to modify the Make file then create a patch for you (second stop for kernel).  You could then use that patch to modify your original patch and build orangepi-R1plus-lts and the dtb will be compiled and end up with the others.  But you may not need to do any of that.

While looking up the patch path for this reply, I noticed a patch in Armbian Build called add-board-nanopi-r2c.patch. 
So I used the build menu (which I seldom do) and there is actually a build option for nanopi-r2c (it's not on the download list, implying that it's unsupported, and it's probably in the wrong menu (someone probably missed it when the menu's were split) and who knows if it has survived uBoot and kernel upgrades.   I see no archived builds, also implying that it's unsupported.  I've requested clarification of it's status, so it's likely to move to community support in the other (CSC/WIP/EOS/TVB) menu.  Unsupported boards are " build your own" only.

I suggest that you set up Armbian build and try to build it. 
You can use my instructions a few replies above either on an Ubuntu based PC or virtual machine.

Edit:  I built it.  One time only, it ties up my pc for an hour. Let me know if it works.
 https://drive.google.com/file/d/1nSug6EYF6O6CALLCaZA1PqRZE5VUBI2n/view?usp=sharing

Or if you run a recent version of Ubuntu or a derivative like Mint then you can use the Armbian build system.  It's pretty easy.
(Officially supported version is currently Ubuntu Jammy, but others are unofficially allowed (without support), and for others not on the allowed list, the OS check can be bypassed).
 
Log in as root (sudo su) and run:
$ mkdir /build-armbian  (wherever you want and named whatever you want)
$ cd /build-armbian
$ apt-get -y -qq install git  
$ git clone --depth 1 https://github.com/armbian/build  
$ cd build  
Run the script
$ ./compile.sh
Follow the menu's  (build time is slower the first time because it downloads, compiles, and builds caches, (and cpu power makes a big difference)

https://docs.armbian.com/Developer-Guide_Build-Preparation/

You can develop your own patches etc.