eselarm

On other fora it is nowadays forbidden to post AI content. I would use same here. So you need to google yourself. Or just 'man dpkg'

I see wine, so you likely have let some tool mess up your Debian packaging setup. See what the following shows: sudo dpkg --print-architecture sudo dpkg --print-foreign-architectures For the rest , this is standard Debian methods, I forgot it a bit, but I see google AI shows all other commands w.r.t. this issue. But make sure you understand it. I at least don't know how to fix it, unless you just accept to remove all that wine stuff I guess. But see what your goal is or what you want.

I did not look well enough and also at a local PDF copy of the wiki which I see is more than 2 years old. Same text is there, but not in red at that time. I think I noticed it at the I was soldering the wire, but I clearly forgot the typing the message i this topic. Anyway, I have no good idea how to solve your remote power issue. I use a MOSFET that has low Vgs on (works directly on 3.3V , but is not for common GND. Else PoE managed switch where I can toggle power when fatal lockup or so. Or else instruct someone to pull the plug, wait 10 seconds, stick it back in again. If you use CoW filesystems, it is no problem to do this.

If you look at the wiki page you find the typical 26-pin header like for the original RaspberryPi. pins 2 and 4 are tagged 5V and pin 6 is tagged GND. However, in the schematics there is no mentioning of the 26-pin header. There is GND ofcourse and there is ACIN, that is the 'master' 5V you need to apply and is the same as the VBUS of the microUSB power connector. As there is also the option to connect a LiPo battery (needs soldering), I decided to use the microUSB input for power, I have enough DIY of those connectors (need soldering) as I am not 100% sure if ACIN is exactly the same as pins 2 and 4. I also use a very small DC/DC from 12V to 5V, so I have 12V, 5V, GND for BananaPi and 3.5inch HDD. In never do anything with power button, It is just and old molex connector that I use to connect/disconnect power. You will have the SATA connector sticking out quite a bit, even more then the microUSB for power, so using 26-pin header for power is not getting it much more compact.

Why you do this (on a normal modern Trixie kernel, actually even 1 year newer)? This is what I have (runs rockchip64 7.0-rc3 kernel): root@ranc:~# ls -al /sbin/iptables /etc/alternatives/iptables lrwxrwxrwx 1 root root 22 Nov 1 2023 /etc/alternatives/iptables -> /usr/sbin/iptables-nft lrwxrwxrwx 1 root root 26 Jan 16 2023 /sbin/iptables -> /etc/alternatives/iptables On other Aarch64 computer, it dates back to 2019 already, that is a standard Debian installation, always in-place upgraded since Buster or so. The Linux kernel does things natively as NetFilter, the iptables commands are mapped. Legacy is even older and I guess the old kernel API has been removed. But do research yourself if you want to know, at least 'man iptables-legacy'

I would not be surprised if there has always been a HW initialization issue. It is just that now with newer Linux (whole systemd stuff etc) you hit this problem. I always liked this HC1, but it is not even on Odroid WiKi anymore. You might need to focus on version/build of U-Boot in combination with kernel and DTB. I have some examples (Rockchip based SBC's) were it is make-or-break, e.g. if I just take latest U-Boot whole system / use-case is useless / gone. So I need to stick to legacy U-Boot or just buy other HW/platform.

Is the much trouble USB-SATA chip, I have it as 'cable', but unused as it at least fails with RPI4 when SSD. It looks like a sequencing/timing issue. You can treat it like external maybe and/or reset the USB device node. That usually works for various USB connected HW that fails at boot but when Linux/platform fully up and running, a reset then somehow avoids timing issues.

My ROCK3A has a jumper option to disable SPI clock, so whole SPI will be bypassed and only SD-card works then. I power with fixed 12V (USB-C pigtail). I do not know now what version the board/PCB is. AFAIR from Radxa docs other versions have no such jumper. Maybe you already tried/know all this. Maybe wipe the SPI via rkdevelop. W.r.t. Rockchip SBC's (various brands) I am a bit confused what boot-device prefence/priority is. From schematics I saw it depends on a resistor value, but many boards in the world and endless resistor values possible.

I also saw that both apt and beta repo's do not contain recent rockchip64 kernels at the moment. There is only a recent generic arm64 one. So it is not only my rock3a, also my nanopi-r6c would be affected, but I use own/other/vendor kernels as well, so specific 6.18.8 is not an issue for me. I use extlinux or grub to select a certain kernel (6.19 flavor on nanopi-r6c for example). For my rock3a, I need vendor kernel, but if you use mainline based, you could use standard Debian backports kernel: https://packages.debian.org/trixie-backports/linux-image-arm64 You need to get the .dtb manually and I just assume most features are supported when the rock3a has mainline U-Boot in SPI. You need of course add that to sources.list and specifically select it. You could also use Armbian build framwork to build a 6.18.x yourself, you will also get a header files package then. For Debian14 I see there is: /usr/lib/linux-image-6.18.15+deb14-arm64/rockchip/rk3568-rock-3a.dtb But as indicated, this is total DIY, I have not tested it. I only know that on rock5b I could run standard distro since quite some months, but use 6.1.115 vendor one as I need all RK3588 HW to work.

Maybe see https://wiki.postmarketos.org/wiki/Medion_Chromebook_S2015_(google-veyron-mighty) It is RK3288, so an Armbian Rockchip kernel might do something, but I have no clue about DeviceTree and/or bootloader. Alpine is quite different from Armbian/Debian but maybe with that bootloader+kernel+DTB and Armbian rootfs it might do something, but make sure you have seril debug cable. In general might need to find solder points on motherboard/PCB or some specific resistor value on OTG ID pin.

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.

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.

you cannot login as root via ssh using password, it is disabled by default for years already you need a normal user first or prepare the image/sd-card to use ssh keys/ids

in the root of the rootfs do: find . -name platform_install.sh find . -name u-boot-sunxi-with-spl.bin essentially construct correct dd arguments somethings else might be wrong though, so make sure you have a serial console/debug able with loglevel=7

The paste armbian URL displays nothing (anymore?) so without any (new) info from you, no-one can help you. AFAIR, 4K via HDMI connector is only recently available (on RK3588, not sure about RK3399), so make sure you can manage various combinations of U-Boot, kernel, rootfs. So sort of act like a developer, als make sure you have a serial console (debug) cable, else you cannot get any step further. Use a 26.2 based U-Boot and 6.19 rockchip64 kernel I would say, then see what happens.

If I understand you correctly: root via ssh is not allowed by default I usually setup (new) SBC's in a different way, but last time testing 2 of my boards with 26.2 minimal/IoT fresh image was via serial console, have not used ssh and certainly not putty. If no (serial) console, you might also have sme networking firewall issues somewhere in Windows or so, although would be vary rare. Have you setup a normal user first via (serial) console first?

You should also consider the bootloader (type and version), in principle you do not need the dtb- package as the dtb files are also in the kernel package (enough when doing own extlinux). U-Boot philosophy is to provide just enough so that the kernel/initrd/DTB can load and started. Audio is not part of that I think. LE certainly used other bootloader and as you already showed has more non-upstreamed patches. See my experience:

then this topic is not applicable

What hardware do you have? What exactly is in the M.2 slot?

What is in armbianEnv.txt then? Anyway you need to load and edit it such that you make sure loglevel=7 Then there will be more text after Starting kernel ... You also seem to have a power and/or reliability problem w.r.t. cables as characters are missing in your debug log text.

High chance this uses some proprietary hardware for 3.5mm audio jack. It has been like that for decades and you probably need to find some firmware blob somewhere maybe. I have also a similar situation, most part s of the computer work fine with Debian Trixie etc, but it took ages to get sound working and still buggy, endless beep or crash occasionally. If you are lucky is it maybe only a mute setting or so, use aumix etc to look what is going on. Not something Armbian specific I guess, but up to you to figure out. Then also mention various versions, what BIOS/UEFI version the computer is loaded with, what Armbian kernel and also specific image release (if it is an unmodified image writer based installation).

You should pipe the output from a serial console cable to another computer where you store it. Make sure kernel cmdline loglevel=7 AFAIR the OPI5+ can only use 5V as input supply power. Your 100W PSU might be a standard spec one so it does only deliver 3A at 5V. This might be a perfect 5.000V, but an extra cable in between will drop that a bit and the risk is then that short higher power drap will either make the 5V goo too low and/or the PSU will cut the power because more than 3A drawn during a short peak. You will need to look at powering first. Usually 5V only SBC's can be powered via other input then the USB-C input. You need to read the instruction for your OPI5+, and also OPi5, those might be different. OPI5+ and also OPi5 should transcode at more or less the same speed, large amount of memory does not really matter as it is just HW processing blocks doing the work in a rather limited memory space. You should do a manual CLI jellyfin-ffmpeg based transcode, see /var/log/jellyfin how commandline arguments for that specific video look like (and simplify it, output to 1 file instead of chunks m3u8). And or search this forum, I at least have posted examples for check/test earlier. You might also try to reproduce it with a publiclicy know video, look for big buck bunny test vids or so.

This is putting some sort of warning flag for myself. 'pretty sure', 'chatGPT', a Rockchip board v.s. Allwinner board.

OK, so the URL I posted is not correct. If those devices are there, your only option is to use dd with correct offsets on SPI/MTD or eMMC ( or SD-card) to write a U-Boot binary. An lsblk should show those devices, else maybe the armbian-install tool is likely correct with its error message.

see: https://radxa.com/products/network-computer/e25#techspec Only SD-card for this device, hence boot order is something fixed, just hardware. On software level it depends on how U-Boot it configured and compiled and on higher level, what partitions are found, can also be USB-stick, and what is on those partitions. Can be Armbian standard boot.scr or own extlinux or even EFI if you want. So minimum is SD-card with U-Boot on it, else nothing will happen unless maskROM is entered, see Radxa docs.