Dantes

Hi, I tried to install WireGuard, but it resulted in a non-bootable-system Wasn't WireGuard integrated in the kernel ? How does this apply to Armbian ? Available rk3588 kernels: $ sudo apt search linux-image.*rk3588 Sorting... Done Full Text Search... Done linux-image-current-rockchip-rk3588/bookworm,now 24.11.0-trunk.152 arm64 [installed] Armbian Linux current kernel image 6.10.11-current-rockchip-rk3588 linux-image-edge-rockchip-rk3588/bookworm 24.11.0-trunk.152 arm64 Armbian Linux edge kernel image 6.11.0-edge-rockchip-rk3588 $ Apt tries to install this kernel: $ sudo apt install wireguard wireguard-tools Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: linux-image-6.10.6+bpo-arm64-16k linux-image-arm64-16k Suggested packages: firmware-linux-free linux-doc-6.10 debian-kernel-handbook Recommended packages: apparmor The following NEW packages will be installed: linux-image-6.10.6+bpo-arm64-16k linux-image-arm64-16k wireguard wireguard-tools 0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded. Need to get 87,9 MB of archives. After this operation, 169 MB of additional disk space will be used. Do you want to continue? [Y/n] n Abort. $

Reported the bug (and solution) upstream to <pkg-privacy-maintainers@lists.alioth.debian.org>. I wonder how long it will take

Step 6. is incorrect, this must be: $ xzcat armbian.img.xz | sha256sum 05ea4603da3c5f5517f6e3f83b8bc456d31e299ac97f564e77a49487f93e5f1b *- (the checksum from armbian.img.sha is still in its compressed form while the sdcard is obviously written uncompressed)

Running Debian on an x86/64 you can clearly see that "tor" is one of the dependencies for "torsocks" $ uname -a Linux TEST-MACHINE 6.1.0-25-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) x86_64 GNU/Linux $ sudo apt install torsocks Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: runit-helper tor tor-geoipdb Suggested packages: mixmaster torbrowser-launcher socat apparmor-utils nyx obfs4proxy The following NEW packages will be installed: runit-helper tor tor-geoipdb torsocks 0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded. Need to get 3.624 kB of archives. After this operation, 17,6 MB of additional disk space will be used. Do you want to continue? [Y/n] Found the problem, yay! Is this something Armbian fixes, or must this be reported upstream ?

Hi, The package torsocks wasn't working and I could not understand why it was not. Torsocks configuration file: /etc/tor/torsocks.conf (default) specifies port 9050 # Default Tor address and port. By default, Tor will listen on localhost for # any SOCKS connection and relay the traffic on the Tor network. TorAddress 127.0.0.1 TorPort 9050 So port 9050 should be visible with netstat, but it was not: $ netstat -at tcp 0 0 127.0.0.53:domain 0.0.0.0:* LISTEN tcp 0 0 127.0.0.54:domain 0.0.0.0:* LISTEN $ Then I tried to enable tor.service, but got an error: $ systemctl enable tor.service Failed to enable unit: Unit file tor.service does not exist. Maybe the tor package was not installed $ dpkg --get-selections | grep '^tor' torsocks install After installing the tor package: $ apt install tor Netstat should now show the port 9050 to be listening: $ netstat -at tcp 0 0 localhost:9050 0.0.0.0:* LISTEN tcp 0 0 127.0.0.53:domain 0.0.0.0:* LISTEN tcp 0 0 127.0.0.54:domain 0.0.0.0:* LISTEN Why is "tor" listed as a "recommended" package? Should this not be a dependency? $ sudo apt install torsocks Reading package lists... Done Building dependency tree... Done Reading state information... Done Recommended packages: tor The following NEW packages will be installed: torsocks 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 74,7 kB of archives. After this operation, 416 kB of additional disk space will be used. Get:1 http://deb.debian.org/debian bookworm/main arm64 torsocks arm64 2.4.0-1 [74,7 kB] Fetched 74,7 kB in 0s (202 kB/s) Selecting previously unselected package torsocks. (Reading database ... 117684 files and directories currently installed.) Preparing to unpack .../torsocks_2.4.0-1_arm64.deb ... Unpacking torsocks (2.4.0-1) ... Setting up torsocks (2.4.0-1) ... Processing triggers for man-db (2.11.2-2) ... $

