emk2203

@g4715, I am in the exact same situation. Hardware and software identical to yours. If you find a solution, please post it here. But I don't have SD cards old enough to see if one with the older specs works. I want use my HC4 as a disk copy / maintenance station, and the lack of hot boot is severely limiting.

If you want a quick solution, you can use my answer here. It's a dirty fix, but it works.

For everyone who might be interested in a not-so-quick fix to keep an older Armbian install running, here is what you can do until base-files become available for armhf: Download the latest base-files version of amd64 and armhf. Unpack with dpkg-deb -x base-files-xx.xx.xx_long_text_armhf.deb armhf and dpkg-deb -x base-files-yy.yy.yy_long_text_amd64.deb armhf_new in two directories armhf and armhf_new. Use diff -qr armhf armhf_new to test for differences. The file arm*/usr/bin/locale-check is different because different architectures, but the creation time shows that the content is the same. Copy it over: cp -a armhf{_new}/usr/bin/locale-check The lib64 symbolic link at the root of armhf_new and its target are unnecessary: rmdir $(readlink -f armhf_new/lib64) && rm armhf_new lib64 . Use dpkg-deb --control base-files-yy.yy.yy_long_text_amd64.deb armhf_new/DEBIAN to have the control files as well. edit armhf_new/DEBIAN/control to have line 4 read armhf instead of amd64. Remove the `lib64` words from /armhf_new/DEBIAN/*. Use grep -nrw armhf_new/DEBIAN -e lib64 to find them. Fix the md5sum with md5sum armhf_new/usr/bin/locale-check and edit armhf_new/DEBIAN/md5sums accordingly. Fix the ownership of the files and directories with sudo chown -R root:root armhf_new/* Build the new deb package: sudo dpkg-deb -b armhf_new base-files_yy.yy.yy.deb and install it: sudo dpkg -i base-files_yy.yy.yy.deb Upgrade formerly stuck packages like armbian-bsp-cli-odroidxu4-current: sudo apt update && sudo apt full-upgrade Clean up. It would really be easier to have an up-to-date version of base-files for armhf, but this has happened twice for me and at least once for another guy on the forum, so I hope the fix can be of help in the future.

It was an earlier Armbian release, I use `sudo apt update && sudo apt full-upgrade && sudo apt autoremove && sudo apt clean` to upgrade. I fixed the base-files issue already once manually for 24.5, but editing a deb package is a pita. i started with Armbian 24.2 iirc.

There seems to be some issue in the build process for armhf, since the base-files are missing again for 24.8.1. I am running an upgraded image of Ubuntu Noble on an Odroid HC1 (XU4 image): Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: armbian-bsp-cli-odroidxu4-current : Depends: base-files (>= 24.8.2) but 24.5.5-13ubuntu10-noble is to be installed I have looked around on some mirrors, but couldn't find a base-files package which is up-to-date. Any help on this issue?

@rpardiniThis testing image looks super promising. Basically everything from my wish list satisfied: stable MAC address boot from whatever is available via MTD/SPI sane boot order which allows for rescue interventions Only missing thing for me would be this image based on an Ubuntu userland, but it's just habit. Bookworm is not lacking in comparison. Going to test it out as soon as I can, but first I need to properly diagnose a Odroid HC4 HDMI bug for eventually RMA'ing the board.

Wow, thanks, these are great news! I wait until the 2023.10 release then. I cross my fingers, though -- in the ARM world, I have seen promising stuff delayed for ages or infinitely quite often.

What are the recommended steps to get the M1 boot from eMMC with the current standard Armbian image? Just skip spi boot, write image to eMMC as usual and boot without a µSD card? @usual userI would very much like to test your build and would also give feedback after. I have just discovered the M1 and I think it is necessary to have as many options as possible. There may be interest from others who, like me, are late to the game, but for this we would need to be able to replicate your build. From what you write, it sounds very promising so far. It would also open the door for more variety in the distributions offered.

OK, I solved the issue myself. Thanks to @Myron for his post, but it was much, much easier than that. I leave this up so the next one who makes a fool out of himself does at least know why. Solution: I used xzcat img/Armbian_22.02.1_Orangepizero_jammy_current_5.15.25.img.xz | sudo dd of=/dev/mmcblk0p1 bs=2M status=progress; sync to write the image. Out of habit, I used mmcblk0p1 instead of the correct mmcblk0. This is able to run as shown by the working ping, but it obviously botches the initialization process enough to not start the SSH server. After rewriting the image with xzcat img/Armbian_22.02.1_Orangepizero_jammy_current_5.15.25.img.xz | sudo dd of=/dev/mmcblk0 bs=2M status=progress; sync everything works as expected. I think it would be nice to have a command-line option in the manual, not just the reference to Balena Etcher or USBImager. With a command line, I wouldn't have had to resort to trial and error and choosing the wrong option (partition instead of full disk). I am not a fan of black-box programs like the above. If it's necessary to check the integrity of the written image, it's always possible to use head -c $(stat -c '%s' armbian.img) /dev/mmcblk0 | sha1sum or similar.

My OPi Zero is not accessible via SSH after installing the new supported image Armbian 22.02 Jammy. After the install, the device is up and ping-able. Any attempt to SSH in with `ssh root@<ip-address>` ends in a `ssh: connect to host 192.168.88.9 port 22: Connection timed out` error. When I reboot the board and try again, it's still the same issue. A ping with `ping 192.168.88.9` works. For completeness, I tried also with the edge instead of the current jammy image. Same error.