Metztli Information Technology Blog Bits

(Use your right mouse pointer on image to show video controls and/or to Open video in new tab -- recommended)

Official 4.14.x iterations of Debian kernel packaging for Unstable (Sid) ended with 4.14.17-1. Accordingly, there is no Debian kernel packaging for current upstream release Linux 4.14.20 and much less named its Nahuatl equivalent: Cempohualli: twenty and Ce: one. Moreover, the currently available Reiser4 patch is for kernel 4.14.1+; thus I had to find a way to debianize last kernel packaging if it was to successfully wrap around pristine kernel.org's Linux 4.14.20. The latter, i.e., Cempohualli, is a beautiful number; full of symbolism for existing Nahuatl speaking real Mexicah. What follows are my annotations to carry out the somewhat involved build procedure.

First oddity. Beginning with upstream kernel 4.14.18, Debian kernel packaging for 4.14.17-1 will fail to build:

LD vmlinux.o
MODPOST vmlinux.o
arch/x86/entry/syscall_64.o: In function `x32_enable':
syscall_64.c:(.init.text+0x8): undefined reference to `system_call_fast_compare_end'
syscall_64.c.init.text+0xe): undefined reference to `system_call_fast_compare'
syscall_64.c:(.init.text+0x19): undefined reference to `system_call_mask_compare_end'
syscall_64.c.init.text+0x1f): undefined reference to `system_call_mask_compare'
syscall_64.c:(.init.text+0x33): undefined reference to `system_call_fast_compare'
syscall_64.c.init.text+0x3f): undefined reference to `system_call_mask_compare'
make[5]: *** [vmlinux] Error 1
[]/build/kernel/tekitl-4.14.18/linux/Makefile:998: recipe for target 'vmlinux' failed
make[4]: *** [sub-make] Error 2
Makefile:146: recipe for target 'sub-make' failed
make[3]: *** [__sub-make] Error 2
Makefile:24: recipe for target '__sub-make' failed
make[3]: Leaving directory '[]/build/kernel/tekitl-4.14.18/linux/debian/build/build_amd64_none_amd64
make[2]: *** [debian/stamps/build_amd64_none_amd64] Error 2
debian/rules.real:190: recipe for target 'debian/stamps/build_amd64_none_amd64' failed
make[2]: Leaving directory '[]/build/kernel/tekitl-4.14.18/linux'
make[1]: *** [binary-arch_amd64_none_amd64_real] Error 2
debian/rules.gen:24: recipe for target 'binary-arch_amd64_none_amd64_real' failed
make[1]: Leaving directory '[]/build/kernel/tekitl-4.14.18/linux'
make: *** [binary-arch] Error 2
debian/rules:50: recipe for target 'binary-arch' failed
dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2

Accordingly, if I wanted to build current upstream Linux 4.14.20 'the Debian way', i.e., to generate DEBs as well as UDEBs suitable for Metztli-Reiser4 netboot Debian-Installer (d-i), I had to figure out the issue above.

After considerable effort I found there are a few updated patches we must apply from current Debian kernel packaging master 4.15.4-1 git repository to our Debian kernel packaging unstable (Sid) 4.14.17-1 for this latter to build my downloaded Linux 4.14.20 from upstream:

debian/patches/debian/gitignore.patch
debian/patches/features/x86/x86-make-x32-syscall-support-conditional.patch

Additionally, I modified 4.14.17-1 packaging
debian/patches/series

because 4.14.20 newer kernel already had these security fixes applied.

Now, assuming the Debian kernel packaging default , i.e., to build the real-time (RT) kernel and headers, we get second oddity.

Although the first set of patches for the Debian 'vanilla' kernel applied smoothly, if the developer desired to build the real-time (RT) kernel and headers to subsequently patch all with reiser4 -- which I did -- I had to implement another small hack to fix the following issue:

Applying patch features/all/rt/preempt-lazy-support.patch
Applying patch features/all/rt/ftrace-Fix-trace-header-alignment.patch
Applying patch features/all/rt/x86-preempt-lazy.patch
1 out of 5 hunks FAILED
Patch features/all/rt/x86-preempt-lazy.patch does not apply (enforce with -f)
debian/rules.real:145: recipe for target 'debian/stamps/source_rt' failed
make[2]: *** [debian/stamps/source_rt] Error 1
make[2]: Leaving directory '/[]/build/kernel/nahui.matlactetl_onnahui.cempohualli/linux'
debian/rules.gen:989: recipe for target 'source_rt_real' failed
make[1]: *** [source_rt_real] Error 2
make[1]: Leaving directory '/[]/build/kernel/nahui.matlactetl_onnahui.cempohualli/linux'
debian/rules:26: recipe for target 'source' failed
make: *** [source] Error 2

Evidently debian/patches/features/all/rt/x86-preempt-lazy.patch applied by quilt with fuzz=0 fails at arch/x86/include/asm/thread_info.h since the latter has an extra line of code in the Linux 4.14.20 source tree:
u32 status; /* thread synchronous flags */

which quilt attempted to patch thread_info.h to be subsequently copied over into RT kernel build directory:
debian/build/source_rt/arch/x86/include/asm/thread_info.h

thus I modified slightly debian/patches/features/all/rt/x86-preempt-lazy.patch ¹ so it could apply after the above referenced line of code.

It worked...

Otherwise, if you do not want to build the real-time (RT) kernel and headers, edit with a text editor (like xvi
xvi debian/config/defines

and locate the lines:

[featureset-rt_base]
enabled: true

and change 'true' text string to false, i.e.,

[featureset-rt_base]
enabled: false

save your changes and close debian/config/defines

In summary. I used last 'official' Debian kernel packaging 4.14.17-1 for Unstable (Sid) as base. I then applied the above operations plus other reiser4 hacks for Stretch elaborated in previous post(s); thus generating a Metztli Reiser4 Debian kernel packaging for 4.14.Cempohualli...er, 20, suitable to build a stretch-backports kernel and which resulting source code I subsequently uploaded to Github.

Real Mexicah used a base Cempohualli, i.e., twenty, for their number theory and cherished the expressiveness, non-linearity, of their language: Nahuatl. Those characteristics enhanced their mathematical acumen to apprehend, appreciate, and imitate, nature and Nehnencacitlalli ['the cosmos']. In stark contrast, pseudo-'Mexicans' from 1821 onward, i.e., descendants of Spanish scum invaders who -- like their mother country Spain -- lag several centuries behind in science and technology[1], only have tainted their colonized masses with infinite ignorance.

[1] Kant.

Building Reiser4/Zstd (SFRN 4.0.2) stretch-backports Linux 4.14.Cempohualli-Ce for AMD64

Assuming a proper development environment to build our kernel 'the Debian way' as elaborated a priori in other post(s), we can build upstream Linux kernel 4.14.20, thus:

mkdir --verbose nahui.matlactetl_onnahui.cempohualli
...er, well that's Nahuatl for 4.14.20 -- which you could name your working directory. I will just make a symbolic link:

ln -s nahui.matlactetl_onnahui.cempohualli 4.14.20

cd nahui.matlactetl_onnahui.cempohualli

Download Debian kernel packaging hacked for Linux 4.14.20 from GitHub:
git clone https://github.com/Metztli/reiser4-debian-kernel-packaging-4.14.20.git linux

(Do something while it downloads as it approaches 1Gb of data)

After the cloning procedure finishes, we make a linux sym link:

ln -s reiser4-debian-kernel-packaging-4.14.20 linux

then download kernel 4.14.20 from upstream:
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.14.20.tar.xz

Let's create a symbolic link in the format that Debian kernel packaging expects:
ln -s linux-4.14.20.tar.xz linux_4.14.20.orig.tar.xz

and change into linux directory
cd linux

Edit debian/changelog:
xvi debian/changelog

Locate the text string:

linux (4.14.17-1) unstable; urgency=medium

and remove the number 17 and insert 20, instead, i.e.,

linux (4.14.20-1) unstable; urgency=medium

save your changes.

Now we are ready to build the kernel 'the Debian way' as we did in previous post(s).

Added bonus
Likely fix for Bug#885166: instability with 4.14 regarding KVM virtualization
https://lists.debian.org/debian-kernel/2017/12/msg00374.html

since referenced commit:
https://lists.debian.org/debian-kernel/2018/02/msg00173.html seems to be already applied to Linux kernel source tree 4.14.20.

YES! Bug#885166 has been fixed in 4.14.20!...
"If I used git correctly, then 4.14.20 already has 2a266f23550be997d783f27e704b9b40c4010292, so I tried 4.14.19. 4.14.19 on the one virt host that had the most violent failures failed in the first hour of operation, but with a slightly different error behavior that I was used to. I am therefore not sure whether we are not talking about multiple issues, one of them having been fixed somewhere in between 4.14.13 and 4.14.19."
...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885166

¹ RE: x86: Support for lazy preemption in Debian Linux 4.14.20 AMD64

DISCLAIMER although due diligence has been applied, this resource is made available for testing/evaluation purposes on an AS IS basis. The procedure only reflects my own modifications, my limited testing, and the potential user who executes the procedures assumes all risks.

Please do not hold me or Metztli Information Technology responsible if the information provided here does not achieve the desired result. The information is provided AS IS and with the hope that it may be useful to the Internet community --especially those who desire reiser4 on GNU/Linux Debian.

Nevertheless, there is no implicit or explicit guarantee that the information presented here is accurate --even though due diligence was exercised during the procedure. Accordingly, if an user(s) decide to download and/or implement the procedure and/or shell commands described here s/he or them, do so at her, his, or their own risk. You have been forewarned.