Metztli I. T.  Blog

As the date of Debian 13, aka Trixie, official release approached, I was busy on other pressing tasks and thought I would eventually catch up with the build of required components for Metztli Reiser4 -enabled Debian Installer (d-i) and online packages for our reiser4 hack. I decided to build the next patched level of the kernel macuilli.caxtolli_omome.matlactetl_omnahui (5.17.14) -- yes a major version behind Linux mainline kernel but still supported by the existing reiser4 patch available from Mr. Edward Shishkin' SourceForge repository; the reasoning was, well, if this reiser4 -enabled kernel will be used for a new Debian official release, then at least a more recent kernel, even with a patchlevel upgrade would be adequate. I have been diligently adapting Mr. Shishkin's patch for increasing kernel patch levels other than the targeted one.

Fact is, all support for reiser4 is now purged in Debian Trixie. I had to build from source even libaal: Reiser4's application abstraction library, reiser4progs: Administration utilities for the Reiser4 file system, and even devise a hack for initramfs-tools -- as the official Debian package generated a non-reiser4-compatible initrd.img-, and thus an unbootable reiser4 -based operating system. This latter issue took me a while to zero-in on the offending commit during which time I created a couple of quite dirty hacks just not to delay any further our custom netboot Debian Installer (d-i): Metztli Reiser4.

Needless to say, all the reiser4 sources had to be built with Debian Trixie's GCC14 default compiler; and I encountered several issues which had to be overcome if reiser4 were to be viable under Trixie. In this long journey to reiser4 on Trixie, Ангелина Кузнецова : Angelina Kuznetsova came along at the rhythm of «Я Хочу Быть Твоим Любовником» : "I Wanna Be Your Lover!" ~ Песня Принца : Prince's song.

WARNING, the instance of an archetype of a beautiful Russian female body visual art requires the user to be old enough -- and male enough in the fascist West, i.e., unperturbed by the Russophobe Zionist Jew Soro's agenda -- and thus be able to appreciate Ангелина Кузнецова : Angelina Kuznetsova's performance:

I wanted to to integrate the more recent drivers/net/wireless/realtek/rtw89, which provide WiFi 6 support for my device, into the Debian Packaging for 5.17.11-1 which was to be hacked and repurposed for Linux macuilli.caxtolli_omome.caxtolli, i.e., 5.17.15, since during the creation of this post I decided to go for the last 5.17 patch level available at The Linux Kernel Archives.

By the way, this is the last kernel version supported by the current and/or incrementally modified existing reiser4 patch available from the aforementioned SourceForge repository. For kernels 5.18.xy the reiser4 code has to undergo a major rewriting to accommodate the Removal of remaining parts of congestions tracking code:

Thus, I began by upgrading an existing Metztli Reiser4 Amatlocuilin, i.e., Bookworm, Debian partition instance up to the recent release of Trixie. Of course, I hit some snags along the way, for instance the binutils package did not upgrade automatically and my overlooking that fact came back to bite me after I had built and was running the GCC14 build of reiser4 kernel but then tried to install modules of my VirtualBox build.

Notwithstanding, the kernel build began with routine preparations:

Shell

Create our working totomichin, i.e., 'penguin', kernel build directory;

Shell

Debian did not release a packaging for 5.17.15, accordingly, as in the case of our kernel build for Amatlocuilin, i.e., 'Bookworm', we will be modifying the Debian Packaging for 5.17.11-1 and patching it to target our current kernel 5.17.15 build for Trixie. We begin by cloning the older branch locally:

Shell

a linux directory will be created and we change into its location at our Linux shell:

Shell

We fetch our target kernel with the last patch level in the series to be downloaded one directory above our current location:

Shell

and verify its signature:

Shell

Obviously, since our resources are one directory up from our current shell location, we pass the -r option to ln to create a link which works with the linux kernel string form expected by the Debian packaging:

Shell

we may verify by lsting contents in parent directory.

Prior to engaging in this post, I had placed a couple of links to our reiser4 -enhanced and/or modified Debian Packaging for 5.17.15, i.e., metztli-reiser4-enhancing-debian-packaging-for-GCC14-5.17.15-ihuan-rtw89.patch , which we will be applying subsequently, and our gradual modification of Mr. Shishkin's last reser4 patch, i.e., metztli-reiser4-sfrn4-for-5.17.15-1.patch.gz .

On the first, we can execute head to output the first part of the file:

Subsequently, we proceed to apply our reiser4 -enabled Debian packaging for 5.17.15 (download link is at the end of the blog post); first with the --dry-run option:

Shell

then for reals:

Shell

Notice the xiuhtzin, i.e., 'blue', hilited entries in the snapshot above. Those are integrated patches for backported rtw89 modules for WiFi 6 -enabled device(s), like the AX16, and the pahole flags required to build the older kernel with GCC12 and GCC14.

If we take a peek at the Debian changelog in the packaging,

Shell

we can see that its version, i.e., 5.17.11, does not match the version of our downloaded kernel, i.e., 5.17.15; accordingly, we ephemerally modify the relevant file with sed:

Shell

as this will enable the Debian Packaging tools to debianize the 5.17.15 source, with:

Shell

Newer Debian scripts cause a couple of errors in the older packaging framework:

dpkg-buildapi: error: cannot read debian/control: No such file or directory
sh: 1: test: Illegal number:
dpkg-buildapi: error: cannot read debian/control: No such file or directory
sh: 1: test: Illegal number:

