Metztli Reiser4 GCC14 / Debian Trixie AMD64

Jose — Mon, 10 Nov 2025 14:38:00 +0000

Metztli Reiser4 Trixie on AX16PRO Ryzen

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.

Nohmatca nehhuatl, NiNantzin motecuiyo
Huitzilopochtli ≈
Это я собственной персоной, я Мать вашего повелителя
Уицилопочтли ≈
It is I in person, I am Mother of your lord Huitzilopochtli

Cohuatlicue, the 'Kundalini' of the true Mexicah

Cohuatlicue, the 'Kundalini' of the real Mexicah peoples of A∙nahuac

≈ Cohuatl∙i∙cue∙itl : 'Та, Цто Носит Юбку Из Змей' : 'She Who Wears the Serpents Skirt'.

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:

bdi_write_congested

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 -- built from source. Apropos, fuck the Zio- cock lover complicit with his ilk's Gaza genocide, Oracle's Larry Ellison, whose policy against those of us who criticize his drama queen, hasbara -puking, scumbag ilk's abhorrent deeds probably had the effect of kicking me out of the VirtualBox mailing list!

Notwithstanding, the kernel build began with routine preparations:

Shell

apt-get -t trixie-backports install build-essential libncurses5-dev libdebconfclient0-dev libssl-dev libpci-dev libwrap0-dev asciidoc quilt git rsync fakeroot devscripts kernel-wedge libelf-dev libperl-dev python-dev-is-python3 libnuma-dev libaudit-dev libunwind-dev libdw-dev libudev-dev libiberty-dev usbip dh-exec dh-di dh-autoreconf flex bison libpfm4-dev
apt-get -t trixie-backports build-dep linux

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

Shell

mkdir --verbose totomichin-5.17.15 && cd totomichin-5.17.15

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

git clone -b debian/5.17.11-1 --single-branch https://salsa.debian.org/kernel-team/linux.git

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

Shell

cd linux

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

Shell

wget -P .. https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.17.15.tar.xz https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.17.15.tar.sign

Fetching kernel 5.17.15 and signature

and verify its signature:

Shell

xz -dc ../linux-5.17.15.tar.xz | gpg --verify ../linux-5.17.15.tar.sign -

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

ln -rs ../linux-5.17.15.tar.xz ../linux_5.17.15.orig.tar.xz

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:

Reiser4 -enhanced Debian Packaging for 5.17.15

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

cat ../../metztli-reiser4-enhancing-debian-packaging-for-GCC14-5.17.15-ihuan-rtw89.patch | patch --dry-run --fuzz=0 -p1

then for reals:

Shell

cat ../../metztli-reiser4-enhancing-debian-packaging-for-GCC14-5.17.15-ihuan-rtw89.patch | patch --fuzz=0 -p1

Applying reiser4 -enhanced Debian Packaging patch

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

head debian/changelog

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

sed -i '0,/$5\.17\.$11/s//\115/' debian/changelog

(NOTE: Any additional patches we apply, i.e., our reiser4 -hacked patch, must be implemented after the command/directive enumerated as 13, below; otherwise, any patched sources will be overwritten by such command/directive 13.)
as this will enable the Debian Packaging tools to debianize the 5.17.15 source, with:

Shell

debian/rules orig

debian/rules orig: debianize kernel 5.17.15

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:

Successful debianization of kernel source tree

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

ls drivers/net/wireless/realtek/rtw89

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

sed -i '0,/$5\.17\.$15/s//\111/' debian/changelog

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.

NOTE: while creating this post I sort of backported perf: Remove libcrypto dependency

Shell

cat ../linux-5.17.15-remove-perf-dependency-on-libcrypto.patch | patch --fuzz=0 -p1

Remove perf dependency on libcrypto

due to the fact that ever since Debian Amatlocuilin, i.e., 'Bookworm', I only had one Debian partition which during kernel build could generate perf without being bound to libcrypto. As Trixie came along, I faced the same issue and thus developed the last patch attached. According to debian/rules.d/tools/perf/Makefile, the perf and libcrypto licenses are incompatible and perf bound to libcrypto can not be distributed. I think I finally solved the issue

ldd shows that perf is not bound to libcrypto

because the debian directive:

MAKE_PERF += NO_LIBCRYPTO=1

seemed not to have an effect and perf always was bound to libcrypto, except for that specific Debian partition in older hardware.

Additionally, this perf does not depend on the older libpython3.11 but on current libpython3.13 in Trixie. Apologies if that caused an issue in existing kernel builds out there.

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

debian/rules debian/control

debian/rules debian/control

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...

debian/rules debian/control normal errors

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

fakeroot debian/rules source

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

Shell

gzip -dc ../../metztli-reiser4-sfrn4-for-5.17.15-1.patch.gz | patch --dry-run --fuzz=0 -p1

Testing application of reiser4 patch on kernel source

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

Shell

gzip -dc ../../metztli-reiser4-sfrn4-for-5.17.15-1.patch.gz | patch --fuzz=0 -p1

Applying reiser4 patch on kernel source tree

reiser4 patch on kernel src tree done

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

head -n 4 debian/config/defines

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

Shell

sed -i 's/^$abiname: 3$/\1+reiser4.0.2/' debian/config/defines

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

dch -v 5.17.15-1+reiser4.0.2 -D metztli

Use dch to modify kernel patch level in debian/changelog

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

