Jump to content

[Q] armbian-build-system: created different cpu-packages at once?

Go to solution Solved by Werner,

Recommended Posts

Today I did compile for some SBCs the kernel 5.9.1 dev but had something strange - for me - 


When I did compile for sunxi I also did get a .deb for sunxi64 and

a new sunxi when I did compile for a sunxi64 board.



as last I did compile for the Odroid C2 (meson64) and I also did get the sunxi and sunxi64 .deb-packages.

Is this normal or a new bug? Because in the past I did only get a new .deb-package for the platform which I did actually compile for.



Link to comment
Share on other sites

  • guidol changed the title to [Q] armbian-build-system: created different cpu-packages at once?

I can confirm, there is new bug in build system.

I tried with clean build system just cloned from git, and here is the result in build/output/debs which was empty (not existing) before build run:

2020-10-31 07:51:45 Executing: ./compile.sh BOARD=orangepione USEALLCORES=yes BRANCH=current KERNEL_ONLY=yes KERNEL_CONFIGURE=no
2020-10-31 08:18:36 Created:
    file: -rw-r--r-- 1 root root     43716 2020-10-31 08:17:33.152639730 +0100 armbian-config_20.11.0-trunk_all.deb
    file: -rw-r--r-- 1 root root 139643152 2020-10-31 08:18:35.516980290 +0100 armbian-firmware-full_20.11.0-trunk_all.deb
    file: -rw-r--r-- 1 root root   6915836 2020-10-31 08:17:44.032001230 +0100 armbian-firmware_20.11.0-trunk_all.deb
    file: drwxrwsr-x 2 root sudo      4096 2020-10-30 10:23:38.957016051 +0100 extra
    file: -rw-r--r-- 1 root sudo     77852 2020-10-31 08:17:31.440740205 +0100 linux-dtb-current-sunxi64_20.11.0-trunk_arm64.deb
    file: -rw-r--r-- 1 root sudo    192228 2020-10-31 08:17:31.400742552 +0100 linux-dtb-current-sunxi_20.11.0-trunk_armhf.deb
    file: -rw-r--r-- 1 root sudo     58208 2020-10-31 08:17:31.440740205 +0100 linux-dtb-legacy-sunxi64_20.11.0-trunk_arm64.deb
    file: -rw-r--r-- 1 root sudo    182012 2020-10-31 08:17:31.440740205 +0100 linux-dtb-legacy-sunxi_20.11.0-trunk_armhf.deb
    file: -rw-r--r-- 1 root sudo  11261392 2020-10-31 08:17:31.488737387 +0100 linux-headers-current-sunxi64_20.11.0-trunk_arm64.deb
    file: -rw-r--r-- 1 root sudo  11382152 2020-10-31 08:17:31.460739031 +0100 linux-headers-current-sunxi_20.11.0-trunk_armhf.deb
    file: -rw-r--r-- 1 root sudo  11008696 2020-10-31 08:17:31.544734101 +0100 linux-headers-legacy-sunxi64_20.11.0-trunk_arm64.deb
    file: -rw-r--r-- 1 root sudo  11089428 2020-10-31 08:17:31.516735744 +0100 linux-headers-legacy-sunxi_20.11.0-trunk_armhf.deb
    file: -rw-r--r-- 1 root sudo  33151948 2020-10-31 08:17:31.688725650 +0100 linux-image-current-sunxi64_20.11.0-trunk_arm64.deb
    file: -rw-r--r-- 1 root sudo  35331128 2020-10-31 08:17:31.604730580 +0100 linux-image-current-sunxi_20.11.0-trunk_armhf.deb
    file: -rw-r--r-- 1 root sudo  34922552 2020-10-31 08:17:31.856715790 +0100 linux-image-legacy-sunxi64_20.11.0-trunk_arm64.deb
    file: -rw-r--r-- 1 root sudo  34758916 2020-10-31 08:17:31.772720720 +0100 linux-image-legacy-sunxi_20.11.0-trunk_armhf.deb
    file: -rw-r--r-- 1 root root 403306604 2020-10-31 08:17:29.904830351 +0100 linux-source-current-sunxi_20.11.0-trunk_all.deb
    file: -rw-r--r-- 1 root root    228852 2020-10-31 07:52:49.533361612 +0100 linux-u-boot-current-orangepione_20.11.0-trunk_armhf.deb
2020-10-31 08:18:36 Built in 0d 0h 26m 51s: orangepione,current


Link to comment
Share on other sites

Definitely is an issue.

For very long time i use build script to build kernel for several orange pi boards, and allways the result was 8 debs for each board: source, dtb,  headers, image,  u-boot, armbian-firmware, armbian-firmware-full, armbian-config.

Now something went terribly wrong, I become whole bunch of debs which are unrelated to my target.



Link to comment
Share on other sites

@IgorS at at 2nd run I could not reproduce anymore. Before starting the same build again make sure

  • to run  git pull beforehand to get master up to date
  • rm -rf cache/*
  • rm -rf output/*

ATM I assume some improper cleanup after building...


Link to comment
Share on other sites

33 minutes ago, IgorS said:

@Werner thanks for advice, but I got a whole bunch of debs at first build, after I deleted build directory and created it fresh from git.
It can't be a problem with any 'leftovers' because everything was fresh.

That's the point where it does not make sense anymore since I could solve this by clearing my folders beforehand. I have no clue why you still run into this issue with a clean pull...

I'll do some more testing.


Edit: nope, cannot reproduce anymore with folders clear....

Edited by Werner
Link to comment
Share on other sites

I think, found what is wrong. @Werner was right, first build from 'fresh' build directory is always ok.
In next builds without 'radical' cleaning cache things go messy.
In directory build/cache/sources/Linux-mainline I found:


I am pretty sure that this *.deb doesn't belong there, so I'll try delete it before each iteration (each board build).

Link to comment
Share on other sites

I'm seeing the same problem, exactly as @guidol described.  I cleared the cache directory and then cleared the output directory, then building 5.9 for nanopi-r1 I ended up with (correct) .debs for sunxi, but (incorrect?) .debs for sunxi64 as well :blink:


Note:  I'm using docker to build; I performed a full build again after removing all "linux-*" files from "/var/lib/docker/volumes/armbian-cache/_data/sources/linux-mainline/" first, and then the output .debs were correct.  So this is consistent with the workarounds above - just need to clear the right "cache" directory.

Link to comment
Share on other sites

I need to build kernels for several sbcs, six to be exact and do this in a loop using a small script to save myself from waiting build to finish and start another.The reason why I don't want to clear entire cache directory is because in that case it downloads toolchain's and sources again and this is slow. It looks like that deleting 'ghost' debs in build/cache/sources/linux-mainline before building do the magic.

Link to comment
Share on other sites

1 minute ago, Werner said:

You don't have to tell me/us. I also do have my almost-daily runs (https://werner.armbian.de) which makes stuff a bit messy ;)

Also this behavior is not intended but debugging simply takes time...

Of course, I know that debugging takes time. I'm just trying to provide developers with as many clues as I can to make their job easier.

Link to comment
Share on other sites

Tried, problem is really solved.
Btw, I am building kernels for 6 boards, mainline and legacy, everytime when new versions of kernel appear.
Changes in building system that have been made since kernel version 5.8.16 speeds up building about 20%, according my observations.
Good work!

Link to comment
Share on other sites

  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines