schwar3kat

When I try this build for a Rockchip64 board orangepi-r1plus-lts, a lot of patches including one of mine produce an error:
"patch is not properly mbox-formatted".  I guess that checking has become more strict? 
I don't see a log with patch errors, making it difficult to know what is wrong. 
 

I don't know if this will work and I can't test because I don't have your board.  

From a different OS same error:
https://my-take-on.tech/2021/05/07/fix-docker-cgroup-errors-after-systemd-248-update/
The write-up indicates that might only affect old docker containers, so the possible fix below may only work for those containers.

To do the same thing in Armbian:
In /boot/armbianEnv.txt    add a line (or if extraargs already exists add an extra argument separated by a comma)
extraargs="systemd.unified_cgroup_hierarchy=0"

Reboot and try again. Good luck.

Let us know the outcome either way.

Edit:  great this worked for Walden.

IT WORKED!!!
 
Thank you soooooooooooo much! I have spent so many hours determined to get this working and have given up so many times. I can finally proceed to actually use this thing the way I wanted!
 
You have no idea how happy I am right now...

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,