notwithstanding, those errors appear not to affect the kernel build overall, as seen in the successful completion of the debianization of 5.17.15:

Indeed, even our integrated patches into the Debian Packaging framework, hilited in xiuhtzin, applied smoothly. Notice that those hilited patches were first used to patch 5.17.14 yet I reused them because the relevant source in 5.17.15 remained the same. For instance, we can peek at the WiFi 6 -enhanced rtw89 modules hack directory:

Shell

In conclusion, before applying our reiser4 patch to 5.17.15 source, we will now revert back to the original Debian Packaging patch level:

Shell

Subsequently, we will use Debian dch tool to properly increase the kernel patch level. Up to now, we have only reiser4 -enhanced the Debian packaging framework to build reiser4 relevant packages. However, we still need to reiser4 -enhance the kernel 5.17.15 source itself; otherwise, the built kernel will be blind to the reiser4 Software Release Number (SFRN) 4.0.2 file system.

Applying Reiser4, either Software Framework Release Number (SFRN) stable 4.0.2 OR unstable 5.1.3 and, Optionally, Customizing 5.17.15 for AMD Epyc/Ryzen CPUs

Please take a look at the annotations in debian/config/config and debian/config/config.cloud for the differences from the Debian defaults -- besides the obvious addition of the Reiser4 module, of course. If those files are not further modified, our kernel build will be for a tlilxochitl, i.e., 'vanilla', Intel CPU(s).

Shell

Again, likely because of Debian Trixie newer tools operating on older Debian Packaging for a major kernel version behind, we observe these couple of errors duplicated and hilited in xiuhtzin:

dpkg-buildapi: error: cannot read debian/control: No such file or directory
sh: 1: test: Illegal number:
dpkg-buildapi: error: cannot read debian/control: No such file or directory

yet, reiterating, those errors do not seem to affect the build procedure. Continuing...

Conversely, based on multiple previous debianized kernel builds, we know that the last errors are 'normal', i.e.,
...

This target is made to fail intentionally, to make sure
that it is NEVER run during the automated build. Please
ignore the following error, the debian/control file has
been generated SUCCESSFULLY.

exit 1
make[1]: *** [debian/rules:135: debian/control-real] Error 1
make[1]: Leaving directory '/mnt/chiucuome/usr/tzinti/build/build-totomichin-5.wx.yz/totomichin-5.17.15/linux'
make: *** [debian/rules:119: debian/control] Error 2

then follow with:

Shell

Now we do test run enhancing the 5.17.15 source tree with our modified reiser4 patch:

Shell

the patch applies smoothly, thus we apply the patch for reals:

Shell

The next task is to concatenate the string '+reiser4.0.2' to the abi in the file debian/config/defines which will indicate that our reiser4 SFRN 4.0.2 -enabled kernel is a tlilxochitl ['vanilla'] kernel targeted at Intel CPUs. We first peek four(4) lines from the top of the relevant file:

Shell

Then we concatenate the reference string to the kernel ABI (note it is usually a digit but sometimes I have seen string 'trunk':

Shell

We verify by implementing directive 20 above. If we are satisfied, then we will increment the kernel patch level in the debian/changelog to reflect the actual kernel source version we will build by utilizing dch, a Debian tool to modify the debian/changelog via a default text editor. Since after the -D option I am providing the string 'metztli', dch warns that it is not a known Debian distribution. I just press Enter to ignore the warning and continue to edit debian/changelog via the dch interface.

Shell

After we save our modifications, we can peek to verify the dch results reflected in the file debian/changelog ; as shown in the screenshot above, I invoked an Eterm with xvi tiny text editor as: Eterm -g 100x33+0+0 -T "Ангелина Кузнецова as Trixie: $1" -t get-E --exec xvi $1 wrapped in iztaccihuatl custom executable.

Then we can verify that our +reiser4.0.2 char strings concatenations match:

Shell

Proceeding with our next Debian incantation, we note that early errors exhibited during command number 16 above do not occur only, as usual, the couple of 'normal' errors in output stream that we have seen during previous kernel builds:

Shell

Lastly, in the ensuing Debian incantation only one error should be expected when the directive finishes:

Shell

For the previous to last debian incantation (observe the red-pointing directive in the ensuing snapshot) you really want to redirect the output and any potential errors, i.e., 2>&1, into a log file to analyze afterwards. It is a fact that if any errors are logged during the make procedure the kernel build will fail:

Shell

We may carry out some final checks, like verifying that our reiser4 module is selected in the ensuing kernel .config file generated:

Shell

We may pass the option pkg.linux.nokerneldbg build profile that excludes kernel debug bloat; it worked well under Debian Bullseye but I did not notice much, if any, build-bloat difference under Debian Bookworm or Trixie:

Shell

Where X is a placeholder for...

Number of jobs allowed to be run simultaneously, number of jobs matching the number of online processors if auto is specified (since dpkg 1.17.10), or unlimited number if jobs is not specified, equivalent to the make(1) option of the same name (since dpkg 1.14.7, long option since dpkg 1.18.8)...

---

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(s) who execute(s) the procedures assumes all risks.

Please do not hold me or Metztli Information Technology (and/or its associates) 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 open-minded individuals interested in Reiser4 continued development.

Notwithstanding, 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 implement the procedure or shell commands described here she, he, or them, do so at her, his, or their own risk. You have been forewarned.

Metztli IT, but not other entities, reserves the right to modify the content -- to correct and/or elucidated procedure(s), for instance -- and/or even delete all or partial, including blog post, without previous notice.