eselarm

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.

I assume OPi02w has no on-board storage, so it only is the bootcode in ROM, and that reads U-Boot binary blob from fixed sector offset location on the SD-card. It does not even need a MBR-table or GPT and it is not in a partition, so you won't see it. Only if you use dd to read (or write/wipe) that data you will know. See how U-Boot needs to be written for your OPi02w, then you will understand. If the U-Boot is build to initialize the USB and HDD, you do not need /boot partition on the SD-card. But I do not know that. Not all USB-SATA chipset drivers are in U-Boot, so if not, you indeed need a boot partition on de SD-card where kernel initrd DTB are, those should understand USB-SATA chips and so see the rootfs on HDD.

The bootlog-OK.txt shows: [ 10.796728] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read which is not good at all. I also think you think you still not have set verbosity=7 in armbianEnv.txt, else the both the OK and NOK logs would show more and that is needed as a start for further investigation.

That is at least the same base release (2024.01) from U-Boot as my Allwinner H3 boards, but old 32-bit ones. If it would be something like 2017.09 that would point to vendor legacy as older Rockchips might still use that. So I think you would need to look at live kernel logs at power-on and see where it stalls. It might be for example a swap in mmcblk numbers (SD-card v.s. eMMC), just an example. I have also seen many things related to powering as well, or some clock wrong (maybe too high for storage HW, whatever). USB serial console/debug cables cost about 1 euro nowadays, so I once just ordered 10-pack, standard connected one to most SBC's.

It would save you (and others) a lot of time if you would have a USB serial console/debug cable and with verbosity=7 in armbianEnv.txt I actually only got triggered because of 'Btrfs' in the topic title, but it might be a totally unrelated issue. Also note that besides the kernel provided .dtb file (is in /boot/dtb but and same file is also somewhere in /usr/lib/linux-image-<KVER> ), U-Boot has its own DeviceTree version/variant. Might be older, newer, broken, incomplete, vendor, mainline, patched, custom. So what U-Boot is loaded/used, also is important to know. Extract that info from SD-card where the U-Boot blob is written (sits at fixed sector offset, between partition table and 1st partition). You can look into U-Boot writing scripts to get to know the offset for Allwinner, but something like this is quicker:

@technik007_cz I see I also posted here, I initially thought the problem was in kernel or initrd or armbian scripts, but it turned out HW related (power). Is all sorted now and all understood and also situation for my ROCK3A is very different now. And also ROCK3A is Rockchip, BPiM2ultra is Allwinner. What is common it seems is that the storage device where the rootfs is on is unavailable to the kernel+initrd. If you have a running Armbian system and you do apt update && apt full-upgrade, you get new kernel and new u-boot if those packages are updated. BUT, the U-Boot blob is not written to storage device automatically, so this seems like a problem as I have had and seen various times before: older U-Boot and newer kernel. As you also it have a non-working with a pre-installed/pre-generated image, the problem is also there its seems. However, it needs more details. You need U-Boot log and kernel log posting here. Attach a serial console cable and set kernel loglevel to 7 Just for (my) reference, the board is this: https://wiki.banana-pi.org/Getting_Started_with_M2_Ultra_%26_Berry

I had similar experience, can't remember exact numbers and versions etc as I already considered it not going to work, so did not take notes. Was on NanoPi-R6C, so same RK3588S at least. I think I already had put 'serial' as console in the EDK2 setup (is in eMMC for NanoPi-R6C), but not the older display option (GOP or so, forgot it). For my trial it was just the kernel, so instead of the a latest edge-rockchip64 that works all fine with EDK2 v1.1 in my setup, it was the generic UEFI-ARM64 kernel. You use a full image, so I think something is missing or not implemented yet. Also, my main assumption was (and is), is that only serial console is working for a CLI image. I have always a serial console cable available/prepared, although you need an extra other computer, but your OPi5 should simply run, just display is not initialized. You can look in dmesg, there might be a lot of HDMI debug/info, might also be the kernel and your HDMI monitor experience miscommunication, timing issue. I rebooted again with 7.0-rc3 rockchip64 and that worked again. Now I did some apt pinning so I can install/use Debian sid kernel (6.19.11 at the moment). That works the same as the armbian build 7.0-rc3 rockchip64. Also Opensuse Tumbleweed with its default 6.19 kernel works fine.

