All Activity

So we are perhaps looking at potential changes on SSH app / encrypting introduced in Debian Trixie? That affects certain clients. On Armbian side - we didn't change anything in this regard. Eventually we will get down to why this doesn't work. Software developers have to learn how to live with constant frustration. It never goes away ...

Some other info that may be relevant. Pretty much the only thing I could find that seemed to indicate different versions. cat /proc/version Linux Version 6.12.11-edge-sunxi64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP PREEMPT Thu Jan 23 11:23:05 EST 2025 gcc --version gcc (Debian 12.2.0-14+deb12u1) 12.2.0

mpv_--hwdec=help.logis what I get, and everything works as expected, but I am on current mainline releases with in-flight patches for mpv and ffmpeg on top. Gstreamer framework based applications work out-of-the-box. The log entries that contain the 'request' component are the ones that matter. But you're right, it can still take a while before current mainline releases are declared stable by some distributions and adopted. But this is not the fault of mainline development, which continues to progress and does not take outdated versions into account any longer.

I always use minimal CLI and deploy k3s. Might be the request amounts are too many or who knows. But the service hangs and stops working. Just my 2 cents.

No need to thank me in this case. You don't even read or understand or act upon it from the start; I mentioned essentially twice earlier what the problem is and now that I again opened that ssh log and you don't seem to understand how to handle ssh links. Is trivial for decades, you need to read docs or maybe ask an AI-bot, else forget about Linux and stay with Windows only.

I currently have a TV box with @Nick A Armbian-unofficial_25.05.0-trunk_x98h_bookworm_edge_6.12.11_xfce_desktop.img. I have installed linux-headers-edge-sunxi64_25.05.0-trunk_arm64__6.12.11 from the same repository. I'm trying to build a custom module to get the LCD working but I keep coming up against a Exec Format Error which implies a mismatch between the build version and the installed version. But I can't find the cause. I have been following the build instructions for tm16xx-display which hasn't been a smooth process. I've had to remove some forward slashes in the Makefile so it would find the drivers/auxdisplay folder and the line-display.mod.c file it created had entries with multiple double quotes that caused errors. I had to change ""LINEDISP"" to "'LINEDISP'" before it would build. I should also mention I have previously tried OpenVFD and come up with the exact same issue so I don't think it's related to tm16xx. uname - r 6.12.11-edge-sunxi64 Vermagic of the module 6.12.11-edge-sunxi64 SMP preempt mod_unload aarch64 uname -a Linux x98h 6.12.11-edge-sunxi64 #1 SMP PREEMPT Thu Jan 23 11:23:05 EST 2025 aarch64 GNU/LINUX I have little experience with building things in Linux. Am I missing something simple? Is "PREEMPT" listed in all caps in uname -a an issue when the vermagic line is lower case? What about mod_unload? Any other ideas? I've been googling all day and got nowhere. Most results show different version between uname and vermagic which isn't the case here as far as I can tell. I guess I just need to know if it's possible to build custom modules with armbian images or if it's something that just doesn't work and I should forget about it. Thanks.

Just some more info I forgot to mention that might help others. I found other repositories for mpv for bookworm that were greater than the version in this repository (35.1) but none of them worked with drm. I believe it's because drm support gets skipped if mpv is built without libdrm being installed. Run mpv --hwdec=help If drm is not listed as one of the options it will not work. You need to find a build with drm support.

Maybe this comment and thread have a hint for you https://forum.armbian.com/topic/47971-driving-the-ili9488-lcd-40-inch-cheap-chinese-clone/#findComment-229274 I don't own a waveshare LCD... but I would also like to know if its possible to make it work with Armbian

I'm on the current Debian Trixie build Armbian 26.2.1 Minimal / IOT, and Wifi is not working. What are the current suggestions to get it back up on BigTreeTech CB1?

Thank you for your comment. From a debian i can go to a stop with the reply of: "Unable to negotiate with xyz port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1" If I dumb the system down I go to the password exchanges with the attached ssh debug and the system does not accept the "1234" password and stops then. edit - frustrating because another odroid bookworm with the same ssh config file is available like a charm... ssh_debian.txt

AFAIR Windows uses other files/objects/regkeys when ssh admin/root I just remember it from other place on internet, test also with Linux only.

Looks like the same adjustment that was made for EDGE needs to be done so for CURRENT.

