ag123

agree with @Igor, supporting a board is a long term commitment and no easy feat. Those who are reading this thread should take it that there is no official Armbian release (not even 'community' nor 'unsupported') for this board (yet). The images tested prior to these comment includes: vendor's images some images created by 3rd parties (possibly including Armbian derivative) These are 'community efforts', attempts to run it on Orange Pi Zero 3 and is purely 'experimental'. But I'm hoping that we can build up enough *community* support and involvement for Orange Pi Zero 3 here. Note that for a supported board, it would call on the community for continuous maintenance and integration, as well as being involved in doing tests when new releases are made. Armbian isn't just supporting one single board after all. It'd also means that the community would need to support this effort financially as well, i.e. supporting Armbian. -- I've been (*messing*) experimenting with this board and I learned something, while one is messing with 'experimental' software, and 'experimental' boards e.g. this board. It is easy to think of it as a software problem. After all the experiments, it turns out some of my network woes I encountered are simply due to a defective network cable. But that said, there are 3rd party images or some such images there are broken in the software. issues with other (e.g. network) hardware are after all quite common e.g. in this case a problem with network hub, and in my case a defective network cable https://forum.armbian.com/topic/29954-sd-card-corrupt-after-hard-power-off/?do=findComment&comment=176561 i.e. there are so many blind spots when something doesn't work, and your hardware (including like cables, other hardware etc) should be in the checklist for troubleshooting.

I did one thing, changed the ethernet cable. Maybe I should have done that earlier now it looks different: I’ve just completed an Android apps update, Orange Pi Zero 3 is my Wifi hotspot, Orange Pi’s official ubuntu images released in Oct 23: orangepi@orangepizero3:~$ vnstat rx / tx / total eth0: today 413.90 MiB / 5.22 MiB / 419.12 MiB wlan0: today 4.24 MiB / 417.69 MiB / 421.93 MiB But that I only managed to configure a 2.4Ghz 802.11g wifi hotspot in the official images with hostapd. that is 40 Mbps. Throughput is decent, though i’m running at 100 Mbps at the ethernet end. 1 link drop, recovers on its own - it’s a new cable ! uptime 1 hour After replacing the cable with a new cable, link has been up 20 hours without ethernet completely freezing out, I'm still able to connect to the hotspot and use it normally after 20 hours. The above confirms that my ethernet woes are simply due to ethernet cable defect and not onboard hardware nor software. I’ve previously manually set the Ethernet to run at 100 Mbps via ethtool -s eth0 speed 100 , but that it is unknown why it sticks to 100 Mbps even across reboots. But for now I don’t think this is a defect, e.g. it could be due to my up stream hub etc. Hope that this paves the way towards eventually being supported in Armbian as well.

the SBC (single board computers) landscape is littered with *undeclared ethernet and wifi chips* (not given in specs when the boards are sold) they only tell you the SOC like H616, and that's it ! after you buy the board *undocumented ethernet and wifi chips* after you made a best effort attempt to find drivers *unsupported* spaghetti codes, that patches *undeclared hexidecimal commands that access *unknown* chip registers* for *unknown purpose* and *unknown functionality* with *unknown binary blobs* of *unknown versions* for *unknown hardware matches* it is a lottery if anything works at all

it is known that some boards may have defective ethernet PHY chips or possibly shorts on the PCB (e.g. pcb defects during soldering) say where the ethernet PHY are located. it is 'useless' to try to fix it in software if indeed it is a *hardware problem*, i.e. that the ethernet phy simply *won't work*. no amount of codes or fixes will fix that, one may need to 'throw the board away' and get a new one or get a different board with a different chip. https://github.com/MichaIng/DietPi/issues/6594#issuecomment-1827683215 ^ for the record in this test with the defective ethernet PHY chip. tested in 3 different distributions from 3 different sources did not fix the problem, each distribution is gigabytes of binaries in 3 different sd cards. after none stop round the clock days of different sets of tests and fixes, including like using 100 Mbps instead of 1 Gbps none of that fix the problem (of the defective ethernet PHY chip, to get the point across.