I think the problem lies in the command line, which I copied like a complete toddler # grep RELEASE /etc/os-release OPENWRT_RELEASE="OpenWrt SNAPSHOT r0-fd4a703" # uname -a Linux 6.11-rc6 #0 SMP Mon Sep 2 08:09:51 2024 aarch64 GNU/Linux # lspci -vvv 2>&1 |grep -i ASPM LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L1, Exit Latency L1 <16us ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+ + ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+ L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L1, Exit Latency L1 <16us ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+ L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+ L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-

Can't get hdmi output in Armbian/6.11 yet, so I'll have to wait for that to clear up. However these 3rd party OpenWRT builds (https://github.com/mj22226/openwrt/releases) all show the same thing: OpenWRT Linux 6.1.94 # grep RELEASE /etc/os-release OPENWRT_RELEASE="OpenWrt SNAPSHOT r0-4dc539f" # uname -a Linux 6.1.94 #0 SMP Sun Jun 16 23:31:23 2024 aarch64 GNU/Linux # lspci 0003:30:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0003:31:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) # lspci -vvvs 01:00|grep -E "L1,ASPM" # OpenWRT Linux 6.4.2 # grep RELEASE /etc/os-release OPENWRT_RELEASE="OpenWrt SNAPSHOT r0-1a94f52" # uname -a Linux 6.4.2 #0 SMP PREEMPT Fri Jul 7 23:03:17 2023 aarch64 GNU/Linux # lspci 0003:30:00.0 PCI bridge: Rockchip Electronics Co., Ltd Device 3588 (rev 01) 0003:31:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd Device 3588 (rev 01) # lspci -vvvs 01:00|grep -E "L1,ASPM" # OpenWRT Linux 6.6.48 # grep RELEASE /etc/os-release OPENWRT_RELEASE="OpenWrt SNAPSHOT r0-5a5368e" # uname -a Linux 6.6.48 #0 SMP Fri Aug 30 11:13:30 2024 aarch64 GNU/Linux # lspci 0003:30:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0003:31:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) # lspci -vvvs 01:00|grep -E "L1,ASPM" # OpenWRT Linux 6.11-rc # grep RELEASE /etc/os-release OPENWRT_RELEASE="OpenWrt SNAPSHOT r0-fe4b9c3" # uname -a Linux 6.11-rc5 #0 SMP Sun Aug 25 07:38:04 2024 aarch64 GNU/Linux # lspci 0003:30:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0003:31:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) # lspci -vvvs 01:00|grep -E "L1,ASPM" #

That might be because its more of an appliance/router than a desktop. It might be a regression. I'd wait for 6.11 to arrive, Sunday we're at 6.11-rc6, so that would mean another 3 weeks give or take. But I have a couple, so I checked them for you: OpenWRT # grep RELEASE /etc/os-release OPENWRT_RELEASE="OpenWrt SNAPSHOT r0-212b6f9" # uname -a Linux 6.10 #0 SMP Mon Jul 15 13:18:21 2024 aarch64 GNU/Linux # lspci 0003:30:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0003:31:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) # lspci -vvvs 01:00|grep -E "L1,ASPM" # Armbian $ grep ^PRETTY /etc/os-release PRETTY_NAME="Armbian 24.11.0-trunk.71 bookworm" $ uname -a Linux 6.10.7-current-rockchip-rk3588 #1 SMP PREEMPT Thu Aug 29 15:36:13 UTC 2024 aarch64 GNU/Linux $ lspci 0003:30:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0003:31:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) $ lspci -vvvs 01:00|grep -E "L1,ASPM" $ Dantes

Dear Community, This might only be with the NanoPI-r6c images, but the SHASUM contains a temporary path which you don't have an thus fails. Since we cannot change the SHASUM because then the ASC would fail, I have a temporary workaround: sed 's,/.*/,,' armbian.img.sha | sha256sum -c In a script you could either 1. CD into the directory of the image 2. Run the SHASUM there 3. Use $OLDPWD to return or correct the SHASUM inline: sha256sum /path/to/file | sed 's,/.*/,,' > armbian.img.sha Dantes

Enable logging and check for hardware keys with $ tail -f ~/.kodi/temp/kodi.log then start pressing keys to see which ones are working. Those are the only ones you can work with.

Hello, Another point I would like to make is that all recommended tools to write sdcards are not in Armbian. So I would hereby formally request "usbimager" as an Armbian package since it was the only one I saw with source code available. That being said, I found myself being locked out as an arm64 only user. All packages are either for MAC or WIN, and if they are for Linux they are x86/x64. So what can you do ? Step 1. Install packages: $ apt install pv xz-utils Step 2. Verify checksum $ sha256sum -c armbian.img.xz.sha amrbian.img.xz: OK Step 3. Unmount sdcard: (very important! to avoid corruption) $ umount /dev/sdcard* umount: /dev/sdcard: not mounted. Step 4. Write image to sdcard $ pv armbian.img.xz | xzcat | sudo dd bs=10M oflag=sync of=/dev/sdcard [sudo] password for test: 1,31GiB 0:01:54 [11,6MiB/s] [===========================================>] 100% 0+867065 records in 0+867065 records out 7256145920 bytes (7,3 GB, 6,8 GiB) copied, 113,024 s, 64,2 MB/s Step 5. Verify image from sdcard (--size=bytes copied from step 4.) $ pv --stop-at-size --size=7256145920 /dev/sdcard | sha256sum 1,31GiB 0:01:43 [11,9MiB/s] [===========================================>] 100% 05ea4603da3c5f5517f6e3f83b8bc456d31e299ac97f564e77a49487f93e5f1b - Step 6. Check if the hash matches $ cat armbian.img.sha 05ea4603da3c5f5517f6e3f83b8bc456d31e299ac97f564e77a49487f93e5f1b *armbian.img.xz My 2 cents

Hi fella's Well I think this is worth updating the #how-to-prepare-a-sd-card page with an extra bullet point pointing to: https://www.grc.com/validrive.htm. This freeware tool detects fraudulent USB mass storage devices. The page explains it in more detail.

Maybe there is a sticky somewhere on this forum, (if not there should be) pointing to this url: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md This is the mainline status of the rk3588(s). How far a long they are and what features have been implemented. I'd give it another year or so.. but I'm looking forward to 6.12 that will be released before years end.

Still don't know what it is. The problem persists in Armbian_community_24.11.0-trunk.25_Nanopi-r6s_noble_current_6.10.6_gnome-kisak_desktop.img.xz

Speeeeeeeeeeeeeeeeeeeeeeeeeedy, I love it

Just found this: source: https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server source: https://arstechnica.com/security/2024/07/regresshion-vulnerability-in-openssh-gives-attackers-root-on-linux/ The vulnerability, which is a signal handler race condition in OpenSSH’s server (sshd), allows unauthenticated remote code execution (RCE) as root on glibc-based Linux systems; that presents a significant security risk. This race condition affects sshd in its default configuration. Are we affected running Armbian ?

I'm trying to setup disk encryption, but for some reason its not opening devices after installing cryptsetup-bin on the installation image. After typing the password it just hangs and does nothing $ cryptsetup open /dev/sda sda_crypt Anyone?

Armbian/Jammy is working like a charm, thanks guys. Settings up the encryption was a bit of bitch but its working as you can see. Any chance of adding encryption to the installer?