I am trying to build an updated image for an orange pi zero using the mainline buster headless. I tried on an ubuntu 20.04 VM (on a fedora host) and on a natively ubuntu20.04 installed laptop. Both fail to compile the kernel with the same error.

Below is my compile config file and my compilation.log is attached. Any ideas what is going wrong here? I know I don't have the make terget in CLEAN_LEVEL, but I even tried when completely removing the whole armbian-build folder and cloning a fresh repos and removing all apt-cache-ng cache. So it's not due to that.

 

# Read build script documentation https://docs.armbian.com/Developer-Guide_Build-Options/
# for detailed explanation of these options and for additional options not listed here

KERNEL_ONLY="no"                # leave empty to select each time, set to "yes" or "no" to skip dialog prompt
KERNEL_CONFIGURE="no"            # leave empty to select each time, set to "yes" or "no" to skip dialog prompt
CLEAN_LEVEL="oldcache"    # comma-separated list of clean targets: "make" = make clean for selected kernel and u-boot,
                    # "debs" = delete packages in "./output/debs" for current branch and family,
                    # "alldebs" = delete all packages in "./output/debs", "images" = delete "./output/images",
                    # "cache" = delete "./output/cache", "sources" = delete "./sources"
                    # "oldcache" = remove old cached rootfs except for the newest 8 files

DEST_LANG="en_US.UTF-8"            # sl_SI.UTF-8, en_US.UTF-8

# advanced
EXTERNAL_NEW="prebuilt"            # compile and install or install prebuilt additional packages
INSTALL_HEADERS="no"            # install kernel headers package
LIB_TAG="master"            # change to "branchname" to use any branch currently available.
USE_TORRENT="yes"            # use torrent network for faster toolchain and cache download
ARMBIAN_MIRROR="https://minio.k-space.ee/armbian/dl/"
DOWNLOAD_MIRROR=""            # set to "china" to use mirrors.tuna.tsinghua.edu.cn
CARD_DEVICE=""                # device name /dev/sdx of your SD card to burn directly to the card when done
BOARD="orangepizero"
BRANCH="current"
RELEASE="buster"
BUILD_DESKTOP="no"
BUILD_MINIMAL="yes"

 

compilation.log

Only building from master is usually works flawless. Tags are mostly for documentary purpose only. Their functionality cannot be guaranteed since external sources changing all the time which is out of scope of Armbian.

Retry to build from master.

Yeah, but master is always the "latest and greatest". But with all the different optional combinations of hardware and software, there is no guarantee that works on all of those as well, especially with older hardware. I usually prefer using a "stable"/"working" tag/version, and only upgrade to a newer version if/when needed.  Right now master gives me (different) trouble as well, but I guess I have no option now if version 2020.11 is broken with the mainline kernel to deal with the issue master gives me. 

 

But would it not be an option to use specific "known good" commits of the kernel srouce in combination with armbian-build tags? Instead of just always checking out the "latest" mainline kernel? It would be really nice to have tags in time where you know a specific combination of kernel, armbian and hardware version works, and you can just check that out again later if needed. For me everything worked until I removed my caches, which kicked off a kernel recompile (as expected), but clearly with a different kernel or toolchain version than before, because now it won't compile anymore., while before it did.

Yes this rebuildability is something we have been thinking/working on for a while. There even is an existing Jira Ticket for it:
https://armbian.atlassian.net/browse/AR-175?atlOrigin=eyJpIjoiN2FhZTgyMTIxZWMxNDA2NmE5NjIxOTEzYTI4YWNiNDAiLCJwIjoiaiJ9

and the original post 

 

As of know this has not been implemented (probably because no one had enough time / interest / motivation to do it). Maybe you can?  
We'd also need to define how many old tags we support and for how long... 

 

 

 

 

41 minutes ago, Heisath said:

We'd also need to define how many old tags we support and for how long... 

For the moment close to none. It is hard enough to keep up with master already

Hmm, maybe I can indeed spend some time on that. Do you guys have an opinion about using git submodules? Instead of just checking out the kernel and other repositories, they could be added as submodules to armbian-build, which would mean they would always check out the same commit.

basically, instead of doing a `improved_git checkout ....` , we could replace it with a `git submodule update --init`, and then depending on a config option, followed by the `improved_git checkout....` if we want the HEAD of all dependencies (default) or stick with whatever commit the submodule points at. It would allow the master branch to always point to HEAD of whatever repos/branch we depend on, while the release branches would be able to point to specific commits/branches/tags of the dependencies.