eselarm

I discovered via an only partly working ssh (I thought was WiFi signal strenght issue or so) that a new version of firewalld was installed and also new conf file that had default set to public instead of trusted (what should be fine for LAN only direct traffic). On a typical generic client-only laptop/computer you probably won't notice. Best is to keep that default and add a zone= statement to the NM profile for a specific connection. I have seen the same for systemd-networkd, but not done anything myself with it. Also should not happen on Debian Stable, but rolling distro is another story.

Yes, I already forgot this and maybe more; Armbian uses this by default now AFAIK, so this is another issue like netplan; I normally do in-place dist-upgrades, so my older SBC's I bought when Buster was the current Debian version, so that is still somewhere in a tag in a image generation file or so, but os-release is 13 and kernel 6.18. But for 1 case, I did take a recent/new Armbian image (Trixie) and it did cost a lot of time as the default settings for that don't work properly in my home network, so after reading freedesktop.org docs and with extra setting in conf file, it worked. But openresolv and a fixed resolv.conf is a simpler base.

So you try routed AP instead of bridged. Trixie might handle 'iptables' in a different way, depends also what alternatives you have for that and/or if it is netfilter underneath. This kind of manual setup (routed, hostapd) I did before Bookworm only a few times, rest is always bridged and basically using only NM. It seems to me that something on IP layer is not accepted by your phone, so it disconnects. You need to dig more and deeper and also still take in to account what is said about that brcmf_psm_watchdog_notify issue. But it seems yest another issues.

There is no proof it is the same problem. As I told you in topic: your Ultra does not have the same SoC as the original/normal OPi5. So this posting in the wrong group and is getting annoying. You should focus on RK3588, not the RK3588S Also the Ultra is community support only, so you are part of that. Make sure you understand installing latest kernels and U-Boot etc yourself manually and also building Armbian yourself. From latest other post here, I conclude that the 7.1 kernel at least can show some sign of life from NVME. Xunlong dumps HW on the market at a high rate, you cannot trust or build on that reliably. Check everything, even their 'official' image, where do the sources come from etc. My perception is that they just clone a certain old version of the Armbian build system, then make it work, likely only boot from SD-card and then they go on the next HW/marketing/vaporware.

The other usual thing is then PSU. So also maybe try a different one. Else I cannot really help you, not being able to find rootfs can have pure software cause, but is unlikely if other people can run it successfully. I wish I had bought this SBC a year ago, but I didn't and now they are sold out where I looked, so cannot see If I can reproduce the problem. You need to look in more detail yourself, like connecting serial debug console and setting loglevel to 7 in armbianEnv.txt. Also post which exact image is (sha256sum), so other people can try the same thing.

If it worked once and now not anymore, it might be the SD-card that is the problem. It might be a as bad that it is a fake SD-card.

Similar quick test here: N100 with PCIe ethernt and wifi HW, already a br0 with enslaved ethernet, I set up a working hostapd.conf, enabled hostapd.service and added /etc/systemd/network/22-wlp2s0.network [Match] Name=wlp2s0 [Network] Bridge=br0 ConfigureWithoutCarrier=yes Then reboot and properly working AP. Is Opensuse Tumbleweed. But it is rather 'static', not as flexible/dynamic as with NM. For example, if I do networkctl down wlp2s0 ; sleep 30 ; networkctl up wlp2s0 the AP still works, but network list shows failed for wlp2s0 I though maybe it has to do with the fact that Tumbleweed has no sysV compatibility anymore (folder /etc/init.d/ is not there), so no option that something goes wrong potentially due to some sync issues, but I think I cannot draw that conclusion. Quick check shows no relation between hostapd.service and systemd-networkd, but it is much more extensive than for debian13 for sure.

This should be specified down to just 2 things: Armbian U-Boot package and kernel package. The DTB package is redundant as the .dtb file is in the kernel package. For more low-level tests, I usually rename boot.scr and use manual extlinux, so easy to select a certain kernel+initrd+dtb(o). This also works for example with Opensuse Tumbleweed as userspace although (Wayland KDE ) GUI not anymore with vendor 6.1.115. For just standard Ext4 rootfs, note that multiple kernels is automatically handled by standard Debian package u-boot-menu (see its config in /etc/default/u-boot).