H618 is near 'bleeding edge' development as far as even kernels and even distributions is concerned. Orange Pi Zero 3 is one of those development boards that runs on H618 and even that is not (yet) supported in Armbian. There are developments at the 'bleeding edge' in 6.6 and above kernels as well as uboot in an attempt to support that board. And that that has a bad ethernet phy chip (but that is just my own experience, others may vary). A biggest touble is 'no 2 boards are configured in a similar way', e.g. just how a particular board boot is different between boards and even between different configuration on the same board. e.g. booting from emmc vs sd card practically is different on the same board. And for every different board there is a different dts (device tree), that alone may cause enough problems using an image on a board. The nearly only way left is to *build from source* and do *further developments* a 'difficult' endeavour.

@Shivan SpS yes there are problems with the UWE5622, various errors in dmesg. But for that matter, in my current tests, UWE5622 wifi has worked fairly ok https://github.com/MichaIng/DietPi/issues/6594#issuecomment-1827683215 In fact, running UWE5622 with the on board gigabit ethernet phy YT8531, I've achieved in excess of 100 Mbps (100 mega bits per seconds) throughput on this board. it is an eyebrow raiser (wow). this is done by running hostapd as a wifi hotspot. In the tests, i've transferred > 1 GB (1 gigabyte) across the wifi hotspot running on OrangePi Zero 3 from a phone running android apps update, and the link stays up after that. Unfortunately, the ethernet phy YT8531 is not stable (at 1 gbps). it (ethernet, not wifi) drops the link on reboot (not always though) and drops the link after some time even if it is idle. The tests are in the link above but in DietPi though. I'm currently repeating the same wifi hotspot tests but setting the ethernet link at 100 Mbps. I'm hoping to achieve a stable ethernet link. For a wifi hotspot, ether of the link (wifi or ethernet) breaks is a bummer, it defeats its purpose as a wifi hotspot. A wifi hotspot is probably a best connectivity tests for this board. This is a good board if the gigabit ethernet interface is stable.

you can try compile.sh PREFER_DOCKER=no note that the docs specify Ubuntu Jammy 22.04 https://docs.armbian.com/Developer-Guide_Build-Preparation/ I did this: the catch is, building it in a systemd-nspawn container cannot use loop devices, hence, the build will fail at building the image, but it does the other 90% compiling things. and fail to make the image at the end

Note that I've another thread here:

agree with @Igor, supporting a board is a long term commitment and no easy feat. those who are reading this thread should take it that there is no official Armbian release for this board (yet). These are 'community efforts', attempts to run it on Orange Pi Zero 3. But I'm hoping that we can build up enough *community* support and involvement for Orange Pi Zero 3 here. Note that for a supported board, it would call on the community for continuous maintenance and integration, as well as being involved in doing tests when new releases are made. Armbian isn't just supporting one single board after all. It'd also means that the community would need to support this effort financially as well, i.e. supporting Armbian. --- Board testing (Orange Pi Zero3) and many issues: For the record, I've tried using the board with the vendor's Debian (bookworm) images (it is an early image released in August 2023, there is a more recently release in Oct 2023). The scenario tested is setting up this Orange Pi Zero 3 as a Wifi hotspot. The distribution is running hostapd and for the record I managed to set up a 5Ghz 802.11ac hotspot on this little board. It clocked like in excess of 100 Mbps (100 mega bits per second) through the WiFI UWE5622 and the (gigabit) Ethernet interface. it is quite an 'eyebrow raiser' (wow). The trouble is there apparently (it seems) is some real hardware bugs/defects in the gigabit Ethernet chip, within less than a day the ethernet hardware stall on me, ethernet connection goes offline. And Network manager disabled the ethernet interface. I've had to manually re-enable that from network manager, and not just that, power cycle the board completely off, disconnect and re-connect ethernet cable in an attempt to restore it. It has become frustrating as this is becoming frequent, like less than an hour. -- edit: For those curious or is trying to reproduce the hostapd WiFi AP on Orange Pi Zero 3, the hostapd.conf is like such https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 -- edit: a session form a DietPi test distribution seemed to show the same hardware issue with the ethernet chip. https://github.com/MichaIng/DietPi/issues/6594#issuecomment-1827683215 -- just 2 cents: Orange Pi Zero 3 is still a 'significant' board, due to an updated Cortex A53 from Allwinnner H616 to H618, accordingly things are similar except that OrangePi Zero 3 is using LPDDR4 while OrangePi Zero 2 is using DDR3, and a different PMIC OrangePi Zero 3 supports up to 4GB memory (important for various apps), the performant gigabit ethernet and 5Ghz 802.11ac capable Wifi is a big plus. It makes this board perfect for a WiFi hotspot, pretty sure open source router distributions like OpenWrt would have noticed it. The trouble is I'm not sure if the ethernet chip (hardware) defect is after all true, that is a real bummer.

