I tried to run the image build process using Docker. At one point it tries to download the Linux tree and due to my slow Internet connection (max 3MB/s) there seems to be a connection reset from Github due to a too long download time (after 9 minutes, simillar times in 2 attempts).

 

✗ [         ...........](2.57 MB/s) Downloading linux-complete.git.tar                                     1.68/3.55 GB  47.34%  9m27s
  └─ sha256:dd18f1227c9bcf8d3a1c1ecd55721323639550c2845750f59168e17a0d0483bd                                                          
Error: failed to copy content to /armbian/cache/git-bundles/kernel/linux-complete.git.tar.oras.pull.tmp/linux-complete.git.tar: copy failed: stream error: stream ID 1; PROTOCOL_ERROR; received from peer

 

Is there any workaround besides switching to a faster Internet connection?

 

KERNEL_GIT=shallow (or was it GIT_KERNEL? Having hard times to keep that in mind correctly) but anyway, this will load a shallow tree with the corresponding kernel version only.

It is KERNEL_GIT=shallow, and this really helped (at least in the evening, when the 3MB/s were possible).

 

What I am now stumbling across are errors in tar and cp due to file ownership issues: I cloned the Armbian repo as plain user and am now running in Docker as root: I probably should have cloned the repo as root already ...

To follow up myself: somehow the Docker build does not work:

 

If I clone the repo as root, I cannot call "./compile.sh docker-shell", as the script cannot create directories in "build" then. I also cannot run the compile.sh as root, as the script is complaining then that I run docker as root / sudo.

 

So I have to clone the repo as plain user. Later I am running compile.sh in Docker, where I will be root. Many downloaded files will be owned by root then.

 

As soon as tar is run (by root) this tries to keep the old user and fails (workaround: add the option --no-same-owner, e.g. in kernel-git-oras.sh:217), I also have to remove the "-p" option from cp (e.g. kernel-config.sh:69).

 

But I am hit by a similar issue in the build process and are flooded with many error messages like these:

 

   GEN     kernel/kheaders_data.tar.xz
   tar: include/clocksource/samsung_pwm.h: Cannot change ownership to uid 0, gid 0: Invalid argument
   tar: include/clocksource/arm_arch_timer.h: Cannot change ownership to uid 0, gid 0: Invalid argument
   tar: include/clocksource/timer-davinci.h: Cannot change ownership to uid 0, gid 0: Invalid argument
   tar: include/clocksource/pxa.h: Cannot change ownership to uid 0, gid 0: Invalid argument
   tar: include/clocksource/timer-ti-dm.h: Cannot change ownership to uid 0, gid 0: Invalid argument
   tar: include/clocksource/hyperv_timer.h: Cannot change ownership to uid 0, gid 0: Invalid argument
   tar: include/clocksource/timer-xilinx.h: Cannot change ownership to uid 0, gid 0: Invalid argument
   tar: include/clocksource/timer-riscv.h: Cannot change ownership to uid 0, gid 0: Invalid argument
   tar: include/clocksource/timer-goldfish.h: Cannot change ownership to uid 0, gid 0: Invalid argument
   tar: include/trace/stages/stage6_event_callback.h: Cannot change ownership to uid 0, gid 0: Invalid argument

 

Docker seems to be recent (Docker version 29.6.2, build 1.fc44) - and I ran it according to the "Building with Docker" page:

 

me@localhost:~/BananaPro/repo/build$ ./compile.sh docker-shell BOARD=bananapipro BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=no EXPERT=yes KERNEL_CONFIGURE=no RELEASE=trixie KERNEL_BTF=no KERNEL_GIT=shallow

root@dbd99257d5cb:/armbian# ./compile.sh

 

The build directory is on a NFS share.

 

And something seems to be very much screwed up ...

Have you tried adding yourself to the docker group and run docker as your user?

 

https://docs.docker.com/engine/install/linux-postinstall/

Yes I have and I call compile.sh (and from it docker) as plain user. But inside docker I am root.

 

There are options to run Docker rootless or to change uid/gid. But as I did not read anything about this in the Armbian docs I have not tried such changes yet.

I moved the whole build directory from my nfs drive to an internal drive, changed all file ownerships as root to me:mygroup and voila: the build process ran through.

 

I do not know what caused the above problems: but it seems to be somehow related to having the tree on an nfs drive.

12 hours ago, loeriver said:

the tree on an nfs drive

see what is /etc/exports on the nfs-server

something like 

*(rw,no_root_squash,no_subtree_check)
should give more or less unrestricted access. 

 

And not to forget id-mappening for non-root, unless you manually made sure same uid gid for users

Edited July 31Jul 31 by eselarm

Thank you for the hint.

 

-/etc/exports on the nfs server is:  /volume1/documents    *(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

 

-the server's /etc/idmapd.conf has:

[Mapping]

Nobody-User = nfsnobody
Nobody-Group = nfsnobody

 

The uid/gid on nfs server and client do not match (server: 1026 / 100, client: 1000 / 1000).

 

I think I have to educate myself about the nfs setup (or work on the non-nfs disk) as this becomes not quite OT in this forum.