eselarm

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'