The Awk implementation from BusyBox cannot run the
arch/arm64/tools/gen-sysreg.awk script, and results in the
following error:
GEN arch/arm64/include/generated/asm/sysreg-defs.h
Error at 51: unhandled statement
make[2]: *** [../arch/arm64/tools/Makefile:24: arch/arm64/include/generated/asm/sysreg-defs.h] Error 1
make[2]: *** Deleting file 'arch/arm64/include/generated/asm/sysreg-defs.h'
make[1]: *** [../arch/arm64/Makefile:176: archprepare] Error 2
make[1]: Leaving directory '/mnt/linux/.output'
make: *** [Makefile:228: __sub-make] Error 2
make: Leaving directory '/mnt/linux'
Add gawk (GNU Awk) to work around this issue.
This fixes an issue where if pmbootstrap is accessed via a
different command than pmbootstrap on the user's system (I have it
set to pmb for example), cross_compiler_version() would try to use
a command that doesn't exist. On my system, this results in it
always asking if I want to install pmbootstrap every time I run
envkerenl.sh.
A recent update to shellcheck made this line start failing:
In ./helpers/envkernel.sh line 59:
export pmbootstrap_dir=$(realpath "$script_dir/..")
^--------------------------^ SC2046 (warning): Quote this to prevent word splitting.
The Git version suffixes usually generated automatically by the Linux
build system break packaging in Alpine because the flavor (e.g.
"-postmarketos-qcom-msm8916") will no longer match the module and
zImage path. So far setting LOCALVERSION= and disabling
CONFIG_LOCALVERSION_AUTO was sufficient to avoid the Git version
suffixes but this is no longer enough in Linux 5.14.
Instead, add a better fix by creating an empty .scmversion file
that will be used by the kernel instead of checking the Git status.
The advantage is that this works on Linux 5.14 and it should even
work when CONFIG_LOCALVERSION_AUTO is set.
The .scmversion code can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/setlocalversion?h=v5.14-rc1#n38
Shellcheck 0.7.2 has a change that gives many error conditions their own
SC30** codes, instead of including them in SC2039. This updates the
scripts in this package that "disable SC2039" to disable the new code.
New codes added in shellcheck: cfd68ee0c2ebfd0ab08a1d4bf628162b454dc207
[ci:skip-build] already built successfully in CI
Prevent stricter shells from crashing there if
$POSTMARKETOS_ENVKERNEL_ENBALED is an empty string. It was reported that
it crashes in ksh93, and busybox sh also complains about it.
After an abuild update in Alpine envkernel.sh now throws an error
when activating envkernel:
ash: to: not found
Run 'pmbootstrap log' for details.
This happens because functions.sh fails with:
Unable to deduce build architecture. Install apk-tools, or set CBUILD.
For now it seems to be enough to set CBUILD appropriately to make it
work again.
Change pmaports path `aports/device/device-*` to `aports/device/testing/device-*`
to match the directory structure changes after pmaports!1063 got merged.
Without this change sourcing `envkernel.sh` with up-to-date `pmbootstrap` & `aports` would fail with:
ERROR: Please select a valid device in 'pmbootstrap init'
See also: <https://postmarketos.org/troubleshooting>
x86_64 kernels require some additional dependencies to build properly.
At this point, the list is getting quite long. Ideally we should only
install the build dependencies that are necessary for a particular
kernel package. Add a FIXME to document this for the future.
Attempting to use envkernel.sh on x86_64 fails at the moment:
$ . ~/pmos/pmbootstrap/helpers/envkernel.sh
Initializing Alpine chroot (details: 'pmbootstrap log')
ERROR: unsatisfiable constraints:
binutils-x86_64 (missing):
required by: world[binutils-x86_64]
gcc-x86_64 (missing):
required by: world[gcc-x86_64]
We do not need to install a cross compiler if the device arch is
equal to the host architecture. Check if we need a cross compiler
earlier, and avoid installing it if not necessary.
Also rename "is_cc" to "need_cross_compiler". "is_cc" is confusingly
named since "cc" can refer to the compiler symlink ("C compiler")
or "cross compiler".
When git is installed, the Linux kernel build system appends suffixes
to the Linux kernel version based on the local repository state.
This means that we get different kernel versions when building the
package normally or with envkernel.sh.
This causes problems with Alpine's "installkernel" script,
which detects the kernel flavor based on the kernel version.
e.g. when building linux-postmarketos-qcom-msm8916 with git installed
the kernel image is installed to /boot/vmlinuz-g556e2c21dbac-dirty
where pmbootstrap (and anything else) cannot find it.
Two changes are necessary to prevent the kernel build system from
appending Git version information:
1. Set LOCALVERSION= - this is done by this commit.
2. Unset CONFIG_LOCALVERSION_AUTO
- this needs to be done in each kernel config (when needed)
The armhf hostspec triplet has changed during the Alpine 3.6 release
cylcle. It was recently adjusted in abuild's arch_to_hostspec()
function [1]. Cross compilers in postmarketOS that were built with a
previous version of abuild still have the old hostspec in the name.
Since we use the same function in envkernel.sh to get the cross compiler
name, it is currently failing here for armhf.
We can't simply bump the pkgrel to force a rebuild, because that would
make them go out of sync with the upstrem (non-cross) compiler packages.
That would break the workflow for fixing incompatibilities with Alpine
(see [2]).
Add a workaround to envkernel.sh, to detect if the installed armhf cross
compiler binaries still have the old name.
[1] https://github.com/alpinelinux/abuild/pull/56
[2] https://wiki.postmarketos.org/wiki/Repository_maintenance
Fixes the following error, when running envkernel.sh from a pmbootstrap
path with spaces:
bash: /home/lofenyy/Root/Cabinet/Projects/Phone: No such file or directory
See also: <https://postmarketos.org/troubleshooting>
Example usage:
For kernels that need to run dtbTool after make.
Create a script named post-make.sh in the kernel source directory:
#!/bin/sh
dtbTool -s 2048 -p "${srcdir}/scripts/dtc/" -o \
"${builddir}/arch/arm/boot/dt.img" \
"${builddir}/arch/arm/boot"
To run this script inside the chroot:
$ source ~/pmbootstrap/helpers/envkernel.sh
$ make lineageos_bacon_defconfig
$ make
$ run-script post-make.sh
When there is already another kernel source path mounted then the old mount
should be removed. Otherwise the mount source will still be pointed at the
old kernel source.
When kbuild is using a separate directory for output files then it will
check if the kernel source directory is clean.
The build will throw an error when the source directory is not clean:
.. is not clean, please run 'make mrproper'
Once envkernel.sh has aliased the make command then make mrproper will
be run in the context of .output directory. If the source directory is not
clean then user may be wondering why make mrproper doesn't clean it.
This change will ensure that the source directory is clean when envkernel
is setup.
The pmbootstrap alias cannot be used within the script.
The reason is that aliases are not expanded in non-interactive shells.
reference: https://unix.stackexchange.com/q/1496
To fix this replace references to the pmbootstrap alias with
the $pmbootstrap variable
Changes:
* `helpers/envkernel.sh`:
* installs everything needed for kernel compilation in the native
chroot
* mounts the kernel source to `/mnt/linux` inside the chroot
* creates `/mnt/linux/.output` and chowns it to the `pmos` user, that
folder will be used for the kernel build output
* sets up aliases for `make`, `pmbootstrap`, `pmbroot`, `kernelroot`
* new action `pmbootstrap work_migrate`: does the interactive work
folder migration if necessary, otherwise it doesn't output anything
* when calling this first, we can safely use all other commands
non-interactively without showing the output
Benefits:
* Fast setup (especially for people who are new to kernel
compilation
* No need to figure out distribution specific package names
(cross compilers!)
* No need to do a test build just to verify that the right
packages are installed
* Less error prone
* The right dependencies are always installed
* `ARCH` and `CROSS_COMPILE` variables always get set automatically
and based on `deviceinfo_arch`
* If the build environment is broken for some reason, just zap and
start over
* Easy to reproduce problems
Notes:
* `make menuconfig` works as well
* Sourcing was tested with `zsh`, `bash` and `fish`, it should be easy to
extend for other shells