Then I don't know why it does not work, and I would assume this combination of SBC and NVME just won't work. Such cases exists, although frustrating that is does not work. You could cross check, but I don't know it you have other brands NVME to try with the OPi5 Ultra. I would also be not surprised if there is simply something wrong of missing in the U-Boot or DTB (all versions, even the one from manufacturer/xunlong). You can look at versions history of U-Boot for example, just to see how much your luck is or would be. And/or until someone with the same combination sees this topic. I only have Samsung NVME's. primarily 970+ in a ROCK5B, is also RK3588 4-lane PCIEv3 and older earlier 970 in an ROCK3A (2-lane PCIEv3). The latter one works but only with a very specific set of U-Boot, BTB and kernel (for my use case).

Ultra is not the standard OPi5 nor OPi5Pro, AFAIR it is also RK3588 v.s. RK3588S wich is a major difference w.r.t. PCIE Use a recent kernel/image, see https://armbian.com/boards/orangepi5-ultra And report brand and type of the M.2 NVME SSD. Some people have asked similar question and turned out to be a M.2 SATA SSD

Good that your bpi appears to be stable. My did hang again, no reaction on serial console, no reaction on IP networking. So I enabled the watchdog, uncommented the 'ping 192.168.1.1 line' and made it ping 192.168.1.100 and temporarily added that address to another computer: ip addr add dev br0 192.168.1.100/24 Then removing it: ip addr del dev br0 192.168.1.100/24 and after a minute or so: [ 263.929336] systemd-journald[236]: Received SIGTERM from PID 1071 (watchdog). [ 265.185973] systemd[1]: systemd 257.13-1~deb13u1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -BTF -XKBCOMMON -UTMP +SYSVINIT +LIBARCHIVE) [ 265.221538] systemd[1]: Detected architecture arm. [ 269.100327] systemd[1]: Failed to fork off sandboxing environment for executing generators: Protocol error [!!!!!!] Failed to start up manager. [ 269.146571] systemd[1]: Freezing execution. This looks like HW watchdog does not work. Same trick on NanoPi-NEO, so also sunxi kernel although 7.0.12-edge-sunxi, it resets. So appears to work although no proof that it is HW reset. I have not checked live dmesg or so, just noticed it went offline and came back later when I also added that .100 IP address again.