Linux 6.6 LTS release – Highlights, Arm, RISC-V and MIPS architectures https://www.cnx-software.com/2023/10/30/linux-6-6-release-highlights-arm-risc-v-and-mips-architectures/

agree with @Igor, supporting a board is a long term commitment and no easy feat. those who are reading this thread should take it that there is no official Armbian release for this board (yet). These are 'community efforts', attempts to run it on Orange Pi Zero 3. But I'm hoping that we can build up enough *community* support and involvement for Orange Pi Zero 3 here. Note that for a supported board, it would call on the community for continuous maintenance and integration, as well as being involved in doing tests when new releases are made. Armbian isn't just supporting one single board after all. It'd also means that the community would need to support this effort financially as well, i.e. supporting Armbian. --- Board testing (Orange Pi Zero3) and many issues: For the record, I've tried using the board with the vendor's Debian (bookworm) images (it is an early image released in August 2023, there is a more recently release in Oct 2023). The scenario tested is setting up this Orange Pi Zero 3 as a Wifi hotspot. The distribution is running hostapd and for the record I managed to set up a 5Ghz 802.11ac hotspot on this little board. It clocked like in excess of 100 Mbps (100 mega bits per second) through the WiFI UWE5622 and the (gigabit) Ethernet interface. it is quite an 'eyebrow raiser' (wow). The trouble is there apparently (it seems) is some real hardware bugs/defects in the gigabit Ethernet chip, within less than a day the ethernet hardware stall on me, ethernet connection goes offline. And Network manager disabled the ethernet interface. I've had to manually re-enable that from network manager, and not just that, power cycle the board completely off, disconnect and re-connect ethernet cable in an attempt to restore it. It has become frustrating as this is becoming frequent, like less than an hour. -- just 2 cents: Orange Pi Zero 3 is still a 'significant' board, due to an updated Cortex A53 from Allwinnner H616 to H618, accordingly things are similar except that OrangePi Zero 3 is using LPDDR4 while OrangePi Zero 2 is using DDR3, and a different PMIC OrangePi Zero 3 supports up to 4GB memory (important for various apps), the performant gigabit ethernet and 5Ghz 802.11ac capable Wifi is a big plus. It makes this board perfect for a WiFi hotspot, pretty sure open source router distributions like OpenWrt would have noticed it. The trouble is I'm not sure if the ethernet chip (hardware) defect is after all true, that is a real bummer.

Linux 6.6 LTS release – Highlights, Arm, RISC-V and MIPS architectures https://www.cnx-software.com/2023/10/30/linux-6-6-release-highlights-arm-risc-v-and-mips-architectures/