ok - so - by the book - burned one of the last bookworm images (Armbian_25.5.1_Odroidxu4_bookworm_current_6.6.88_minimal.img) - sshd-config file is attached (note "PubkeyAuthentication yes" and "#PasswordAuthentication yes" ) no connection - see attached "ssh_neu.txt" - can't negotiate the keything reburned image and changed the sshd config to "PubkeyAuthentication no" and "PasswordAuthentication yes" and got as ssh response the "ssh2.txt". So 2 times not even got to a password request. What to do ??? regards sshd-config.txt ssh_neu.txt ssh2.txt

Problem must be affecting most if not all (Armbian Debian) users in order to be removed. We need to understand why you have problems and we / others don't. If there will be more reports on issues, we will look into and fix them. This is how it usually goes. And minimal CLI has different networking stack as server / desktop.

I setup a fresh install on the RV2 using the pre-built Forky binary. Everything works stably but the idle load average is very high all the time: armbian@orangepirv2:~$ uptime 09:22:27 up 13:30, 1 user, load average: 2.00, 2.00, 2.00 Looks like the bug that cause the kernel to spin is still there.

Hi, No sure if this is the place to post this but here it goes. I use the Debian distro for my armbian deployments. Every time I deploy, and the system comes with systemd-resolved it gives me problems. I always have to remove it and use the /etc/resolv.conf file by it self. I would suggest removing this, it's not necessary or useful. -Cheers

Sorry for my late reply (been very busy in the last couple of days). No, reboot does not work either: same freeze. Anyway it's a software issue and that's unfortunate for Armbian, because shut down and reboot for my device work flawlessly with CoreElec. I hope in a future improvement.

Thanks for the advice.

How do you make it work on the original OS? I have the same screen and the same Orange Pi, but I haven't been able to make it work.

"ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss -oCiphers=+aes128-cbc -oMACs=+hmac-sha1 -vv root@xyz" Let's try again, but this will be my last time typing this: The normal way to use ssh, is to type: "ssh user@xxx.xxx.xxx.xxx" where x is the ip number. So for Armbian first login, it's "ssh root@xxx.xxx.xxx.xxx", NOTHING ELSE. Just glancing at the few first lines in that log: OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2 debug2: resolve_canonicalize: hostname xyz is address debug1: Connecting to xyz [xyz] port 22. debug1: Connection established. debug1: identity file C:\\Users\\sebas/.ssh/id_rsa type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_rsa-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa_sk type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519 type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519_sk type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519_sk-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_xmss type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_xmss-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_dsa type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_dsa-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_for_Windows_9.5 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.0 debug1: compat_banner: match: OpenSSH_6.6.0 pat OpenSSH_6.5*,OpenSSH_6.6* compat 0x14000002 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to xyz:22 as 'root' debug1: load_hostkeys: fopen C:\\Users\\sebas/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory As I suspected, it looks like it is somehow trying to use keys and whatnot. Since you refuse to listen, yeah, this might be frustrating and "bad for morale". If you instead listen and do what is suggested, your morale would likely not suffer at all.

I'm back Asking for help on Radxa discord i got the answer to check for the FPC ("Flexible Printed Circuit") cable pin orientation and run lspci next. Turns out it was the cable all along, lspci returned: # lspci 00:00.0 PCI bridge: Rockchip Electronics Co., Ltd Device 3576 (rev 01) 01:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02) and lsblk shows: # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 4.5T 0 disk └─sda1 8:1 0 4.5T 0 part sdb 8:16 0 223.6G 0 disk └─sdb1 8:17 0 223.6G 0 part mtdblock0 31:0 0 16M 0 disk mmcblk1 179:0 0 59.5G 0 disk ├─mmcblk1p1 179:1 0 16M 0 part /config ├─mmcblk1p2 179:2 0 300M 0 part /boot/efi └─mmcblk1p3 179:3 0 59.2G 0 part / zram0 253:0 0 1.9G 0 disk [SWAP] So now it works and i can carry on with making my NAS 😇

Probably the easiest way to assess chances is to submit PR.

Support for Rockchip’s VDPU381 and VDPU383 decoders is now upstream in Linux, bringing mainline H.264/HEVC decode support, robust IOMMU-reset recovery, and new HEVC V4L2 UAPI controls aligned with Vulkan Video. View the full article

Hello ik316q-emcp_v6.0 full dump please

Any chance of the above commit being adopted in future releases? It could make multichannel PCM hdmi audio work correctly.