You need the U-Boot source-code version; I at least cannot conclude on it; You can watch the start-up via serial console, then you will see. Or like this: root@rock3a:~# strings /dev/mtdblock0 | grep "U-Boot SPL 20" U-Boot SPL 2017.09-armbian (May 20 2024 - 00:46:51) I see you have 2 options: which U-Boot is used: mtdblock0 (the SPI-flash) or mmcblk0 (SD-card) ??

Log shows nothing about PCIE when 6.19.0-edge-rockchip64, it does when 6.18.8-current-rockchip64 If you just upgraded the kernel via apt, then this might be the point where an older U-Boot is incompatible with newer kernel. This is the case for all Rockchip devices I have and not strange. It is like it is, so if you want edge or newest or even standard Debian sid/unstable/testing kernel, you will need to look at that in more detail. I have been spending a lot of time on it, it is simply what you want or need. If you want all RK3588 silicon HW support, so like video encoders, stick to vendor based U-Boot and kernel. I you want a generic computer that is good enough for server tasks and web-browsing etc, use mainline based U-Boot and kernel. Of course something else might be wrong, but reporting U-Boot version would be needed and helpful first I think.

I have seen some kernel errors w.r.t. trim on Silicon Power 16GB SD-card, was in ROCK3A. But no other errors. Kernel is unspecified, although I might be able to figure out which/what, you can even search this forum, then you know yourself. This errors do not occur on a RPi4 v1.1 (with RPL OS and kernel). So if you want to know, dig more into logs, doe specialistic blocklevel error checking. In general: welcome to SD-card magic!. See also this:

Why repair the filesystem first while you anyway overwrite the whole storage device then? /dev/sdb1 suggests an USB SD-card adaptor is used. Both the adaptor, which translates USB protocol into MMC commands, and the SD-card itself, which also does internal block managing, can mess up the filesystem. Not as long as this is plugged into the computer where the imager (or dd) is running, but once removed and put into the SBC, power is lost and re-applied. The USB + SD-card hardware (and also OS driver in the computer) might have flaws in its implementation. It could easily be that SD-card signals 'ready' to OS, so you then take out USB + SD-card, but that actually not all is committed to the actual flash and still some is in buffers or the SD-card is still doing wear-leveling and doesn't do that in a correct way. And worse, if fake sized counterfeit, the firmware might be busy doing its 'magic tricks' to fake hundreds of GB size while only 8 or 32 GB is actual flash chip. So unfortunately, even if using a verify step in writing an image, the actual content on the SD-card might be different from the image file once the SD-card is put in the SBC. I remember such a case on this forum where someone did manual block-level compare of storage device and image. I also have had such issue at least once. It is the situation where you just re-do / re-write again without knowing what is wrong. And/or use other SD-card, other USB-adaptor, other computer, etc. To prevent such issues, I tend to use (the) SBC itself to write SD-cards. My RPI4 runs from USB-SSD, so SD-card slot is free. I trust RPL HW more than various USB SD-card adaptors. Earlier test I mentioned using the the Armbian-imager was on NanoPi-R6C running from eMMC+NVME, so same story, free SD-card slot. It ran Armbian Trixie KDE6 and 7.0-rc rockchip64 kernel. I was also forced to more or less, because on my Tumbleweed N100 box the Armbian Imager only stayed white (some EGL error). That was with x86-64 AppImage. I thought it would be better to install from a .deb hence walked to my powered-on ARM64 running Debian. Anyway I do normally not use images. I would rather use ddrescue (enable mapfile option) to check and make sure image is same as on storage device. That helped also in the past for 4TB HDD's (when risk of bit-rot). It is CLI based and allows to re-do check after power-cycle.