If you use and Armbian image with kernel '6.1.115-vendor-rk35xx' (note there are many builds over time, all same name, but you need to look in config-6.1.115-vendor-rk35xx and maybe also consider the gcc compiler version to have RKMPP based method working. I mean the API is there, you need a special ffmpeg (from jellyfin for example to use it) in order to use RKMPP based decoding and encoding in HW. That is just CLI, server use-case, works on RK3568 and RK3588. RK3576 should have the same speed/ASIC blocks as RK3588 AFAIK, but check yourself. It can do 5x realtime speed 1080p50 HEVC to H264. mpv 'uses open and agreed standards' and RKMPP is not. Also Android is completely different. Same is Windows or Apple iOS. Those are implemented by commercial/paid developers. In fact it is worse, ffmpeg open-source developers have concluded already long time ago the Rockchip downstream kernel code was copied and violates licenses. (Rockchip copied code and put their names in it.). So since a few months, ffmpeg developers requested github to remove access and that happened. So following GPL licensing, that 6.1.115 kernel is essentially illegal. How you want to deal with that is up to you. It is like it is. Anyway, 6.1.x downstream is getting old and might contain several unpatched security holes. So over time the 'problem' will solve itself as people won't trust it anymore despite being able to use every HW block in RK35xx. As already said, decoding generally is implemented as part on mainline kernel, you just need matching latest userspace. Encoding is much more complex. If you want that, only Intel/AMD is more or less viable option. Like N100, so in cheap miniPCs, certainly considering high RAM prices, is just a way better option. Plays all HW accelerated in FireFox (and mpv as well). Does also VP9 encoding for example, is a royalty free codec, so you won't see this 2 decades old patents issues for H264 and HEVC. Also note AV1 HW decoding was the first to be available in mainline kernel for RK3588. There is just not much content I think. And HW AV1 encoding is another level of new silicon, is not really an option to do in software.

# cat /etc/NetworkManager/system-connections/br0.nmconnection [connection] id=br0 uuid=75d54cd2-cdfe-4621-ab45-0bddf3ab4e6c type=bridge interface-name=br0 zone=trusted [ethernet] cloned-mac-address=my eth0 mac address [ipv4] method=auto [ipv6] addr-gen-mode=default method=ignore # cat /etc/NetworkManager/system-connections/eth0-br0_slave.nmconnection [connection] id=eth0-br0_slave uuid=31645756-5c39-4184-a0c2-337ae09422ec type=ethernet interface-name=eth0 master=75d54cd2-cdfe-4621-ab45-0bddf3ab4e6c slave-type=bridge # cat /etc/NetworkManager/system-connections/wlan0-br0_slave.nmconnection [connection] id=wlan0-br0_slave uuid=4ff7f9f2-056e-4836-9bc7-0e77d98a989c type=wifi interface-name=wlan0 master=75d54cd2-cdfe-4621-ab45-0bddf3ab4e6c slave-type=bridge [wifi] band=bg channel=1 mode=ap ssid=mywifissid [wifi-security] key-mgmt=wpa-psk proto=rsn; psk=mypassword template, stripped, optimized, cleaned, untested

I would not give up on the BPiPro just because this networking stack/tool issues. As I indicated, a bridged WiFi AP works fine with NetworkManager. Armbian images are there to get you started very easily, even without Linux know-how. But it still is Linux, open-source, all DIY and no company you can manage to blame (try to find the engineer(s) who designed the SBC ... ). I know the majority of SBC users throws away working older installations and then get stuck with some new pre-installed image. You can instead just dist-upgrade in-place Netplan is from Canonical and there to uniform Ubuntu so NM and systemd-networkd can be used. Debian does not need netplan, there is no dependency on NM nor systemd-networkd. Now look at this: A script from Armbian does netplan yaml that does .netdev/.network files or .nmconnection files. As long as it works, fine. But 3 layers, from math permutation you can know that means many more potential error cases. So you want to discard HW because networking config tooling has become too complex? I forgot to power off the RPi3b+ before night and now in the morning the internet on the smartphone still works (via that AP). A simple reboot via serial console and short flip to 4G but then back to connected to the AP. BUT, the wlan0 again shows as 'failed'. So it seems a timing issue or so or just the status reporting is the issue. Also Android normally simply disconnects on PHY/MAC layer if no public routing ('internet'). That might happen easily after reboots or so or just without various timeouts. Note I have disabled systemd-networkd-wait-online.service else always 3 minutes waiting at reboot. You can also specify how and what to wait for, but needs reading docs. Also note that OS is not vanilla Debian aarch64, but from RPL, there is many changed packages, especially also in the network domain. And RPi3 has USB connected networking, not on the SoC like most other SBC's, this is also an issue I discovered. I see for another RPi3: @/raspi4/latest/etc/NetworkManager/system-connections -rw------- 1 root root 259 Jan 21 16:16 br0.nmconnection -rw------- 1 root root 217 Jan 21 16:16 eth0-br0_slave.nmconnection -rw------- 1 root root 312 Jan 22 10:44 wlan0-br0_slave.nmconnection Is still RPiOS arm64 bookworm, but with some hacks to prevent netplan and cloud-init disturbing things and wasting time, it also works with RPiOS Trixie. Certainly without tricks on standard Debian Trixie as I simply copy those 3 files to and from old AMD fanless computer etc that also has WiFi onboard. You need to make sure you stop and start NM at the proper moments and also make sure no UUID doubles or orphans. Should be fine when new, not yet booted image.

You disable the zram swap, I forgot how, I think look in /etc/default/ambian* files. Else disable or mask the specific .service file.