schwar3kat
-
Posts
251 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by schwar3kat
-
-
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). -
On 5/30/2022 at 10:36 PM, Igor said:
text on download pages is good enough
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.
-
15 hours ago, Igor said:
they work - both NICs are up.
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 🤔 -
3 hours ago, Igor said:
I have build images again
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 -
1 minute ago, balbes150 said:
at the beginning I manually switch the branch (git checkout branch)
Yes that is what I did.
-
7 hours ago, Igor said:
I tried a build from a clone of that branch using LIB_TAG="v22.05"
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. -
3 hours ago, Igor said:
Check if you see anything suspicious here:
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. -
4 minutes ago, Igor said:
And RC images were alright, right?
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).
-
3 hours ago, Igor said:
Today's RC build
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. -
24 minutes ago, Igor said:
CI ads some troubles
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. -
19 hours ago, schwar3kat said:
RK3328 Orangepi r1plus lts seems to have reverted to broken LAN0 Ethernet behavior
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.
-
The patch is enabled. It was put there by the developer who configured the build. It is enabled by being in the directory. build/patch/kernel/rockchip64-current (If you are building current)
Your board is in the rockchip64 family. There are three active kernels legacy (currently 5.10y), current (5.15y) and edge (5.17y)The drivers are slightly different between 5.10 and 5.15/5.17 so it may be worth trying the legacy build.
I suspect that the build worked on an earlier kernel version and that it has has not been maintained on newer kernels. -
5 hours ago, thelinuxguy said:
Tried a few things
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 -
Three quarters of the way there
At least you now have something to start with.
If I was you, I would try the rk3328-nanopi-r2-rev06.dtb device tree that is included in the current build (and/or any other promising looking dtb's).
Easiest way is to open /boot/dtb/rockchip and rename rk3328-orangepi-r1-plus-lts.dtb to rk3328-orangepi-r1-plus-lts.dtb.bak and rename rk3328-nanopi-r2-rev06.dtb to rk3328-orangepi-r1-plus-lts.dtb. Or you can modify armbianEnv.txt but I can't remember off hand if there is another step to make this work which is why I mentioned the renaming method.
If this works, you can look into using Armbian build to customize a build for your board (and maybe contributing as a community build or supporting it). This is quite simple because it's all config with no kernal patching.
If this doesn't work, most likely, either the device tree is wrong or there are changes required to the kernel networking code to enumerate/identify/initialize the NIC. (The NIC drivers are already in Armbian and should in theory work).
If you can find a build with source for your device on some other Linux (preferably on the same kernel version) with dts (source code for a dtb) or even a dtb and a set of kernel patches, then you can ignore the NIC patch(es) and see if you can modify the other bits to work with code in the current kernels in Armbian build.
It can take an enormous amount of effort to research this sort of thing, so it's unlikely that anyone here would be willing to attempt it for you.
Repository with an expired certificate
in Beginners
Posted
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.