OK I see, now I remember, HAOS aarch64 has been there for download for a long time, I even recommended it to some one on another forum who also only saw the Intel VM, but as I indicated, is a bit hidden on github: https://github.com/home-assistant/operating-system/releases/ and direct latest link: https://github.com/home-assistant/operating-system/releases/download/17.2/haos_generic-aarch64-17.2.img.xz I personally don't want the Proxmox stuff indicated by Markus, I just use the standard packages available In Debian (or Opensuse) for years, on both Intel and Arm. Like indicated install virt-manager. It is manual install, but at least then more control. I used/use a mix of LVM based block devices and also just raw images (like unxz the one referenced). I see on RPi4 I have the HAOS VM configured with 2 vCPUs and 1GB RAM. On RK3588, so OPi5+, you will need CPU pinning if you use the vendor kernel (6.1) as it does not support mixing big and little (Cortex-A76 and Cortex-A55). Or use just 1 vCPU for the VM, then de-facto no mixing. Mixing is no problem with mainline based kernel, so then you can just use 8 vCPU's if you want. I currently have my NanoPi-R6C running with kernel 6.19.10+deb14-arm64-16k (from Debian sid) and works fine with VM's and all 8 cores.

I used it once as test. Good thing is it does verification. Hopefully that will help kill the counterfeit SD-card sales and various rubbish SD-card adapters. Bad thing (for me at least) is that there is some image caching option on by default. Good for saving excessive re-downloads, but I did not look how it works and where it is stored. I use differential backups, also via slow/expensive mobile links potentially, so don't want to wast bandwidth and volume on some cache image or chunk of data. To help people with images on this forum, I did run/boot various images as container, can be done with sudo systemd-nspawn -b -i <imagefile> (if rootfs in image is just 1 partition ) You need some working ARM64 computer of course, but that can be the old/running version of the one you want to upgrade. So I suggest you do that, or maybe the build environment cache cleaning fails (your setup). Also you involve an SD-card already. What if that card internal firmware messes up blocks. If you anyhow build image yourself, maybe use Btrfs as rootfs, also make sure U-Boot has option enabled, than you have much better ways to pin-point where the problem is. But you already did bold text for file dates I see, so I guess some caching issue somewhere.

/dev/mmcblk0p1 is a partition that contains the filesystem, not a drive. The drive is /dev/mmcblk0 and because you did a low-level sector by sector (or block by block) copy with dd, it also just has the exact same partition table (MBR-table or GPT). Now in modern Linux and various pre-installed images there are methods (possible) to expand the partition and the filesystem to occupy the whole remaining space. It is easier with MBR-table. If GPT, there is a backup GPT at the end of the disk, so in your case 64G. On the 128G SD-card the space after 64G is then hidden. I usually manage all this manually before first boot, with gdisk, not fdisk. As it is text based, it also works via remote ssh and serial console cable. I also deliberately added a dummy partition (number 3) to RPi images in the past so that the auto-expander could not claim the whole SD-card. If no GUI, a Linux install fits within a few GB, especially if you use Btrfs as filesystem for root and use on-the-fly compression (mount option compress-force=zstd). Then it is about 1GB needed, not 100x more.

If you want snapshots, you can also do it on filesystem level. Look at Btrfs and snapper. While testing HA 2 years ago, I also took the Intel VM image and made it work in a libvirt VM on an Atom J1900 board. Default size was 32G I think, way too big IMO. So I also took a clone of an existing Debian aarch64 VM (runs on RK3588 or BCM2711) and installed HA in there with supervisor method. I use Btrfs as filesystem, so do not take snapshot of VM image, but just Btrfs snapshot of the rootfs in that VM with HA. Also use Zstd compression, so much smaller than that 32G. But as a matter of fact, HA has good internal backup-restore, so that is also very useful, especially moving between Intel HA en Arm HA.

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.