eselarm

This does not support f2fs I guess; standard in U-Boot is only FAT and Ext4 Some never U-Boot builds also include Btrfs. f2fs I have not seens working, but you will need to build a custom u-boot yourself then. Other option is at add Armbian argument to use an extra bootfs, tha will then be FAT or Ext4, so you can still use f2fs for rootfs. I would make U-Boot understand Btrfs and then use Btrfs for rootfs, as for several boards/platforms that is already default (likely only when you use newer/edge/mainline U-Boot).

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

My ISP offers no IPv6, so I usually set IPv6 configuration on disable or ignore. You still might see a link-local IPv6 address (starting with fe80), but that should not matter. I don't know why you can't simply type an IPv4 address in the various fields of nmtui. I have no issues with that. The risks is that you have various other random issues; If you try to do an fsck of /dev/sdc1 and it fails, that is a sign on the wall. It usually is something with SD-card, it might be counterfeit or your SD-card adapter has issues.

No; an Intel (virtual machine) image does not run natively on ARM (OPi5+). You need an ARM (virtual machine) image, but those are not available (at least not click-to-download). If you look in raw downlaod folders and/or github, maybe there are nowadays. Or ask on the forum there. You need a general Aarch64 UEFI HAOS image, qcow2 or raw/flat/img format and that will be able to run at full speed on a hypervisor. Not sure about VirtualBox, but for sure the Linux built-in QEMU/libvirtd/KVM. Main user-inteface program is installed via sudo apt install virt-manager.

I assumed your router is 192.168.71.1 and is only doing DNS for internet, so not for your in-house computer. For in-house computers, I assumed want to use a fixed IP address assigned on the local computer and also put a hosts file per local computer so all other computers in your house are known via that. So then, on a new image in a running computer, use: sudo nmtui to assign a fixed IP address. You need to tab through the options.

You mix up 2 things: - 'msdos filesystem' which usually means 'FAT' - 'msdos table' which usually means 'MBR partition table' Both can be up to 2 TeraBytes when sector or cluster size is 512 bytes. So no reason to change to GPT. Changing to GPT (with standard 128 entries), will use the same space as where the U-Boot bootloader is located on SD-card for older Arm chips, like Allwinner A20 (original bananapi). So risk is un-bootable. Back to your networking issues: I have not read all, but this BPI-M5 image is Ubuntu based and I see NetworkManager. So that means you also get netplan. I don't want that, so I only use Debian based images as a start. But it seems that if you use 'nmtui' text based tool that you still can quite easily set fixed IP addresses locally. At least that is the case for 'Raspberry Pi OS Trixie' where they also made a dependency between netplan and NetworkManager. Then since this year also Debian by default uses systemd-resolved for their pre-installed (cloud) images for DNS. This means it all won't work out of the box for you. Same was the case for me, I use also my own router and DNS server and that did not work with Armbian (half a year ago). I think now some extra is done, as tests with 26.2 images what Igor asked for, worked OK, but only did boot them via serial console. Look up the forum topic about it if you want to know, I already forgot. So to work with local hosts file on every computer, the whole Linux must prioritize hosts file over DNS resolver. That is determined in /etc/nsswitch.conf I have at least 2 ARM64 computers that need fixed IP (they must work without router) so I have a few entries in hosts file, very limited and dedicated, as rest is all in router. So what I do with new images when some tests or so, is (as root): systemctl disable --now systemd-resolved # this stops the DNS resolver and also makes sure it won't start after reboot rm /etc/resolv.conf # when systemd-resolved is used, this file is a symbolic link to tmpfs in RAM, so if not removed, your next settings are lost after reboot echo nameserver 192.168.71.1 > /etc/resolv.conf Then same as on older (bookworm) Raspberry Pi OS, install openresolv (it handles access to /etc/resolv.conf 😞 apt install openresolv I can not guarantee that it all works the same in Ubuntu when netplan is active, but up to you to figure that out yourself in your network environment.

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?