September 11, 20251 yr Originally I tried to use DietPi and opened a bugreport there: https://github.com/MichaIng/DietPi/issues/7715 But DietPies support for the ZeroPi is based on armbian, so I tried this directly: oldest image not working: Armbian_community_25.8.0-trunk.338_Zeropi_bookworm_current_6.12.35_minimal.img.xz bootlog12.txt newest image working: Armbian_community_25.5.0-trunk.256_Zeropi_bookworm_legacy_6.1.104_minimal.img.xz bootlog13.txt Does anybody have an idea what it could be? Edited September 11, 20251 yr by TimoA
February 9Feb 9 The raised U-Boot version here is the culprit: https://github.com/armbian/build/commit/b8844c9 Maybe done by accident, since the commit/PR message does not mention the ZeroPi at all, or that it has been successfully tested on that board. Removing those two lines BOOTBRANCH="tag:v2025.04" BOOTPATCHDIR="v2025-sunxi" , reverting to U-Boot v2024.01 and respective patch dir, solves it for us. Of course, if someone finds time, it would be interesting to find out which missing patches or changes in upstream U-Boot are causing the issue. What I see in our logs is that the last starting and never finishing service is one which calls "udevadm settle", hence waits for udev rules to be processed, endlessly. The NanoPi NEO image boots on the board, but using the NanoPi NEO device tree on the ZeroPi image does not boot, which left only the bootloader as culprit. Maybe it puts some device into a bad state which causes the kernel/udev hang. Duplicate topic: Edited February 9Feb 9 by MichaIng
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.