Metztli I. T.  Blog

Reiser4 developer Edward Shishkin did not release a patch for chachictetl, i.e., 'kernel', 5.15.15, the last kernel supported by the official Debian Packaging patch, including backports for the then Debian Bullseye release:

As a matter of fact, Mr. Shishkin's reiser4 patches skipped the 5.15.xy altogether, as he released reiser4 for 5.13 and subsequently for 5.16 only. Back when I was using Github, I observed Mr. Shishkin's advice to a reiser4 user interested in reiser4 -enhancing 5.15:

Assuming you need a stable [reiser4] release (format 4.X.Y) I would recommend you to patch vanilla 5.15 kernel with reiser4-for-5.13

And, indeed, his advice initially worked. Nevertheless,

Ah mochipa Tlalticpac: zan achica ye nican ≈
«Не вечно на Земле: лишь краткий [мимолетный миг] здесь». ≈
'Not forever on Earth: only a little [fleeting moment] here'

since, as the 5.15 long term support kicked-in, and advanced, some kernel code was backported from upstream, and then the reiser4 for 5.13 patch application onto 5.15 became somewhat obsolete and the build halted with error(s), especially since:
fs/reiser4/plugin/file/cryptcompress.c
fs/reiser4/plugin/item/extent_file_ops.c
fs/reiser4/plugin/item/tail.c

required to be updated, as in reiser4 for 5.16 patch Mr. Shishkin had already done. Otherwise, reiterating, the kernel build fails during the 5.15.xy LTS build.

Yet, truth is, I never cared to look back to the 5.15.xy series until recently, when an official kernel developer hinted at the 5.15 long term support (LTS) kernel in a thread relating to security issues: Re: [oss-security] Backports available - cBPF JIT spray hardening. Well, for those paranoid about 'security', likely those in enterprise environments -- I can only guess 🙄, here is a best-effort reiser4 for 5.15.220 LTS patch built under my 5.17.15-3 reiser4 environment overview -- as I'd heard it through the grapevine that there were no reiser4 for 5.15 LTS patch(es when, in fact, I am already running -- daily -- 5.15.220 LTS from my initial build!

NOTE: metztli reiser4 for 5.15.220 patch hack strips away: fs-writeback: writeback_sb_inodes：Recalculate 'wrote' according skipped pages

commit 71f32f762d1a065ce27ec4922cb362aec122279d
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date: Tue May 10 21:38:05 2022 +0800

fs-writeback: writeback_sb_inodes：Recalculate 'wrote' according skipped pages

commit 68f4c6eba70df70a720188bce95c85570ddfcc87 upstream.
...

applied upstream as it introduced corruption to the reiser4 SFRN 4.0.2 file system in subsequently reiser4 -enhanced kernels -- as analyzed with dmesg -- if the Telegram Desktop application was being used and the /home partition, where Telegram writes its cache/data, was formatted in reiser4 SFRN 4.0.2. As a matter of fact, .local/share/TelegramDesktop/tdata/user_data/cache/ becomes unreadable with userland utilities. Depending on the corruption extent, the reiser4 -formatted media had to eventually be checked with fsck.reiser4.

Thus we begin our reiser4 -enhanced 5.15 Long Term Support (LTS) build hack

My initial couple of builds were with GCC-14 under Metztli Reiser4 with chachictetl, i.e., 'kernel', 5.17.15-3 under Debian 13, aka Trixie : Трикси. Subsequently, I installed my newly built LTS 5.15.220 into the same Debian environment. Accordingly, we will be building our LTS under the same LTS chachictetl that we are gonna be building.

Be aware that the resulting perf utility is not suitable to be installed under Debian Trixie, and you will be warned about it if you try. Accordingly, I am using perf from my previous 5.17.15-3 build. Additionally, be aware that official Debian -built Xorg, Mesa, etc., from Trixie backports introduce DRM/video driver feature(s) from chachictetl, i.e., 'kernel(s)', 6.x and above which are incompatible with older 5.15 LTS and 5.17.15. It follows, logically, that you -- as the older kernel user -- should not install Debian official Xorg, Mesa, etc. from Trixie backports because you will lose the hardware -assisted graphical interface feature(s); these being replaced by software -assisted slower graphical interface feature(s).

With those issues elaborated above out of the way, i.e., you want your reiser4 Software Format Release Number (SFRN) 4.0.2, i.e., reiser4 stable, -enabled 5.15 LTS for your server and/or will be careful not to install graphics support from Trixie backports on your Debian desktop, we proceed.

Shell

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

Shell

Subsequently, clone the last official Debian Packaging for 5.15.15, for those of us who hack asymptotically approaching the 'Debian Way' of development.

Shell

Shell

We proceed to verify our chachictetl 5.15.220 LTS integrity:

Shell

Shell

And apply our Debian Packaging for 5.15.220 LTS for reals:

Shell

Observe, the xiuhtzin, i.e., 'blue', hilited additional patch to add RTW89 from upstream; a feature enhancement for Wi-Fi 6 in my laptop and others:

Shell

Shell

Shell

Our enhanced debian packaging for 5.15.220 had specified, a priori, and preselected module RTW89 in debian/config/config

We also verified our RTW89 patch successfully added Wi-Fi 6 support module source by listing the relevant directory:

Shell

Before applying our reiser4 file system patch to 5.15.220 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/modules. However, we still need to reiser4 -enhance the chachictetl 5.15.220 source itself; otherwise, the built chachictetl, i.e., 'kernel', will not find 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.15.220 LTS 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). Yet for this build, we will modify relevant configuration sections for AMD Epyc/Ryzen CPUs:

Shell

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:122: debian/control-real] Error 1
make[1]: Leaving directory '/mnt/chiucuome/usr/tzinti/build/build-totomichin-5.15.220/totomichin-5.15.220/linux'
make: *** [debian/rules:106: debian/control] Error 2

We complete this first stanza with:

Shell

which should not generate any errors.
We test the application of our metztli modified reiser4 for LTS 5.15.220 by specifying the --dry-run flag:

Shell

then apply metztli modified reiser4 for LTS 5.15.220 by deleting the --dry-run flag:

Shell

Needless to say, the application of our metztli for reiser4 patch should not generate any errors on 5.15.220 LTS.

The next task is to concatenate the string '+reizer4.0.2' to the abi in the file debian/config/defines which will indicate that our reiser4 SFRN 4.0.2 -enabled chachictetl, i.e., 'kernel', is targeted at AMD Epyc/Ryzen cpus. We first peek four(4) lines from the top of the relevant file:

Shell

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

Shell

We verify by again implementing directive 20 above. If we are satisfied, then we will increment the kernel patch level in the debian/changelog to reflect the actual chachictetl, i.e., '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

To compare and contrast the original, older, chachictetl, i.e., 'kernel', version string vis-a-vis our modifications, we can view the dch results reflected in the file debian/changelog ; as shown in the screenshot above, I have 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 +reizer4.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

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

Thus build started:

After a fraction of an hour, with eight(8) processor cores specified, the build finished:

---

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.