eselarm

Here your debugging activity will need to start. There is an awful lot of things unknown, to others on this forum but more important, also to yourself. It could already be that your server (Armbian) has nothing to do with it, but that it is the info in your router (even caching stuff) that has refreshed, simply because you probably restarted, so something was not 'reset proof'. I have seen many of such things myself in my house/home networking and in conjunction with various ISP's (also mobile4G). Which made me use my own (open-source) router instance for example, so I can at least check all what is needed in such case as you have. But it might be simple, you can use wget (do 'man wget' first to see all options) to mimic browser behavior and that should already say something. If docker etc is involved, make sure you understand all (virtual) networking, it can get very complex. I haven't seen potentially disturbing things from Armbian 26.2.1, but I removed/blocked also several things, like no netplan.io, that at least works on Debian Trixie based installs. There have been lots of security related updates in Debian recently, so make sure you log and see changes to packages (edit listchanges.conf)

This topic is 2 years old and HA formally does not support supervised anymore. And doing 2 such modifications and then hoping all will be fine is false hope IMO. If you don't have a serial console cable to watch kernel en journal log etc to see what your system is doing, maybe it is time now to get one. I have an old supervised inatsllation (not use for many months, but it is plain Debian and a VM so I have free/easy CLI console.

What U-Boot/bootloader is in the MTD?

I just checked at my ROCK5B running Armbian userspace: # sudo apt update # sudo apt list -a linux-headers-*current-bcm2711 linux-headers-current-bcm2711/trixie 26.2.1 arm64 linux-headers-current-bcm2711/trixie 25.11.2 arm64 linux-headers-current-bcm2711/trixie 25.8.2 arm64 linux-headers-current-bcm2711/trixie 25.8.1 arm64 linux-headers-current-bcm2711/trixie 25.5.1 arm64 linux-headers-current-bcm2711/trixie 25.2.3 arm64 linux-headers-current-bcm2711/trixie 25.2.2 arm64 linux-headers-current-bcm2711/trixie 24.11.1 arm64 linux-headers-current-bcm2711/trixie 24.8.2 arm64 linux-headers-current-bcm2711/trixie 24.5.1 arm64 linux-headers-current-bcm2711/trixie 24.2.1 arm64 So you can install them with: # sudo apt install linux-headers-*current-bcm2711 You will get the latest if you do not select explicit version 6.18.9, I got 6.18.10 as that seems to be the latest now. Armbian also has edge and legacy, but for normal release all 64-bit Raspberry Pis is named 'current-bcm2711', which should be the equivalent of 'rpi-v8', which is the normal 4k pages downstream kernel in Raspberry Pi OS 64-bit. It might be you originally had the dedicated rpi5b installation, so you simply had not gotten the headers maybe. Armbian has no 16k pages kernel, if you want that, you need to build yourself, but note that this comes with quite some of issues, many people are not aware and cannot fix issues due to that. See 2+ years of trouble w.r.t. that on RPL forums. I do not use Ubuntu based Armbian, but Debian based, but should not matter for that kernel packages as those are Armbian on top of either distro.

I think most important is that people make sure they can fix their own issues if a HW/computer fails. I found high-availability interesting, but for just my house (or even 2 places/countries at the same time) I found it too much to make it all work. The thing I could maybe use is DRDB, however I see v9 is under development since 2011 and it still is not in mainline kernel. Compared to that I have some script to transfer latest differential Btrfs snapshot from 1 computer to the other on-the-fly, I doubt I can really benefit from DRDB, but maybe I set up a test and see what it does. I use only ARM64 for 24/7 servers, so no x86_64 <=> ARM64 incompatibility. So same as for ZFS for example, it is external to Linux distro and my experience is that complicated issues/failures always happen at the wrong moment, e.g. also no internet and/or mains power failure etc. So I try to minimize the amount of 'external' HW/SW modules, certainly if the backing company is commercial and in whatever country far away from where I am. Proxmox is nice, but also 'external'. Same for even Docker, so I have actually no such containers. But it all depends on how much you are involved in various HW and SW. As you can see in my earlier message, I already forgot HA was available as generic aarch64 image, so that says enough. I use several custom (own) HW (like 'changed' solar inverter) and HomeAssistent does not support it, so I actually do not really use it. It is mostly C-code and Node-RED in conjunction with various micro-controllers. A good test is to disconnect internet (power-off fiber-RJ45 box in my case) and/or also do an ad-hoc power cut (no cheating with UPS). And then see if you can get it all running again within a certain time frame (what you think is acceptable, like before temperature in freezer gets > -10 or so).

