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 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.

keys that promts with NO_PUBKEY errors can be manually retrieved like such use a keyserver e.g. https://keyserver.ubuntu.com/ key in the PUBKEY and search/retrieve the public key looks like this https://keyserver.ubuntu.com/pks/lookup?search=23F3D4EA75716059&fingerprint=on&op=index you can probably download that (an asc file, clicking on the pub link. That is the public key in an 'armored ascii' format and perhaps use https://8gwifi.org/pgpdump.jsp to dump/verify it again. the key (the .asc file) can be converted and installed for apt as in the prior comment.

I'm not sure if some hints from here may help, especially the initial post. it probably works if the public key is not expired (e.g. has no expiry dates).

hi Gunjan Gupta, thanks much! PREFER_DOCKER=no works in the systemd-nspawn Ubuntu Jammy 22.04 container that I created to run compile.sh for reasons I couldn't figure out, I did not manage to resolve the NO PUBKEY errors running in a docker container. but that the run proceed significantly without issues doing apt-get update, apt-get install and all with PREFER_DOCKER=no

I tried downloading the keys https://keyserver.ubuntu.com/pks/lookup?search=871920D1991BC93C&fingerprint=on&op=index and following this https://askubuntu.com/questions/1286545/what-commands-exactly-should-replace-the-deprecated-apt-key generated a gpg key file, placed it in /etc/apt/trusted.gpg.d the keys can be checked using apt-key list but that it didn't seem to fix the problem when run from a docker container. Apparently, the userid that docker build used to run apt-get update and apt-get install ... , is not root, and there are errors reading the gpg key files. It could be due to an older docker engine that I'm running. The docker client is from Ubuntu jammy 22.04

