guidol Posted October 26, 2020 Posted October 26, 2020 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. AND 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.
Werner Posted October 26, 2020 Posted October 26, 2020 Odd. Tried to reproduce from a clean workspace? Some enhancements have been made a few days ago regarding multicore building but no idea if that mighht have interfered.... https://github.com/armbian/build/pull/2266/files
IgorS Posted October 31, 2020 Posted October 31, 2020 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
IgorS Posted October 31, 2020 Posted October 31, 2020 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.
Igor Posted October 31, 2020 Posted October 31, 2020 It seems like a side effects of some improvements we made. We will look into it, when time permits.
Werner Posted October 31, 2020 Posted October 31, 2020 @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...
IgorS Posted October 31, 2020 Posted October 31, 2020 @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.
Werner Posted October 31, 2020 Posted October 31, 2020 (edited) 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 October 31, 2020 by Werner
IgorS Posted October 31, 2020 Posted October 31, 2020 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: linux-5.4.72-sunxi_20.11.0-trunk_armhf.buildinfo linux-5.4.72-sunxi_20.11.0-trunk_armhf.changes linux-5.8.17-sunxi64_20.11.0-trunk_arm64.buildinfo linux-5.8.17-sunxi64_20.11.0-trunk_arm64.changes linux-5.8.17-sunxi_20.11.0-trunk_armhf.buildinfo linux-5.8.17-sunxi_20.11.0-trunk_armhf.changes linux-dtb-current-sunxi64_20.11.0-trunk_arm64.deb linux-dtb-current-sunxi_20.11.0-trunk_armhf.deb linux-dtb-legacy-sunxi_20.11.0-trunk_armhf.deb linux-headers-current-sunxi64_20.11.0-trunk_arm64.deb linux-headers-current-sunxi_20.11.0-trunk_armhf.deb linux-headers-legacy-sunxi_20.11.0-trunk_armhf.deb linux-image-current-sunxi64_20.11.0-trunk_arm64.deb linux-image-current-sunxi_20.11.0-trunk_armhf.deb linux-image-legacy-sunxi_20.11.0-trunk_armhf.deb orange-pi-5.4 orange-pi-5.8 I am pretty sure that this *.deb doesn't belong there, so I'll try delete it before each iteration (each board build).
5kft Posted October 31, 2020 Posted October 31, 2020 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 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.
IgorS Posted October 31, 2020 Posted October 31, 2020 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.
IgorS Posted October 31, 2020 Posted October 31, 2020 4 minutes ago, IgorS said: But still, this is just workaround.
Werner Posted October 31, 2020 Posted October 31, 2020 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...
IgorS Posted October 31, 2020 Posted October 31, 2020 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. 1
Solution Werner Posted October 31, 2020 Solution Posted October 31, 2020 There you go: https://github.com/armbian/build/pull/2293 Either checkout the PR branch or apply the fix manually. Need feedback if that works.
IgorS Posted November 1, 2020 Posted November 1, 2020 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! 1
Werner Posted November 1, 2020 Posted November 1, 2020 More optimizations are WIP https://github.com/armbian/build/pull/2296
Recommended Posts