Hi All

 I've made for my sbc image, however found during this process  messages including 1 marked as error :

 

```

Error response from registry: failed to fetch the content of "ghcr.io/armbian/os/armbian-bsp-cli-bananapipro-current:1-PCc91e-V4b00-H9299-B1e5d-Rf36a": ghcr.io/armbian/os/armbian-bsp-cli-bananapipro-current:1-PCc91e-V4b00-H9299-B1e5d-Rf36a: not found

```

some repeatible during the process:

```

gpg: WARNING: unsafe ownership on homedir '/home/bask/.gnupg'

/usr/bin/deb-systemd-helper was not called from dpkg. Exiting.
/usr/bin/deb-systemd-helper was not called from dpkg. Exiting.
invoke-rc.d: unknown initscript, /etc/init.d/iperf3 not found.

```

and finally filtered from log:

```

filtered from log  @output/logs/log-build-322ed1c8-a4db-4873-85ac-be8e6a87fbd6.log.ans
Error 3 occurred in main shell /home/bask/Dokumenty/build/lib/functions/configuration/menu.sh:38
  dialog_if_terminal_set_vars() --> lib/functions/configuration/menu.sh:38
  interactive_config_ask_board_list() --> lib/functions/configuration/interactive.sh:149
  config_possibly_interactive_kernel_board() --> lib/functions/main/config-interactive.sh:16
  prep_conf_main_build_single() --> lib/functions/main/config-prepare.sh:21
  cli_standard_build_run() --> lib/functions/cli/cli-build.sh:22
  armbian_cli_run_command() --> lib/functions/cli/utils-cli.sh:136
  cli_entrypoint() --> lib/functions/cli/entrypoint.sh:176
  main() --> compile.sh:50

```

Not sure if I should worry or it is handled somehow?

I'll try an expert mode as there was not too much to configure and verify

Second thing: 90 mins for this process is normal? I was doing it on newly installed Ubuntu (directly on the disk in dual mode so whole HW available for it)

 

Excerpts are often useless. Provide full logs using the curl command from the end of each run.

5 minutes ago, Cancer said:

g: 90 mins for this process is normal?

If the used hardware isn't very powerful, yes, can be.

HP Pavilion8 core processor, 32Gig RAM  laptop.

I wanted to limit information to limit time for digging into it, but here they are:

 

log-build-322ed1c8-a4db-4873-85ac-be8e6a87fbd6.log.ans summary-build-322ed1c8-a4db-4873-85ac-be8e6a87fbd6.md

What's wrong with just using the curl command? It will upload the logs to one of our paste servers and it will be nicely formatted and colorful. Way easier to read.

Here it is:

https://paste.armbian.com/ququgojasu

 

Works well on my side - could not reproduce (with Docker based compilation), but however there is a (common to a20 boards) problem with HDMI output while boards otherwise works.

My setting was without docker and I was not using it.

I was observing shell output, and because I selected version without desktop (on which HDMI could affect) while there were some desktop components additions during script processing. Small remark: I use sbc as server with good quality server 1TB 2,5"drive.

1 hour ago, Cancer said:

without docker

This is not recommended as its not controlled environment. It might work, but no warranties.

 

1 hour ago, Cancer said:

I selected version without desktop

 

HDMI output is broken in general (on this particular SoC) regardless of variant, desktop, cli, minimal. Its known bug, but we currently don't have anyone maintaining Allwinner A20 series so its up to random person to fix this. Code is open, so anyone can.

 

1 hour ago, Cancer said:

I use sbc as server

Then it should be o.k. since HDMI output is not needed.

Thanks, all's clear

Just now, Igor said:

anyone maintaining Allwinner A20 series so its up to random person to fix this

I might be such random person lol. However it would need either a lot of time or information delivered when it has been broken; open code is nice but there are too many kernel versions and distributions. That matter would need some deeper conversation. I think you was the person managing this area so maybe you know where to search the issue to correct it or you know the person who might know.

I'm affraid I found the reason of long image generation time: my laptop fans are to silent today and it might be the reason...

Alright, let's give  a real quick overview where the code for A20 comes from. Let's focus on current.

 

First stop. Board config: https://github.com/armbian/build/blob/main/config/boards/bananapipro.csc -> BOARDFAMILY="sun7i"

Next stop. Family config: https://github.com/armbian/build/blob/main/config/sources/families/sun7i.conf -> No sources defined. However there are includes.

Next stop. Includes: https://github.com/armbian/build/blob/main/config/sources/families/include/sunxi_common.inc -> No kernel source URL defined. Therefore kernel comes from mainline (kernel.org to say). However a version is tagged: v6.12.43

So we know: Linux source comes from unmodified mainline and the version is 6.12.43

 

Next stop. Patches: https://github.com/armbian/build/tree/main/patch/kernel/archive/sunxi-6.12 ->  vendor family = sunxi, kernel major.minor is 6.12

All these patches are applied on top of the kernel source from kernel.org. And yes, that's a lot. I think sunxi is the worst family regarding number of additional patches to make stuff work.

 

Next component is u-boot.

https://github.com/armbian/build/blob/main/config/sources/families/include/sunxi_common.inc -> BOOTBRANCH:-"tag:v2024.01" so uboot is tagged to this version.

So we know: U-Boot source comes from unmodified mainline and the version is v2024.01.

And BOOTPATCHDIR="${BOOTPATCHDIR:-"u-boot-sunxi"}" which means here we find the patchset put on top of that version. Let's check.

https://github.com/armbian/build/tree/main/patch/u-boot/u-boot-sunxi -> folders starting with board_ are applied only if the target board is being built. All remaining paches are always applied.

 

There are more definitions of stuff appling for multiple families, whole architectures or even all boards regardless of architecture but in this case they are not important. Just including for the sake of completion/information:

https://github.com/armbian/build/blob/main/config/sources/armhf.conf

https://github.com/armbian/build/blob/main/config/sources/common.conf

 

 

Good luck.

 

11 hours ago, Cancer said:

However it would need either a lot of time or information delivered when it has been broken

When things are not actively monitored, features stopped working without knowing. This has to be find out.

 

11 hours ago, Cancer said:

too many kernel versions and distributions

 

At least all Armbian distributions have the same kernel, regardless of its upstream origin - Debian X,Y,Z and Ubuntu A,B,C ... have same kernel. But of course kernels versions go up all the time.

 

11 hours ago, Cancer said:

I think you was the person managing this area so maybe you know where to search the issue to correct it or you know the person who might know.

 

I am not managing this that deep / specific. Where to search? On this forum. I am sure that this was already brought up.

6 hours ago, Igor said:

When things are not actively monitored, features stopped working without knowing. This has to be find out.

As I understood they are not tested, am I right?

Yes, csc boards are not actively monitored. Build test only.

OK, how should i understand build test?

Our CI produces automated builds which are published here: https://github.com/armbian/community/releases

If a build fails we will notice and fix if it doesn't much effort. Otherwise it's demoted to EOS and autobuilds disabled.

ok , so no special procedure exists.

There is only minimal image is accessible for download for bpi pro. Does It mean all other failed or nobody tried to build them? Random images are accessible from archive too.

What does "CI" stand for?

There is usually only one or two images built per board. That's enough to make sure it compiles properly. All other combinations can be made DIY with the framework, check documentation.

Continous Integration  https://en.wikipedia.org/wiki/Continuous_integration

 

ok, thx

3 hours ago, Werner said:

All other combinations can be made DIY with the framework, check documentation.

 

Or simply add whatever packages you desire with apt.