I see it is this board, quite new: http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-4A.html You can see at https://github.com/armbian/build/commits/main/config/boards/orangepi-4a.csc that no manintainer is defined, so up to yourself to figure out what is wrong. You need to start with attaching a serial debug cable (see 3 pins next to power key) Also I see this board has SPI-flash, there might be an old U-Boot variant in there that does not work together with mainline based 7.0.x kernel.

I have just cleaned-up / changed (again) things w.r.t. network names for my Nanopi-R6C. Same as Nanopi-R4S, it has 'wan' and 'lan', where wan is on-chip ethernet and lan is external PCIe connected. Double check for the R4S, but I am almost sure. So a mainline kernel in principle just numbers them eth<x> depending on timing and other things. New kernel behavior is that the on-chip gets named end0 and for my Nanopi-R6C the external gets named enP3p49s0, as that represents how it is HW connected via PCI-e. That is 7.0.<x-flavor> generic distro kernel. Then Armbian has 2 udev rules to rename to wan? and lan?. That is where the problem was and is for me as I use various different bootloader/firmware. I removed those udev rules as I run standard main distros as well and I need the names for bridges and vlans etc future proof and I don't care about names wan and lan (not using it as router). But if you want to keep that naming, check bootloader version (U-Boot I guess for you) and also udev rules and maybe other patches for RK3399 and/or R4S.

You know there is a fruit company in Cambridge UK that is proud to tell they have sold 75 million pieces and 75% is to non-noobs. They provide passwordless sudo by default and a self-modifying rpi-update script by default in their OS. So why so complicated with this copy-fail exploit, every script kiddy had and has an easy task of keeping the noobs on a leash for more than a decade.

I see it like who is motivated to check and do the work w.r.t U-Boot. Especially while EDK2 UEFIv1.1 is available already a year and at least for my ROCK5B and NanoPi-R6C with both Armbian rockchip edge kernels as well as standard Debian arm64 kernels works OK. We call those things 'firmware' but the 'firm' selling this OP5 HW is not delivering this. Good thing is that it is all open source at least. For the ROCK5B I also used it in 'vendor' mode, so 6.1.115 works and so video encoders as well (for Jellyfin). For NanoPi-R6C (RK3588S, same as OP5) it is in the on-board eMMC, that is some disadvantage compared to SPI and more as SD-card. So not sure how OP5 will deal with it.

There will be no fix if it is not clear what exactly needs to be fixed I would say. I guess you need to dig deeper yourself. You can build U-Boot independent of Armbian if you want, maybe less reading initially, still the testing/debugging is what matters.

Yes that is what it seems. But strange that mainline kernel+DTB gets it right and 2026.04 U-Boot not. You need to look into the build-config of this U-Boot for the OP5 then I think. All PCIe NVME needed for boot might be there, but still other factors might determine fail or success. Maybe timing at power on, some power line or other signal not enabled. You could flash https://github.com/edk2-porting/edk2-rk3588 into SPI and see if you can boot mainline based kernel with that with just SPI and NVME. Maybe other things don't work then, but depends on what the board should do. You need to add or already have an extra EFI type FAT formatted partition with that, usually done manually and also installing grub-efi package and installing all that manually. Also you may want to add loglevel=7 to kernel command line, then you see what is happening after 'Starting kernel'

What happens after that? Do you see PCIe getting activated? Is the NVME SSD enumerated? What brand and type of NVME?

You need to look into github changes then, everything is traceable, but certainly not an easy and quick thing to do.

What you prefer or think is best. An extra boot partition is more flexible as it is an extra 'boot-stage' sort of, and normal computers that use UEFI anyway need also a FAT formatted bootpartition besides 1 or more rootfs for (multiple) OS. So not a bad approach to have separate boot partition an if on SD-card, is removable, so is flexible in case of trouble and/or testing things.

Both logs show initial timestamped text, then the same again non-timestamped. That is something fundamentally wrong. You can de-compile and compared DTB files but it might not reveal why it fails. Btrfs might by just un-related. I see in the NOK log a disabling of an LDO, might be on purpose but also because code is just corrupted somehow. I do not have this BPIM2U board, so no way to see if same would happen for me. Hope someone else can reproduce, else use older kernel that does not fail.