All Activity

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. 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.

bedna, that is not a "putty only" behavior. Attached the verbose output using the Win11 ssh client - same same I see only to pull the SD card, mount it on another linux system and then have a look at the ssh server and general system settings edit: i put that sd card into another SBC (odroid hc4), mounted that card, chroot, gave a passw to root, created another superuser etc. no change - ssh does not recognize any of these users. This is bad for morale.. ssh1.txt

Hello. After burning Efuse to the Nanopi Neo Core, I can't boot from emmc. It works from the SD card, so I try loading everything into emmc: spl, uboot. But spl doesn't find u-boot, as far as I understand. I'm using the u-boot and dts config from the Nanopi Neo, with some edits to mmc2, since it's not available in the Neo. U-Boot SPL 2024.07 (Feb 25 2026 - 15:51:42 +0300) DRAM: 512 MiB Trying to boot from MMC1 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001aa RET -110 CMD_SEND:55 ARG 0x00000000 RET -110 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:1 ARG 0x00000000 RET -110 Card did not respond to voltage select! : -110 spl: mmc init failed with error: -95 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###

Well don't know exactly how the board got bricked, but I would guess the armbian-config did not flash the SPI right and somehow my SD card got screwed too. armbian-install did it right. I was able to get it back by using the rkdeveloptool tool from my mac mini. For whoever runs into this problem this is what I had to do: Get a usb-c cable connected to the "DP Display Port" and connect to another machine to troubleshoot, disconnect the power source before you do this. Before you connect the cable, press the Maskrom button. This should allow you to access the SPI from your troubleshooting machine. I played around with the windows tool RKDevTool with no luck. I ended up compiling rkdeveloptool in my mac mini m4 and this one did work. Anywho, once you have the board hooked up and in Maskrom mode, you need to get your hands on the SPI Loader *.bin. It's somewhere in the resources page of radxa. The one I used is rk3588_spl_loader_v1.15.113.bin. After this you flash the board with the following commands: The following command should show you the board info and confirm it's connected in Maskrom mode. ./rkdeveloptool ld ./rkdeveloptool db rk3588_spl_loader_v1.15.113.bin ./rkdeveloptool ef ./rkdeveloptool rd This allowed me to boot aging from SD, even though I had to reflash the SD because somehow it also went bad. Not sure if it was because of all the testing or armbian-config screwed it up. After all this, I was booting again, and I did an armbian-install to move again the content of the SD to the nvme. I again, did an install/update MTD flash and boot from MTD first and this time around it all worked. I'm able to boot from SD first and if not SD is present it boots from NVME.

booting from sd should work even with proper mtd in place. Get usb uart adapter and provide boot logs.

@Nick A Thank you very much. Newbies will try. 😅

Hello! Are there any plans for a stable minimal/IOT release for the Rock 4D, and if so, what’s the timetable? Thanks!

Stop providing false information, I disproved your theory earlier, please stop. On Armbian, the way to do it via ssh IS TO LOGIN AS ROOT on first run, SSH has logging in as root ENABLED BY DEFAULT on Armbian. This works, and is the way I have ALWAYS done it on Armbian, for years. Here is a link to documentation: https://docs.armbian.com/User-Guide_Getting-Started/#first-login I quote: "The first boot will log you in automatically if you have connected a display via HDMI or if you are connected to the serial console. For SSH, you need to login as root and use the password 1234." If OP refuses to listen to recommendation and keep using putty, OP will have to take this up with the devs of putty, there is nobody here that can/will help with that.

Sorry for filling this thread with my issues. I'm calling it quits on this one and I'll just put up with it. It seems the v4l2request/drmprime stuff is a slow moving beast with ffmpeg/mpv and I have no interest in dealing with the dependency rabbit hole building my own versions. I found some references on the mpv github mentioning possible frame size issues so that's probably what causing my problems. I don't expect it will be fixed until ffmpeg upstream is sorted out. Going by current progress rates that's probably 2 years away.... I did find using --hwdec=drm-copy will play the files without producing the driver error but the green issue is still there. Using drm-copy with 1080p videos would be a little choppy though. I did a grep search on the mpv and mesa driver source code and couldn't find any reference to the "rejecting image due to unsupported offset" error so that must be coming from an external library. I did have a small win as installing the backported Mesa driver did fix some slight screen tearing issues I was encountering on 1080p content.

Thanks @sven-ola. I will give that a try. The standard Armbian is unable to connect to an WPA3 access point in basic client mode (no AP). It connects fine to WPA2-Personal.