creating packages in the armbian build system


going
 Share

3 3

Recommended Posts

1 hour ago, Igor said:

Is it possible to add to postinst to create some file containing that info?

The answer is NO. This script is intended for actions after installing the package.

 

To do this, we have a special file "changelog".
This file contains a list of the changes made by the debian maintainer, the person who made the package packaging.
Here is an example of my first proper library package:

libevl (0~210316-1) UNRELEASED; urgency=low

  * Initial release (Closes: #7777)
  * This is my first Debian package.
  * Adjusted the Makefile to fix $(DESTDIR) problems.

 -- The-going <48602507+The-going@users.noreply.github.com>  Tue, 16 Mar 2021 12:42:00 +0300

 

libevl - Source package name

0~210316 - Source package version

1 - Debian package version

UNRELEASED - is replaced by xenial|bionic|focal|groovy|hirsute, armbian-current

 

P.S. Or am I wrong somewhere?

Link to post
Share on other sites

Donate and support the project!

1 hour ago, going said:

The answer is NO. This script is intended for actions after installing the package.


I actually don't mind where ...  I want to attach "legacy" "current" and "edge" information to the kernel package. Anywhere, any way.

 

1 hour ago, going said:

This file contains a list of the changes made by the debian maintainer, the person who made the package packaging.

 

Good. I never went very deep with Debian packaging and I do understand we need to fix those things. Step by step.

 

33 minutes ago, going said:

This file should be filled in according to the template by the build system itself and enter the current data in it.


Understand. Well, (to build) this file is IMO deprecated since it probably only works in a combination with kernel 3.4.y / 3.10.y which we abandoned some time ago.

 

28 minutes ago, going said:

Unfortunately, there are many such moments today.

 

Day ain't over yet :P

Link to post
Share on other sites

My God, with this reworking of patches, I completely forgot about the main task of building kernel packages.

Experience in rpmbuild suggests that you need to take the native kernel build system and fix it a little for our tasks.

 Yes, it is an independent build system for building packages from kernel sources.
Documentation:

.https://wiki.ubuntu.com/Kernel/Dev

https://wiki.ubuntu.com/KernelTeam/KernelMaintenance

Based on this git repository.

I'll see what happens tomorrow.

Link to post
Share on other sites

On 4/19/2021 at 7:29 PM, Igor said:

BRANCH information on the board is needed at least for showing warnings that user is on "EDGE" kernel ... New BSP packages will be one for all, so it can't hold this information. Is it possible to add to postinst to create some file containing that info?

 

 

 


We have to store branch information to those packages

 

In the previous answer, I seem to have overreacted.

Here it matters in which case we want to give the message to the user.

If only when installing the package, then the postinst script is possible.

But, but I don't remember today what I installed in the system yesterday and check using the package manager.

For example, now there is a ubuntu or debian system on the board. How can I find out what is installed from the provided armbian?

sudo apt search linux-image-current
sudo apt search armbian-current
.....
sudo apt search armbian
armbian-config/focal,focal 21.02.3 all
  Armbian configuration utility

armbian-firmware/now 21.05.0-trunk all [установлен, локальный]
  Linux firmware

armbian-firmware-full/focal,focal 21.02.3 all
  Linux firmware-full

armbian-focal-desktop/focal,focal 21.02.2 all
  Armbian desktop for Ubuntu focal

armbian-focal-desktop-gnome/focal,focal 21.02.3 all
  Armbian desktop for Ubuntu focal

armbian-focal-desktop-xfce/focal,focal 21.02.3 all
  Armbian desktop for Ubuntu focal

linux-focal-root-current-bananapi/focal 21.02.3 armhf
  Armbian tweaks for focal on bananapi (current branch)
.....
linux-focal-root-current-orangepipc2/now 21.05.0-trunk arm64 [установлен, локальный]
  Armbian tweaks for focal on orangepipc2 (current branch)
.....
linux-focal-root-*
  Armbian tweaks for focal on *

Armbian tweaks for focal on orangepipc2 (current branch) - Probably this line is the correct option.

In other packages, the keywords 'edge current armbian' must be present in this I agree with you.

Link to post
Share on other sites

On 4/25/2021 at 9:42 PM, going said:

Armbian tweaks for focal on orangepipc2 (current branch) - Probably this line is the correct option.

In other packages, the keywords 'edge current armbian' must be present in this I agree with you.

 

... has been changed to https://github.com/armbian/build/blob/master/lib/main.sh#L395-L396 so this package is only board specific now. Similar variant will come for desktop.

Anyway, since release days are over, this can be moved in - if ready. FYI, there is another larger chunk of additions by @rpardini which needed review, understanding and integration. Not directly related, but imo it's wise not to merge both at once. @lanefu

Link to post
Share on other sites

On 5/11/2021 at 9:50 PM, Igor said:

... has been changed to https://github.com/armbian/build/blob/master/lib/main.sh#L395-L396 so this package is only board specific now. Similar variant will come for desktop.

Very well. But I want to say:

On 4/25/2021 at 10:42 PM, going said:

How can I find out what is installed from the provided armbian?

 

Today I'm testing a few different options for the kernel. File control of the last option:

Package: linux-image-5.10.33-sunxi64
Source: linux-5.10.33-sunxi64
Version: 21.05.6
Architecture: arm64
Maintainer: Igor Pecovnik <igor.pecovnik@****l.com>
Installed-Size: 124084
Provides: linux-image, linux-image-armbian, linux-image-sunxi64
Section: kernel
Priority: optional
Homepage: https://www.kernel.org/
Description: Linux kernel, armbian version 5.10.33-sunxi64 current
 This package contains the Linux kernel, modules and corresponding other
 files, version: 5.10.33-sunxi64.

 

The description field contains information about $BRANCH, but apt will not respond to it, it just outputs the first line as text information for the user.

If the "Provides:" field is in this version:

Provides: linux-image, linux-image-sunxi64, linux-image-armbian, linux-image-armbian-current

 

We will be able to search by tags like this:

sudo apt search linux-image-armbian-current

Link to post
Share on other sites

2 minutes ago, going said:

How can I find out what is installed from the provided armbian?

 

You mean where to find information which branch is currently installed?
 

Spoiler

igorp@nanopik1plus:~ $ cat /etc/armbian-image-release
# PLEASE DO NOT EDIT THIS FILE
BOARD=nanopik1plus
BOARD_NAME="NanoPi K1 Plus"
BOARDFAMILY=sun50iw2
BUILD_REPOSITORY_URL=https://github.com/armbian/build
BUILD_REPOSITORY_COMMIT=b34a3985
DISTRIBUTION_CODENAME=bionic
DISTRIBUTION_STATUS=supported
VERSION=19.11.5
LINUXFAMILY=sunxi64
BRANCH=current
ARCH=arm64
IMAGE_TYPE=user-built
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image
IMAGE_UUID=f3f0671b-4d2b-42a9-b171-7fd9cc236060
igorp@nanopik1plus:~ $ cat /etc/armbian-release       
# PLEASE DO NOT EDIT THIS FILE
BOARD=nanopik1plus
BOARD_NAME="NanoPi K1 Plus"
BOARDFAMILY=sun50iw2
BUILD_REPOSITORY_URL=git@github.com:armbian/build.git
BUILD_REPOSITORY_COMMIT=08297378c-dirty
DISTRIBUTION_CODENAME=bionic
DISTRIBUTION_STATUS=csc
VERSION=21.05.1
LINUXFAMILY=sunxi64
ARCH=arm64
IMAGE_TYPE=stable
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image
igorp@nanopik1plus:~ $

 

 

7 minutes ago, going said:

We will be able to search by tags like this:


IMO that should be fine.

Link to post
Share on other sites

1 hour ago, Igor said:

~ $ cat /etc/armbian-image-release

I didn't even know this information existed.
Thanks.
 

I am a regular ubuntu user. I built or downloaded a mini system image for the board.

What other packages does armbian provide?

What versions do these packages have?

How can I find out this information in a simple way using the apt service?

We need to add key tags to the "Provides:" field. In all packages provided by armbian.

 

Logically, this implies another point - the Version field.
How justified is Version: $REVISION ?

Link to post
Share on other sites

35 minutes ago, going said:

I didn't even know this information existed.


This fingerprint is created at image creation. Then second one (cat /etc/armbian-release) is inside armbian-cli-* package (former linux-root-release-*).

 

35 minutes ago, going said:

What other packages does armbian provide?

 

linux-image

linux-dtb

linux-u-boot

 

armbian-bsp-cli-BOARD

armbian-bsp-desktop-BOARD

armbian-zsh 

armbian-config

armbian-firmware

armbian-RELEASE-desktop-xfce, armbian-RELEASE-desktop-gnome, ...

 

then repacks of hostapd, mmc-utils, htop, ...

 

35 minutes ago, going said:

What versions do these packages have?


All have common version or in case of repacks UPSTREAM_VER-ARMBIAN_VER

 

35 minutes ago, going said:

How justified is Version: $REVISION ?


So you want that we have separate versioning for those internal packages?

Link to post
Share on other sites

17 hours ago, going said:

What other packages does armbian provide?

What versions do these packages have?

How can I find out this information in a simple way using the apt service?

I'm sorry. These are rhetorical questions.

I can't get used to articulating thoughts in the style of English grammar so that the automatic translation looks correct.
In fact, I am an experienced user and will find any information.

But if we give the user the ability to search, update, or reinstall by key tags, it will be very good.

 

sudo apt search armbin

This command will display the full list of packages provided by armbian.

sudo apt search armbin-edge

This command will only show packages for $BRANCH

It is the word combination that is important here armbian-$BRANCH

sudo apt reinstall armbian-current

This command will actually do a package update for the $BRANCH

 

Here we not only take care of the user, but also improve the armbian.

 

18 hours ago, Igor said:

So you want that we have separate versioning for those internal packages?

@Igor Yes, but only for those packages that contain programs, libraries that have their own version.

This is necessary to correctly register the mutual dependencies.

And this is especially true for the kernel and libraries that use the functionality of this particular kernel.

The final version can be formed by concatenating the original version and the armbian version.

Link to post
Share on other sites

Looking ahead a bit, I want the build system to learn how to build complex projects.

Such as Xenomai and Evl. Example of evl core latency:

leo@orangepipc2:~$ uname -a
Linux orangepipc2 5.10.19-evl-sunxi64 #trunk SMP IRQPIPE Sat Mar 6 16:34:02 MSK 2021 aarch64 aarch64 aarch64 GNU/Linux

leo@orangepipc2:~$ sudo cyclictest -t -p80 --clock=1
WARN: cyclictest was not built with the numa option
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.04 0.01 0.00 1/117 2389          

T: 0 ( 2386) P:80 I:1000 C:  17866 Min:      6 Act:    7 Avg:    7 Max:      45
T: 1 ( 2387) P:80 I:1500 C:  11911 Min:      6 Act:   14 Avg:    7 Max:      28
T: 2 ( 2388) P:80 I:2000 C:   8933 Min:      7 Act:    8 Avg:    7 Max:      42
T: 3 ( 2389) P:80 I:2500 C:   7146 Min:      7 Act:    7 Avg:    7 Max:      28

To date, this is the only option for the arm architecture.

Link to post
Share on other sites

In AR-746

For packages linked by the same variable '$BRANCH', the three fields look like this:

debs> for file in linux-*; do echo "$(dpkg -f $file | awk -v f=$file '/Package:|Version:|Provides:/{printf " %-31s", $2" "$3" "$4}')"; done
 linux-dtb-edge-sunxi64          21.08.0-trunk                   armbian-edge, linux-dtb, linux-dtb-armbian
 linux-headers-edge-sunxi64      21.08.0-trunk                   armbian-edge, linux-headers, linux-headers-armbian
 linux-image-edge-sunxi64        21.08.0-trunk                   armbian-edge, linux-image, linux-image-armbian
 linux-libc-dev-edge-sunxi64     21.08.0-trunk                   armbian-edge, linux-kernel-headers, linux-kernel-headers-armbian
 linux-u-boot-orangepipc2-edge   21.08.0-trunk                   armbian-u-boot

 

I think it will be good to bring this to a single unified style.

Link to post
Share on other sites

For comparison, two packages:

linux-libc-dev, linux-headers ubuntu <-> AR-746

Spoiler

leo@orangepipc2:~/DEB$ dpkg -f linux-headers-5.4.0-73-generic_5.4.0-73.82_arm64.deb 
Package: linux-headers-5.4.0-73-generic
Source: linux
Version: 5.4.0-73.82
Architecture: arm64
Maintainer: Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>
Installed-Size: 9778
Depends: linux-headers-5.4.0-73, libc6 (>= 2.17), libssl1.1 (>= 1.1.0)
Provides: linux-headers, linux-headers-3.0
Section: devel
Priority: optional
Description: Linux kernel headers for version 5.4.0 on ARMv8 SMP
 This package provides kernel header files for version 5.4.0 on
 ARMv8 SMP.
 .
 This is for sites that want the latest kernel headers.  Please read
 /usr/share/doc/linux-headers-5.4.0-73/debian.README.gz for details.

leo@orangepipc2:~/DEB$ dpkg -f linux-headers-edge-sunxi64_21.08.0-trunk_arm64.deb 
Package: linux-headers-edge-sunxi64
Source: linux-5.12.4-sunxi64
Version: 21.08.0-trunk
Architecture: arm64
Maintainer: Igor Pecovnik <igor.pecovnik@****l.com>
Installed-Size: 77464
Depends: make, gcc, libc6-dev, bison, flex, libssl-dev
Provides: armbian-edge, linux-headers, linux-headers-armbian
Section: kernel
Priority: optional
Homepage: https://www.kernel.org/
Description: Linux kernel headers for 5.12.4-sunxi64 on arm64 edge
 This package provides kernel header files for 5.12.4-sunxi64 on arm64
 .
 This is useful for people who need to build external modules

 


leo@orangepipc2:~/DEB$ dpkg -f linux-libc-dev_5.4.0-73.82_arm64.deb   // provided by ubuntu
Package: linux-libc-dev
Source: linux
Version: 5.4.0-73.82
Architecture: arm64
Maintainer: Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>
Installed-Size: 5815
Conflicts: linux-kernel-headers
Replaces: linux-kernel-headers
Provides: aufs-dev, linux-kernel-headers
Section: devel
Priority: optional
Multi-Arch: same
Description: Linux Kernel Headers for development
 This package provides headers from the Linux kernel.  These headers
 are used by the installed headers for GNU glibc and other system
 libraries. They are NOT meant to be used to build third-party modules for
 your kernel. Use linux-headers-* packages for that.


leo@orangepipc2:~/DEB$ dpkg -f linux-libc-dev-edge-sunxi64_21.08.0-trunk_arm64.deb 
Package: linux-libc-dev-edge-sunxi64
Source: linux-5.12.4-sunxi64
Version: 21.08.0-trunk
Architecture: arm64
Maintainer: Igor Pecovnik <igor.pecovnik@****l.com>
Installed-Size: 5921
Conflicts: linux-libc-dev
Provides: armbian-edge, linux-kernel-headers, linux-kernel-headers-armbian
Section: devel
Priority: optional
Multi-Arch: same
Homepage: https://www.kernel.org/
Description: Armbian Linux support headers for userspace development
 This package provides userspaces headers from the Linux kernel.  These headers
 are used by the installed headers for GNU glibc and other system libraries.

 

Link to post
Share on other sites

FYI. Packaging seems to work, but it runs very slow / it stalls for some time (10-15 minutes at our build server running Ubuntu hirsute, a minute or two on my slower desktop hw running Linux mint) at the point below. 

 

Spoiler




make KERNELRELEASE=5.12.5-sunxi ARCH=arm 	KBUILD_BUILD_VERSION=trunk -f ./Makefile
  CALL    scripts/atomic/check-atomics.sh
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  CHK     kernel/kheaders_data.tar.xz

 


If I choose to use previous solution (packaging patch 5.10.y) it runs without a stall.

Link to post
Share on other sites

1 hour ago, Igor said:

CHK kernel/kheaders_data.tar.xz

For me, this process was a few seconds.
It is installed in the configuration:

Enable_kernel_headers.thumb.png.6e1ca7f93c4bb884863899893a3fcb44.png
I ran a test build to check it.
@Igor I picked up the stopwatch.

 

P.S. The process took 1 min 39 sec. VM 6 threads 3.4 Ghz

[ o.k. ] Done building [ /home/leo/build/output/images/Armbian_21.08.0-trunk_Bananapim64_focal_edge_5.12.6_minimal.img ]
[ o.k. ] Runtime [ 26 min ]
[ o.k. ] Repeat Build Options [ ./compile.sh  BOARD=bananapim64 BRANCH=edge RELEASE=focal BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=yes COMPRESS_OUTPUTIMAGE=sha,gpg,img  ]

 

Check the contents of the archive file: /sys/kernel/kheaders.tar.xz
Just compare the sizes for 5.10 and 5.12
I don't need it. I use the linux-headers-*package. That's the reason I didn't pay attention.
I'll try to figure it out. The first suspicion is that in addition to archiving, there is also a process of recompilation for the target architecture in the scripts folder in one thread.

 

Link to post
Share on other sites

4 minutes ago, Igor said:

Understand, but I wonder to what this is related. I would bet to some host / compiler related tools.

@Igor I corrected the previous post.
Now everything is in our hands. We can edit scripts right on the spot.

Link to post
Share on other sites

linux-mainline/orange-pi-5.12$ git diff scripts/package/builddeb

...

3 hours ago, Igor said:

If I choose to use previous solution (packaging patch 5.10.y) it runs without a stall.

With the patch, some of the archiving processes fail with an error and this can be seen in the compilation log. Somewhere at the very end.

Link to post
Share on other sites

I can't speak for anything else, but in my experience with 5.12.y and cross compiling, moving the patching of the headers-byteshift.patch and make M=scripts clean process into the postinst script corrects the problem. 

 

Example:
cp headers-byteshift.patch $destdir/
if ls $destdir/scripts/module.lds > /dev/null 2>&1;
    then install -m 0644 $srctree/scripts/module.lds $destdir/ > /dev/null 2>&1;
fi

 

    mkdir -p $kernel_headers_dir/DEBIAN
    cat > $kernel_headers_dir/DEBIAN/postinst <<EOT
#!/bin/bash
# compile headers
CORES=$(grep -c 'processor' /proc/cpuinfo)
clean_headers(){
echo 'y' | make M=scripts clean
if ls headers-byteshift.patch; then patch -p1 < headers-byteshift.patch; fi
if ls module.lds; then install -m 0644 module.lds scripts/; fi
rm -f headers-byteshift.patch module.lds
}

 

set -e

cd /usr/src/linux-headers-$version
echo -e "\e[1;37mCompiling headers\e[0m ..."
find -type f -exec touch {} +
clean_headers > /dev/null 2>&1
echo 'y' | make -j${CORES} -s scripts >/dev/null
echo 'y' | make -j${CORES} -s M=scripts/mod/ >/dev/null
exit 0
EOT

    chmod 755 $kernel_headers_dir/DEBIAN/postinst

 

Case in point on a Pi4 using Mainline:
sudo dpkg -i *.deb
(Reading database ... 60568 files and directories currently installed.)
Preparing to unpack raspberrypi-linux-headers_5.12.6-1_arm64.deb ...
Unpacking raspberrypi-linux-headers (5.12.6-1) over (5.10.39-1) ...
Preparing to unpack raspberrypi-linux-image_5.12.6-1_arm64.deb ...
Unpacking raspberrypi-linux-image (5.12.6-1) over (5.10.39-1) ...
Setting up raspberrypi-linux-headers (5.12.6-1) ...
Compiling headers ...
Setting up raspberrypi-linux-image (5.12.6-1) ...
update-initramfs: Generating /boot/initrd.img-5.12.6
Creating initrd.gz.
Generating uInitrd for U-Boot:
Image Name:   initramfs-5.12.6
Created:      Mon May 24 15:50:40 2021
Image Type:   ARM Linux RAMDisk Image (gzip compressed)
Data Size:    9920125 Bytes = 9687.62 KiB = 9.46 MiB
Load Address: 00000000
Entry Point:  00000000

 

As for the module.lds file, this needs to be moved as make M=scripts clean now removes it for some reason? But this started happening at some point in 5.10.y.

Link to post
Share on other sites

1 hour ago, Cornelius said:

I can't speak for anything else, but in my experience with 5.12.y and cross compiling, moving the patching of the headers-byteshift.patch and make M=scripts clean process into the postinst script corrects the problem. 

Thanks. Did you mean a workable header package?

I'll check it out tomorrow.

Link to post
Share on other sites

The main problem with the linux-headers-* package is that it has a libc6-dev dependency, and it depends on the linux-libc-dev package without a version. During the installation and subsequent compilation, the distribution version "linux-libc-dev"is installed. That is, not the one that is relevant for us. I have to do it manually. on top of the already installed distribution version of "linux-libc-dev", I install my own, which I just built.

Link to post
Share on other sites

Yes, I mean usable headers when Cross Compiling. As for the linux-libc-dev package, this doesn't even need to be installed on Armbians end. This should just be a depends during the creation of an img and should be dragged in regardless. It doesn't need to exactly be reflective of the kernel installed on the system.

 

As an aside, if one were to compile kernels native the headers-byteshift.patch and that whole postinst script isn't even needed.

Link to post
Share on other sites

@Cornelius Thank you for the discussion. Today, for the 5.12 kernel, the build involves these two scripts.

They are simply copied to the target directory here.
I will ask you to look carefully at these two scripts. Maybe I don't see some error?

 

These two scripts collect kernel packages normally on my local VM (focal) and on @Igor local VM.

But the build on the VM that collects all the packages for armbian takes a very long time.

It slows down at the end of the compilation process at the "make kernel headers as a kernel module" stage.

On 5/23/2021 at 2:44 PM, Igor said:

make KERNELRELEASE=5.12.5-sunxi ARCH=arm KBUILD_BUILD_VERSION=trunk -f ./Makefile

CALL      scripts/atomic/check-atomics.sh

CALL      scripts/checksyscalls.sh

CHK       include/generated/compile.h

CHK       kernel/kheaders_data.tar.xz

This is not a kernel-heads package.

 

 

Link to post
Share on other sites

Other than the suggestion I made before I see nothing really wrong with it. It's way more complicated than my approach and written better, but that would be expected. This is Armbian after all. :)

I see some variables I don't understand such as $MAKE and $SRCARCH, but I'm going to assume that makes sense in the builder somewhere.
 

I also notice that none of the pre/post scripts define what they are..? Such as #!/bin/bash or #!/bin/sh, but that would only be relative during the kernel install and have nothing to really do with creation.

 

Only major difference I see, is you appear to be using the builddeb/mkdebian files from 5.10.y, where as I use the 5.4.y files and patch them accordingly to the SoC I am building for. I find it to be a more simplistic builddeb script and less of hassle to deal with and the kernel doesn't complain when I replace the ones it comes with. 

 

Example packaging I use for my test builds. https://github.com/pyavitz/debian-image-builder/tree/feature/patches/packaging

Disclaimer: I don't recommend anyone using that builder, it's mostly a pet project and learning tool for myself. 

 

As for the slow down you are getting in the VM, I really have no ideas as to why that would be. I never use a VM when building, although I do use Docker sometimes.

 

 

Link to post
Share on other sites

@Igor I did a check on a VM with the hirsute operating system.
The kernel build is absolutely the same. In a clean system, only the script worked
compile.sh Reassembly, when the compiler cache is full, takes 9 minutes.

[ o.k. ] Runtime [ 9 min ]
[ o.k. ] Repeat Build Options [ ./compile.sh  BOARD=bananapim64 BRANCH=edge BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=yes KERNEL_CONFIGURE=no  ]

 

I watched the processes in the VM using htop.

These processes go in a single thread:

make KERNELRELEASE=5.12.6-sunxi64 ARCH=arm64        KBUILD_BUILD_VERSION=trunk -f ./Makefile
  CALL    scripts/atomic/check-atomics.sh
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
  AR      init/built-in.a
  CHK     kernel/kheaders_data.tar.xz
  GEN     .version
  CHK     include/generated/compile.h
  LD      vmlinux.o
  MODPOST vmlinux.symvers
  MODINFO modules.builtin.modinfo
  GEN     modules.builtin
  LD      .tmp_vmlinux.kallsyms1
  KSYMS   .tmp_vmlinux.kallsyms1.S
  AS      .tmp_vmlinux.kallsyms1.S
  LD      .tmp_vmlinux.kallsyms2
  KSYMS   .tmp_vmlinux.kallsyms2.S
  AS      .tmp_vmlinux.kallsyms2.S
  LD      vmlinux
  SORTTAB vmlinux
  SYSMAP  System.map
  OBJCOPY arch/arm64/boot/Image
  MODPOST modules-only.symvers
  GZIP    arch/arm64/boot/Image.gz
  GEN     Module.symvers
make KERNELRELEASE=5.12.6-sunxi64 ARCH=arm64        KBUILD_BUILD_VERSION=trunk -f ./Makefile
  CALL    scripts/atomic/check-atomics.sh
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  CHK     kernel/kheaders_data.tar.xz

 

CHK     kernel/kheaders_data.tar.xz - 6 cpus are loaded at 15-30% each.

But when the linux-headers, linux-source package is created, archiving is done in multithreaded mode. 6 CPUs are 100% loaded.
 

Link to post
Share on other sites

 Share

3 3