there is a different problem https://keyserver.ubuntu.com/pks/lookup?search=871920D1991BC93C&fingerprint=on&op=index Type bits/keyID cr. time exp time key expir pub (4)rsa4096/f6ecb3762474eda9d21b7022871920d1991bc93c 2018-09-17T15:01:46Z uid Ubuntu Archive Automatic Signing Key (2018) <ftpmaster@ubuntu.com> sig sig 871920d1991bc93c 2018-09-17T15:01:46Z ____________________ ____________________ [selfsig] sig sig 0bfb847f3f272f5b 2018-09-17T15:12:03Z ____________________ ____________________ 0bfb847f3f272f5b sig sig 7de50a8278ddc1f0 2021-12-06T22:39:23Z ____________________ ____________________ 7de50a8278ddc1f0 the public key used to sign the files is apparently expired. This is strange as then all the apt-get install commands will fail. edit: nope doesn't seem so https://8gwifi.org/pgpdump.jsp Key ID: 871920d1991bc93c Algorithm: RSA_GENERAL Fingerprint: f6ecb3762474eda9d21b7022871920d1991bc93c Encoded: 99020d045b9fc1da011000effc6c72b71fcb7125d8b8cd0cc0aa236c1c9ef35b341b59c4c7e973e95014a485199db92a7570470be770ac64bf09e78bb808cf44b53c028c44fe38ef655a7cc4518458761d925a97199fe025f3f97777c8501b591d910997c07c9bda4c1dffc041076c0be6338b3486e6de4c867a2dc34e382d7b5d104931dade89cf4386ae1fb9228c6a5fba598aae82bf5f41a216948a828c769ec44ba4587cdee897a1d22c596b317b557e1fe28e937d8f766154655e442f2428742c2793e421b9afc4189487b48999f654c7421084d31a0c75df75900636d9e1cf335179bd45a8d2d2564ad2fcf9ec010ccc846d410e6d9539217ae2379b2977df16a3392d74504dea932ec8d46dbaea47ab3f1823bc505ee37d48fa23bb5a2f2826b073bf243e23a4a442d206e95017da889c8bbee7a9c77916a2a2f7b0dd0b865308f34f9f03b193be83b1e2da6a565ce513a4da8d8bbe8df5b74293854b97b010c74bdba873c6c660fe0799bd36c0adc3fe3ac24a46686fe24368e80c9dc8743fdd957f7f75fd993dff48f2db25aba6920a7763377ab793de06ef99424fe637958d36e6a284d115ee595bd5986f634171bbd05577f04d974af3bb1a77ac88a70764d7d920a0ef0139c579305ee43fd9e4c3134bf41e51a7b64b998c6a300d99311d9412c5954ecdd642455697fd61052e929ad80429c39449ad0e2867f39f89f5f22733f6ee8d37c10011010001b4425562756e74752041726368697665204175746f6d61746963205369676e696e67204b657920283230313829203c6674706d6173746572407562756e74752e636f6d3e8902380413010a002205025b9fc1da021b03060b090807030206150802090a0b0416020301021e01021780000a0910871920d1991bc93c2c731000a4b6727c73ff959aa0239602b7f983a5076de38281ce43066d210ae1436565afe36eda19e8b708fb8bc340c62c25d977273976a13c9af8cc94e9a600a2a58f5b868374d809b4168d63de32704f65b9058246685c9effe8207b6d6461b75b07ce9b752d367e4980f03b027af10469ec345a665f58e908946deba1ab60d4713a1f55b0716e1adc90de19b5e2ef9befe71bd9bf722a2973ae8bc11764c6a7c9df60b2abed534b955a2090c6ec35b3886f8a6eeeaa08333840d960dcb1fba75e02ad1c406dce25be885182c578790aac21c74592e558e473cf8f62bc4eaa58e924def068746a9ac6d5157c64a6b2dca48ca67c95d5f00a9f87ccf5bca22f3400a2f0b42d9f4c30cb2b012ff8e40bc2dc810a4928632c59f55f57510a23baffb8e6644a19b40a79de191ff12301b22efc85536b06e999c1f21d040d6fdb6f8b638c502bcab85c2a11700f46fa9bf353d6155bb7119c36591a5d2ec0ec3bcfd3e44011792852a3583cf87c293e2baf98b46a68bc629e90605bf08ec403a529bcf82a03f41d234b752013f4374e9141cb357d4680404b73e831b2e73911851e29192667f9d1444fb3dd02310af38cbb05d638b7e5358dc488bc18f417607b2f044bef11a94a920a8bf7a40172ecd75edbbc51da0af99460dec9569d46326545c6121dc7a0859b77f11bc42335be6d7ab7bf62a2beb8e81c5e7cb5525c2d094ce5ad268f8902330410010a001d162104153f1c9ef1395fbf00352e8d0bfb847f3f272f5b05025b9fc443000a09100bfb847f3f272f5b6e170ffd1a069e820bc29f5e50a650016bce8e45e2404719c0c6968bdb6de92e48006c1600393ecf9938f0c070aa19e25918bcc042c18b73a5a44037a07b04023162e9fb5cce1e65011db64fb33dc4efa01cdfcd45017859063f0c2db7323913ac298299f4cff219eacca55c7807c58d6f93feb7db6d030c0047f94db39392de5a55e27930233bf103a5a7ab48162812fff6b73bb0bfaa59e2439d0124ab567f74d05b8085a4b43b6a7885c595d82360e5fec7544df356de2d50ed44ba0e53422442c14668e39bd28db1f3f76660cd9c5ee721346626758d99e6378b235174773091f8245410315daf4705f78512815196c82a1a1dd0014d10f97bfb8813248bd13f729bddd1341b6873d80f10d141d8048c26090c34836257cd9a94f8d862b6ecf99547b8b40881dfaac3f37acf02ed543828d8f73a157669aa64a34519ad05126ebfe5670c17803acb65d10968466e60441a7fc20b7ddc4d4087e409455b8c405ab3d273d9593c1f7066a099212ead688a5fc9f614562488b7f2516d37df94cdf3c67df7e82f43e03248016ef11793fe543300f44f3512e3a409397b516e333418a0125c6303f4b230083b50169a0b8f23528b7e75675e7b13e4960c6c6d8308b1c8fce22f9e946af2ff79e60959e4bf5aabc6cd9cec02d812ba31552ca5b251a462d0dbd85b787f239d13ce3d0f926f06b60bcfd94a805afcbe891a5e510da38b435c8901330410010a001d1621044b96e0121d08b6fc46eb2b0d7de50a8278ddc1f0050261ae911b000a09107de50a8278ddc1f093ea0800a8f6a80eb10e85c67b31c1625c4966cee868bbc802e3d97f53e8f261a6b6c6f5cebd7f2e3d1db064965d905411ff88911ccfab1af5311f62863e9bdcd70ccbb89dedd7ac3dede352109b3f3c7fbb9c4c899a6596ef7a9951d9c5d547e0cdf031f7e6aa1b1e0d26d595c33e119250fe3443675bd629679e2d321e760014eae0b4d368fad55a8bdbfe8995c9ba802f5989b22992dc98213ec963b3d17bfad7f393b0613abeb1c3dc055aa59a09eac5508c8e165bd6196844cd7be61fdd0b0b8534152018ba6d5d720b4472062fc88e94bc391c2db22b71d811a3ba8491b13fb404b7d52444e66bbddb4fef5e580170e0545a338dc450ffa93b30dcca21f86cfd8f Creation Time: Mon Sep 17 15:01:46 UTC 2018 Bit Strength: 4096 Has Revocation: false Has EncryptionKey: true Has MasterKey: true UserId: Ubuntu Archive Automatic Signing Key (2018) <ftpmaster@ubuntu.com>