grep "+reiser4.0.2" debian/config/defines debian/changelog

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

debian/rules debian/control

debian/rules debian/control no extraneous errors

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

Shell

fakeroot debian/rules debian/control-real

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

fakeroot make -f debian/rules.gen setup_amd64_none_amd64

fakeroot make -f debian/rules.gen setup_amd64_none_amd64

fakeroot make -f debian/rules.gen setup_amd64_none_amd64 done

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

Shell

egrep -i 'reiser4|zstd' debian/build/build_amd64_none_amd64/.config

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

dpkg-buildpackage --build-profiles=pkg.linux.nokerneldbg -F -us -uc -jX -T binary-arch,binary-indep

dpkg_buildpackage ... typical kernel build begins

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)...

Yet, towards the end of the kernel build, I hit a couple of separate snags¹ during the older kernel documentation build:

Sphinx parallel build error:
AttributeError: module 'docutils.nodes' has no attribute 'reprunicode'

and

Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sphinx/config.py", line 529, in eval_config_file
exec(code, namespace) # NoQA: S102
~~~~^^^^^^^^^^^^^^^^^
File "/mnt/chiucuome/usr/tzinti/build/build-totomichin-5.wx.yz/totomichin-5.17.15/linux/debian/build/build-doc/Documentation/conf.py", line 27, in <module>
from load_config import loadConfig
File "/mnt/chiucuome/usr/tzinti/build/build-totomichin-5.wx.yz/totomichin-5.17.15/linux/debian/build/build-doc/Documentation/sphinx/load_config.py", line 6, in <module>
from sphinx.util.pycompat import execfile_
ModuleNotFoundError: No module named 'sphinx.util.pycompat'

Eventually -- after patching -- the kernel build will complete,
NOTE: metztli-reiser4-enhancing-debian-packaging-for-GCC14-5.17.15-ihuan-rtw89m.patch supersedes our earlier Debian Packaging patch which fixes the document generating issues just elaborated above. The patch is also attached at the end of this post.
and thus the '-2' to differentiate from the '-1' in the first referenced successful kernel build in an older machine instance upgraded from Bookworm to Trixie. Below is a typical successful kernel build completion output screen:

Typical screen output kernel 5.17.15 build success

'Just for kicks' we will install our newly built linux-perf package:

Shell

sudo dpkg -i metztli-GCC14-5.17.15-2-on-Ryzen-omeDEBs/linux-perf_5.17.15-2+reiser4.0.2_amd64.deb

subsequently, acquiring root privilege -- or as sudo -- test perf² utility:

Shell

perf stat -- sleep 0.1

perf stat -- sleep 0.1

and then, adapting test from Debian Packaging for 5.17.11-1, debian/rules.d/tools/perf/Makefile at line number 54, i.e.,

# Check that perf didn't get linked against libbfd or libcrypto
type ldd
! ldd $(CURDIR)/perf | grep -E '\blib(bfd|crypto)'

Shell

perf version --build-options
ldd $(which perf) | grep -E '\blib(bfd|crypto)'

Ангелина Кузнецова as Trixie - perf Q.E.D

Tlilxochitl, i.e.,'Vanilla, Intel CPUs:

Ryzen/Epyc CPUs

And, yes, I can build from source VirtualBox 7.2.4 under Metztli Reiser4 Trixie with my recently built kernel(s) 5.17.15-2 -- in spite of me being quietly omitted from the Zionists US Anglo- Nazi Jews' -controlled Oracle mailing list:

VirtualBox 7.2.4 built on Metztli Reiser4 5.17.15-2

So we celebrate our Metztli Reiser4 Trixie achievement embodied by none other than Русский пример платоновского Архетипа Красоты ≈ a Russian instance of Plato's Archetype of Beauty: Ангелина Кузнецова ≈ Angelina Kuznetsova ... if I could only remember where her file is ... 'You Beat Me to the Punch' by Mary Wells:

¹
Trixie installed python3-docutils 0.21.2+dfsg-2 all, i.e., 'text processing system for reStructuredText (implemented in Python 3)' and
... docutils 0.21 has removed nodes.reprunicode,

Trixie installed python3-sphinx 8.1.3-5, i.e., 'documentation generator for Python3 projects', but

Sphinx 6.0 removed the execfile_() function, which we use as part of the
configuration process. They *did* warn us... Just open-code the
functionality as is done in Sphinx itself.

... Fix the docs build with Sphinx ...

² Linux perf

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.

Original post blogged on Metztli b2evo for PHP 8.

	`apt-get -t trixie-backports install build-essential libncurses5-dev libdebconfclient0-dev libssl-dev libpci-dev libwrap0-dev asciidoc quilt git rsync fakeroot devscripts kernel-wedge libelf-dev libperl-dev python-dev-is-python3 libnuma-dev libaudit-dev libunwind-dev libdw-dev libudev-dev libiberty-dev usbip dh-exec dh-di dh-autoreconf flex bison libpfm4-dev`
	`apt-get -t trixie-backports build-dep linux`

	`perf version --build-options`
	`ldd $(which perf) \| grep -E '\blib(bfd\|crypto)'`

Metztli I. T. Blog

Metztli Reiser4 GCC14 / Debian Trixie AMD64

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

Tlilxochitl, i.e.,'Vanilla, Intel CPUs:

Ryzen/Epyc CPUs