schwar3kat

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

On Windows and I'm not sure if there is a good method, but you can always compress the image. This will not help if you want to fit it on a smaller sd card. On Linux you can resize the image to a smaller image by removing unused space, and it can then be expanded to fit the size of your sd card. This is an old tutorial but it works: https://web.archive.org/web/20200602173912/https://softwarebakery.com/shrinking-images-on-linux

It's only 16MB. Smallest Armbian is about 1GB and it needs more space to operate. SPI flash is big enough for a boot loader, but the OS would have to be on other storage like USB drive.

Thanks for reporting. I have reported the issue. If it is causing you issues, you can choose another mirror: https://docs.armbian.com/User-Guide_Fine-Tuning/#choosing-an-apt-mirror Edit: This should now be resolved, see next reply.

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.

@Igor I have found a simple way to apply the mitigation that will work for most scenarios. It will continue to work with most external plugin USB NIC's that change the kernel NIC names (the previous work around would fail). The only scenario where it may not work is if a plugin NIC that requires the same r8152 driver is used. /etc/udev/rules.d/70-rename-lan.rules is modified using "eth*" as follows: SUBSYSTEM=="net", ACTION=="add", DRIVERS=="r8152", KERNEL=="eth*", NAME="lan0", RUN+="/usr/sbin/ethtool -K lan0 tx off" This will find the NIC with driver r8152 and rename it to lan0 then apply "tx off" to lan0. The affected boards ( nanopi-r2s and r2c, and orangepi-r1plus and lts) already grouped have a routine to create the file '70-rename-lan.rules' in config/sources/families/include/rockchip64_common.inc (to rename the NIC to lan0) and this is trivial to modify. . I have tested the change built on my local branch on orangepi-r1plus-lts. Orangepi-r1plus doesn't have a maintainer. You are maintainer of the others. I know that you don't have a r2c, but perhaps you have a r2s (forum indicates it has the bug)? If it is acceptable to patch for the 4 boards then I can have a PR ready very soon. I have not yet opened a new Jira task, in case a sub-task on AR1204 might be appropriate. This is more of a work around than a fix, but it will have to do until we can find a better solution.

I think that I figured a way to patch this in that will work for all scenarios. Just need to test. Nope: scrap that. I added a few lines to the download page. @Igor What state should I leave the Jira -AR1204. Currently it's 'to do' and tagged for this release and has a comment about the added lines.

'ethtool -K lan0 tx off' mitigates the issue. modifying /etc/udev/rules.d/70-rename-lan.rule to 'SUBSYSTEM=="net", ACTION=="add", DRIVERS=="r8152", KERNEL=="eth1", NAME="lan0", RUN+="/usr/sbin/ethtool -K lan0 tx off"' mitigates the issue permanently. But if you plug in another usb ethernet adaptor, it changes the name of the of the interface from lan0 to enx8aaf6680410a and the rename in /etc/udev/rules.d/70-rename-lan.rules no longer works, so lan0 is not consistent. Maybe we should leave it like this as a known issue with instructions on how to mitigate the issue, and I can investigate further and see if we can improve it for next release.

Very strange. Edge Jammy is working. Both current images have the the LAN0 RX bug. It is true that both NIC's are up, and LAN0 TX speed is good, but RX speed is between 0 and 90 B/s for a short period, and then it dies completely. If it does get an IP address, I can't connect to the device with ssh, it times out. Iperf fails with continuous errors on RX. (TX gets normal speeds): 'recv failed: Resource temporarily unavailable'. The results seem inconsistent which is perplexing. Time for plan B I think 🤔

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

Yes that is what I did.

I think that it did switch, but I can't guarantee it. Previously when I tried unsuccessfully to build this branch, balbes150 showed me to use LIB_TAG="v22.05" to prevent it from switching. targets.conf has your rock-3a changes, so I think it worked.

I don't see anything suspicious. They all look safe. I've opened Jira AR-1204 I tried a build from a clone of that branch using LIB_TAG="v22.05" and focal image worked. No obvious differences between the working and not working images. I wonder if this issue is similar to the first CI run that affected all three images with the same symptoms.

Initial RC images were all bad with the same issue USB3 Ethernet not working. As if the quirk patch was missing. Final RC images were all good.

orangepi-r1plus-lts - problems with the published downloads. Tested: Armbian_22.05.1_Orangepi-r1plus-lts_focal_current_5.15.35.img.xz - bad image. USB3 Ethernet not working, torrent and direct. Armbian_22.05.1_Orangepi-r1plus-lts_jammy_edge_5.17.5.img.xz - no image available, torrent or direct. Armbian_22.05.1_Orangepi-r1plus-lts_bullseye_current_5.15.35.img.xz - working, no observed issues (torrent tested).

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.

All three of the orangepi-r1plus-lts images in the RC folder are bad, they have the USB3 Ethernet receive bug. When I build the v22.05 branch locally, the images work correctly Affected images are: 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 If I understand you correctly, then this is probably a CI issue. Is there anything that I can I do to help resolve this.

Can someone please advise me. I tried to clone the RC branch to try and diagnose the issue. I'm not sure if this is correct: git clone -b v22.05 --single-branch https://github.com/armbian/build It cloned, but the image that I built worked, unlike the one I downloaded, so I suspect that this clone might not be correct.

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.

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.

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,

@thelinuxguy I've sent you a personal message, in your forum profile mailbox.