got that NO_PUBKEY error again tried patching RUN DEBIAN_FRONTEND=noninteractive apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 871920D1991BC93C Into the Dockerfile (not directly but in the script https://github.com/armbian/build/blob/main/lib/functions/host/docker.sh#L276) (^a possible improvement may be: check if the Dockerfile exists, if not then generate it. This may help in cases of Dockerfile experiments, e.g. user edits, but that it is deemed 'do not edit') and run compile.sh again [3/9] RUN DEBIAN_FRONTEND=noninteractive apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 871920D1991BC93C: [🔨] 0.279 Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)). [🔨] 0.286 Executing: /tmp/apt-key-gpghome.gobsOrrUwl/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys 871920D1991BC93C [🔨] 6.301 gpg: connecting dirmngr at '/tmp/apt-key-gpghome.gobsOrrUwl/S.dirmngr' failed: End of file apparently, keyserver.ubuntu.com is down, does not respond to pings whatever, try again later.

The problem apparently is in the RUN apt-get -y update step in the dockerfile, and it happens during the initial build. It is observed after seperating the apt-get -y update step and the subsequent apt-get install step into 2 RUN commands. For reasons unknown, the same step run in a systemd-nspawn container used for the build works perfectly fine and completes in less than 10 secs. But that it fails while being run in the docker container during the build run by compile.sh turns out there is various network issues in the build docker container driven by compile.sh, need to figure out how to fix that there is no ping and ip command in the image, hence downloaded these using apt-get download iproute2_5.15.0-1ubuntu2_amd64.deb - this is /usr/sbin/ip and friends iputils-ping_3%3a20211215-1_amd64.deb - this is ping and dependencies libcap2-bin_1%3a2.44-1ubuntu0.22.04.1_amd64.deb libmnl0_1.0.4-3build2_amd64.deb libbpf0_1%3a0.5.0-1ubuntu22.04.1_amd64.deb libxtables12_1.8.7-1ubuntu5.1_amd64.de and use docker cp, copy them into the container https://docs.docker.com/engine/reference/commandline/cp/ from there run a shell (/bin/bash) and use dpkg -i to install them all docker run -it [armbian-ubuntu-jammy-latest image ID] /bin/bash root@cee6f1b4e249:/armbian# dpkg -i *deb then docker commit https://docs.docker.com/engine/reference/commandline/commit/ now there is a new image with /usr/sbin/ip and /usr/bin/ping docker network is 'hairy' (lots of pitfalls), edit lib/functions/host/docker.sh https://github.com/armbian/build/blob/main/lib/functions/host/docker.sh#L361 run docker build with --network host, to use the host network to work around some issues in addition use --add-host to work around some DNS issues. well partly as my ipv6 setup is goofed, ipv6 won't route properly in my setup, most likely a cause of the problems.

tried switching the base image to debian-bookworm, unfortunately a same issue appeared after some time during built [🔨] #6 [2/6] RUN echo "--> CACHE MISS IN DOCKERFILE: apt packages." && DEBIAN_FRONTEND=noninteractive apt-get -y update && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends bash git psmisc uuid-runtime bc binfmt-support bison libc6-dev make dpkg-dev gcc ca-certificates ccache cpio debootstrap device-tree-compiler dialog dirmngr dosfstools dwarves flex gawk gnupg gpg imagemagick jq kmod libbison-dev libelf-dev libfdt-dev libfile-fcntllock-perl libmpc-dev libfl-dev liblz4-tool libncurses-dev libssl-dev libusb-1.0-0-dev linux-base locales lsof ncurses-base ncurses-term ntpdate patchutils pkg-config pv qemu-user-static rsync swig u-boot-tools udev uuid-dev zlib1g-dev file tree expect colorized-logs unzip zip pigz xz-utils pbzip2 lzop zstd parted gdisk fdisk aria2 curl wget axel parallel python3-dev python3-distutils python3-setuptools python3-pip gcc-x86-64-linux-gnu gcc-aarch64-linux-gnu gcc-arm-linux-gnueabihf gcc-arm-linux-gnueabi gcc-riscv64-linux-gnu debian-archive-keyring libc6-amd64-cross g++-aarch64-linux-gnu g++ btrfs-progs cryptsetup openssh-client f2fs-tools nilfs-tools xfsprogs zerofree qemu-utils qemu-utils libudev-dev libusb-1.0-0-dev dh-autoreconf build-essential gcc-arm-linux-gnueabi gcc-or1k-elf qemu-utils [🔨] #6 0.996 --> CACHE MISS IN DOCKERFILE: apt packages. [🔨] #6 49.05 Ign:1 http://deb.debian.org/debian bookworm InRelease [🔨] #6 97.10 Ign:2 http://deb.debian.org/debian bookworm-updates InRelease [🔨] #6 145.2 Ign:3 http://deb.debian.org/debian-security bookworm-security InRelease ... [🔨] #6 481.4 Temporary failure resolving 'deb.debian.org' [🔨] #6 529.4 Err:2 http://deb.debian.org/debian bookworm-updates InRelease [🔨] #6 529.4 Temporary failure resolving 'deb.debian.org' [🔨] #6 577.4 Err:3 http://deb.debian.org/debian-security bookworm-security InRelease [🔨] #6 577.4 Temporary failure resolving 'deb.debian.org' [🔨] #6 577.4 Reading package lists... [🔨] #6 577.8 W: Failed to fetch http://deb.debian.org/debian/dists/bookworm/InRelease Temporary failure resolving 'deb.debian.org' [🔨] #6 577.8 W: Failed to fetch http://deb.debian.org/debian/dists/bookworm-updates/InRelease Temporary failure resolving 'deb.debian.org' [🔨] #6 577.8 W: Failed to fetch http://deb.debian.org/debian-security/dists/bookworm-security/InRelease Temporary failure resolving 'deb.debian.org' [🔨] #6 577.8 W: Some index files failed to download. They have been ignored, or old ones used instead. as i'm not sure how to define that correctly, i patched lib/functions/host/docker.sh docker_cli_prepare() declare -g DOCKER_ARMBIAN_BASE_IMAGE="${DOCKER_ARMBIAN_BASE_IMAGE:-"debian:bookworm"}" # declare -g DOCKER_ARMBIAN_BASE_IMAGE="${DOCKER_ARMBIAN_BASE_IMAGE:-"ubuntu:jammy"}" that managed to pick-up the Debian bookworm image, but the same resolving errors persists