@Gunjan Gupta Thanks, I'd try that out. -- some news from the 'bleeding edge' https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-6.8 arm64: dts: allwinner: h616: add Orange Pi Zero 2W supportsunxi/dt-for-6.8 The Orange Pi Zero 2W is a board based on the Allwinner H618 SoC. It uses the RaspberryPi Zero form factor, with an optional expansion board, connected via an FPC connector, to provide more connectors. The base board features: - Allwinner H618 SoC (quad Cortex-A53 cores, with 1MB L2 cache) - 1, 2 or 4GB of LPDDR4 DRAM - SD card socket - two USB-C sockets, one UFP, one DFP - HDMI connector - (yet unsupported) WiFi module - 16 MiB SPI flash - power supply via the UFP USB-C port The FPC connector provides access to two more USB host ports, Fast Ethernet, some GPIOs, Audio Line out and the IR receiver pin. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20231020145706.705420-3-andre.przywara@arm.com Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> It seemed quite a lot of things are happening for h616, h618 (e.g. Orange Pi Zero 3, Zero 2W etc) at the mainline 6.6 kernel versions and beyond. But as seen in the various dts trees at the 'bleeding edge' https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/tree/arch/arm64/boot/dts/allwinner?h=sunxi/dt-for-6.8 UWE5622 Wifi isn't there in mainline. Hence, for UWE5622 Wifi drivers. it is from Armbian. a few other places where the UWE5622 driver codes are found seemed to be from orange-pi 6.1 kernel branch https://github.com/orangepi-xunlong/linux-orangepi/tree/orange-pi-6.1-sun50iw9/drivers/net/wireless/uwe5622 bigtreetech cb1 https://github.com/bigtreetech/CB1-Kernel/tree/kernel-5.16/kernel/drivers/net/wireless/uwe5622 it seemed the souce tree for all 3 sets of UWE5622 codes Armbian, OrangePi (2 branches 6.1 and 6.6), and Bigtreetech CB1 are after all 'similar'. But that there are various differences in some files, some updates are apparently possibly bug fixes. e.g. some of the commit logs here https://github.com/orangepi-xunlong/linux-orangepi/commits/orange-pi-6.1-sun50iw9/drivers/net/wireless/uwe5622 https://github.com/bigtreetech/CB1-Kernel/commits/kernel-5.16/kernel/drivers/net/wireless/uwe5622 https://github.com/orangepi-xunlong/linux-orangepi/commits/orange-pi-6.6-rk35xx/drivers/net/wireless/uwe5622 It'd be good to 'keep an eye' on fixes that goes into either one as there has been some reported issues for uwe5622, I've personally encountered some of that as I'm trying to setup a wireless hotspot with that. For now, the above are just 'for information', nice to know. And I think I should just try to make an image and try it out -- off-topic: I ran into some issues making an image, but it has nothing to do with the Armbian build process, It is simply because I'm running the build from within a systemd-nspwan container. systemd-nspawn do not support loop devices, which is a bummer to make images from within the container. Hence, I'd need to figure out how to make the images manually separately, but that that is still significant as compiling the kernel and building the raw image file (including all that apt-get pulls) is successful in the systemd-nspawn container

@Gunjan Gupta a teaser from here: 😉

it seemed during the 6.6 kernel build - UWE5622 driver is inlined in the 6.6.2 kernel, but that this is just the 'armbian' kernel, I'm not sure if it is there in mainline. edit: https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/tree/drivers/net/wireless?h=sunxi/for-next https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/tree/drivers/net/wireless?h=sunxi/fixes-for-6.7 https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/tree/drivers/net/wireless?h=sunxi/drivers-for-6.6 ^ well, didn't seem so, mainline didn't seem to explicitly list that Can't find the part number YT8531C, but that there is a tag for Allwinner devices, I'm not sure if that is included

https://linux-sunxi.org/Xunlong_Orange_Pi_Zero3 Feature Orange Pi Zero2 Orange Pi Zero3 SoC H616 H618 DRAM DDR3 LPDDR4 DRAM sizes 512MB/1GB 1/1.5/2/4 GB SPI flash size 2MB 16MB PMIC AXP305 AXP313a Ethernet PHY RTL8211F YT8531C wifi: https://www.cnx-software.com/2023/07/03/orange-pi-zero-3-allwinner-h618-sbc-ships-with-up-to-4gb-ram/ Dual-band WiFi 5 and Bluetooth 5.0 (CdTech 20U5622 module) with external antenna

some 'old' discussions across from linux sun-xi mailing list https://groups.google.com/g/linux-sunxi/c/p64EM9m9inY

still trying to figure out how to build Armbian and the kernel, it'd seem for "Orange Pi Zero 3", would need to go to the 'bleeding edge' 6.6 kernel to be closer to state-of-the-art.

some news related to Orange Pi Zero 3 u-boot: commit: https://source.denx.de/u-boot/u-boot/-/commit/4b02f0120a4bb2a5d7081aef8cef6a4ca57e9db2 https://source.denx.de/u-boot/u-boot/-/commit/fafedff35015c8cca7c537b68deb57b22c3ead73 er-em, this is at the .. far bleeding edge i.e. uboot source https://source.denx.de/u-boot/u-boot and like between 1 week to 1 month ago

some news related to Orange Pi Zero 3 context: https://lore.kernel.org/linux-arm-kernel/20230731011725.7228-1-andre.przywara@arm.com/T/#u [PATCH 0/3] sunxi: Orange Pi Zero 3 DT support @ 2023-07-31 1:17 Andre Przywara 2023-07-31 1:17 ` [PATCH 1/3] arm64: dts: allwinner: h616: Split Orange Pi Zero 2 DT Andre Przywara ` (3 more replies) 0 siblings, 4 replies; 8+ messages in thread From: Andre Przywara @ 2023-07-31 1:17 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland Cc: Icenowy Zheng, devicetree, linux-arm-kernel, linux-sunxi, linux-kernel Hi, Orange Pi recently released the Orange Pi Zero 3 board, which is some updated version of their former Zero 2 development board. Some component changes (Motorcomm PHY instead of Realtek, different PMIC), some board layout changes, and it ships with up to 4GB of DRAM now. The SoC is now labelled H618 instead of H616, which apparently is the same, just with more L2 cache. Split the existing OPi Zero2 DT, to allow sharing most DT nodes, then add the binding documentation and DT for the new board. Linux v6.5-rc boots out of the box (the PMIC driver just made it in), and most things work: UART, PSCI, GPIO, SPI flash, SD card, USB. Ethernet is almost working, I get an IP address via DHCP, but no further packets come through. Might be either a problem with the new Motorcomm PHY driver, or some missing delay settings, I have to investigate, any help or advice welcome. Also let me know if the DT split is a good idea or not, happy to roll that back if requested. Cheers, Andre Andre Przywara (3): arm64: dts: allwinner: h616: Split Orange Pi Zero 2 DT dt-bindings: arm: sunxi: document Orange Pi Zero 3 board name arm64: dts: allwinner: h616: Add OrangePi Zero 3 board support .../devicetree/bindings/arm/sunxi.yaml | 5 + arch/arm64/boot/dts/allwinner/Makefile | 1 + .../allwinner/sun50i-h616-orangepi-zero2.dts | 119 +--------------- .../allwinner/sun50i-h616-orangepi-zerox.dtsi | 131 ++++++++++++++++++ .../allwinner/sun50i-h618-orangepi-zero3.dts | 86 ++++++++++++ 5 files changed, 224 insertions(+), 118 deletions(-) create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zerox.dtsi create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts -- 2.35.8 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread * [PATCH 1/3] arm64: dts: allwinner: h616: Split Orange Pi Zero 2 DT 2023-07-31 1:17 [PATCH 0/3] sunxi: Orange Pi Zero 3 DT support Andre Przywara @ 2023-07-31 1:17 ` Andre Przywara 2023-08-03 21:05 ` Jernej Škrabec 2023-07-31 1:17 ` [PATCH 2/3] dt-bindings: arm: sunxi: document Orange Pi Zero 3 board name Andre Przywara ` (2 subsequent siblings) 3 siblings, 1 reply; 8+ messages in thread From: Andre Przywara @ 2023-07-31 1:17 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland Cc: Icenowy Zheng, devicetree, linux-arm-kernel, linux-sunxi, linux-kernel The Orange Pi Zero 2 got a successor (Zero 3), which shares quite some DT nodes with the Zero 2, but comes with a different PMIC. Move the common parts (except the PMIC) into a new shared file, and include that from the existing board .dts file. No functional change, the generated DTB is the same, except some phandle numbering differences. Signed-off-by: Andre Przywara <andre.przywara@arm.com> --- .../allwinner/sun50i-h616-orangepi-zero2.dts | 119 +--------------- .../allwinner/sun50i-h616-orangepi-zerox.dtsi | 131 ++++++++++++++++++ 2 files changed, 132 insertions(+), 118 deletions(-) create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zerox.dtsi diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts index cb8600d0ea1ef..c786b170fb9a8 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts @@ -5,95 +5,19 @@ /dts-v1/; -#include "sun50i-h616.dtsi" - -#include <dt-bindings/gpio/gpio.h> -#include <dt-bindings/interrupt-controller/arm-gic.h> -#include <dt-bindings/leds/common.h> ...

oops, building from within systemd-nspawn-container, at the end of it [🌱] Unmounting [ /home/armbian/build/.tmp/rootfs-7074b0dd-8f8a-4d2a-9eb5-2064fe133932 ] [🌿] Actual rootfs size [ 1638MiB ] [🌱] Preparing image file for rootfs [ orangepizero2 jammy ] [🌱] Current rootfs size [ 1638 MiB ] [🌱] Creating blank image for rootfs [ truncate: 2136 MiB ] [🌱] Creating partitions [ root: ext4 ] [🔨] Checking that no-one is using this disk right now ... OK [🔨] [🔨] Disk /home/armbian/build/.tmp/rootfs-7074b0dd-8f8a-4d2a-9eb5-2064fe133932.raw: 2.09 GiB, 2239758336 bytes, 4374528 sectors [🔨] Units: sectors of 1 * 512 = 512 bytes [🔨] Sector size (logical/physical): 512 bytes / 512 bytes [🔨] I/O size (minimum/optimal): 512 bytes / 512 bytes [🔨] [🔨] >>> Script header accepted. [🔨] >>> Created a new DOS disklabel with disk identifier 0x6335c2bb. [🔨] /home/armbian/build/.tmp/rootfs-7074b0dd-8f8a-4d2a-9eb5-2064fe133932.raw1: Created a new partition 1 of type 'Linux' and of size 2.1 GiB. [🔨] /home/armbian/build/.tmp/rootfs-7074b0dd-8f8a-4d2a-9eb5-2064fe133932.raw2: Done. [🔨] [🔨] New situation: [🔨] Disklabel type: dos [🔨] Disk identifier: 0x6335c2bb [🔨] [🔨] Device Boot Start End Sectors Size Id Type [🔨] /home/armbian/build/.tmp/rootfs-7074b0dd-8f8a-4d2a-9eb5-2064fe133932.raw1 8192 4374527 4366336 2.1G 83 Linux [🔨] [🔨] The partition table has been altered. [🔨] Syncing disks. losetup: cannot find an unused loop device: No such device [💥] error! [ Unable to find free loop device ] [💥] Exiting with error 43 [ at /home/armbian/build/lib/functions/logging/traps.sh:1 exit_with_error() --> lib/functions/logging/traps.sh:1 prepare_partitions() --> lib/functions/image/partitioning.sh:218 do_with_logging() --> lib/functions/logging/section-logging.sh:81 build_rootfs_and_image() --> lib/functions/main/rootfs-image.sh:80 full_build_packages_rootfs_and_image() --> lib/functions/main/default-build.sh:36 do_with_default_build() --> lib/functions/main/default-build.sh:42 cli_standard_build_run() --> lib/functions/cli/cli-build.sh:25 armbian_cli_run_command() --> lib/functions/cli/utils-cli.sh:136 cli_entrypoint() --> lib/functions/cli/entrypoint.sh:176 main() --> compile.sh:50 ] [💥] Cleaning up [ please wait for cleanups to finish ] [🌿] Unmounting recursively [ SDCARD - be patient ] [🌿] Unmounting recursively [ MOUNT - be patient ] [🌿] ANSI log file built; inspect it by running: [ less -RS output/logs/log-build-7074b0dd-8f8a-4d2a-9eb5-2064fe133932.log.ans ] [🌿] Share log manually (or SHARE_LOG=yes): [ curl --data-binary @output/logs/log-build-7074b0dd-8f8a-4d2a-9eb5-2064fe133932.log.ans https://paste.next.armbian.com/log ] armbian@snoopy1:~/build$ ls /dev console fd hugepages log net ptmx random stderr stdout urandom core full initctl mqueue null pts shm stdin tty zero well, this is an artifact / limitations of the systemd-nspawn container but that reaching here is pretty good, just that the last few steps (probably) needs to be manually done

oops, building from within systemd-nspawn-container, at the end of it [🌱] Unmounting [ /home/armbian/build/.tmp/rootfs-7074b0dd-8f8a-4d2a-9eb5-2064fe133932 ] [🌿] Actual rootfs size [ 1638MiB ] [🌱] Preparing image file for rootfs [ orangepizero2 jammy ] [🌱] Current rootfs size [ 1638 MiB ] [🌱] Creating blank image for rootfs [ truncate: 2136 MiB ] [🌱] Creating partitions [ root: ext4 ] [🔨] Checking that no-one is using this disk right now ... OK [🔨] [🔨] Disk /home/armbian/build/.tmp/rootfs-7074b0dd-8f8a-4d2a-9eb5-2064fe133932.raw: 2.09 GiB, 2239758336 bytes, 4374528 sectors [🔨] Units: sectors of 1 * 512 = 512 bytes [🔨] Sector size (logical/physical): 512 bytes / 512 bytes [🔨] I/O size (minimum/optimal): 512 bytes / 512 bytes [🔨] [🔨] >>> Script header accepted. [🔨] >>> Created a new DOS disklabel with disk identifier 0x6335c2bb. [🔨] /home/armbian/build/.tmp/rootfs-7074b0dd-8f8a-4d2a-9eb5-2064fe133932.raw1: Created a new partition 1 of type 'Linux' and of size 2.1 GiB. [🔨] /home/armbian/build/.tmp/rootfs-7074b0dd-8f8a-4d2a-9eb5-2064fe133932.raw2: Done. [🔨] [🔨] New situation: [🔨] Disklabel type: dos [🔨] Disk identifier: 0x6335c2bb [🔨] [🔨] Device Boot Start End Sectors Size Id Type [🔨] /home/armbian/build/.tmp/rootfs-7074b0dd-8f8a-4d2a-9eb5-2064fe133932.raw1 8192 4374527 4366336 2.1G 83 Linux [🔨] [🔨] The partition table has been altered. [🔨] Syncing disks. losetup: cannot find an unused loop device: No such device [💥] error! [ Unable to find free loop device ] [💥] Exiting with error 43 [ at /home/armbian/build/lib/functions/logging/traps.sh:1 exit_with_error() --> lib/functions/logging/traps.sh:1 prepare_partitions() --> lib/functions/image/partitioning.sh:218 do_with_logging() --> lib/functions/logging/section-logging.sh:81 build_rootfs_and_image() --> lib/functions/main/rootfs-image.sh:80 full_build_packages_rootfs_and_image() --> lib/functions/main/default-build.sh:36 do_with_default_build() --> lib/functions/main/default-build.sh:42 cli_standard_build_run() --> lib/functions/cli/cli-build.sh:25 armbian_cli_run_command() --> lib/functions/cli/utils-cli.sh:136 cli_entrypoint() --> lib/functions/cli/entrypoint.sh:176 main() --> compile.sh:50 ] [💥] Cleaning up [ please wait for cleanups to finish ] [🌿] Unmounting recursively [ SDCARD - be patient ] [🌿] Unmounting recursively [ MOUNT - be patient ] [🌿] ANSI log file built; inspect it by running: [ less -RS output/logs/log-build-7074b0dd-8f8a-4d2a-9eb5-2064fe133932.log.ans ] [🌿] Share log manually (or SHARE_LOG=yes): [ curl --data-binary @output/logs/log-build-7074b0dd-8f8a-4d2a-9eb5-2064fe133932.log.ans https://paste.next.armbian.com/log ] armbian@snoopy1:~/build$ ls /dev console fd hugepages log net ptmx random stderr stdout urandom core full initctl mqueue null pts shm stdin tty zero well, this is an artifact / limitations of the systemd-nspawn container but that reaching here is pretty good, just that the last few steps (probably) needs to be manually done

@Gunjan Gupta Thanks, and a new guide/tutorial Building Armbian using Ubuntu (jammy) in a systemd-nspawn container https://gist.github.com/ag88/05245121cce37cb8f029424a20752e35

Building Armbian using Ubuntu (jammy) in a systemd-nspawn container https://gist.github.com/ag88/05245121cce37cb8f029424a20752e35 Special thanks goes to @Gunjan Gupta for the tip on PREFER_DOCKER=no

thanks Gunjan Gupta, yeah, I'd need to upgrade the distribution, has posponed it for a very long time. A trouble is I've got a lot of other stuff installed in the same system, though in different partitions / filesystems. An upgrade would likely break quite a few stuff, hence I'd need to schedule that.