Download: metztli_avoid-flooding-dmesg-with-unnecessary-info-messages-5_15_220-LTS.patch

Downloading: metztli_avoid-flooding-dmesg-with-unnecessary-info-messages-5_15_220-LTS.patch Metztli Reiser4 chachictetl macuilli.caxtolli.matlactli_om_cempohualli, i.e., kernel 5.15.220, LTS

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

Speaking of Xorg, Mesa, video drivers, etc., to my mind came an artful, sensual, female portrayal of perhaps Foreigner's greatest 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/or the Epstein pedo class moral bankruptcy paradigmatic of the Nazi Adolf Trump and his regime -- and thus be able to appreciate НИКОЛЬ : NICOLE's performance:

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

Before forgetting, since our resources are one directory up from our current shell location, we pass the -r option to ln to create a symlink which works with the linux chachictetl, i.e., 'kernel', string form expected by the Debian packaging:

Shell

we may verify by lsting contents in parent directory.

We need to reiser4 -enhance the Debian Packaging for 5.15.15 bp that we just recently cloned (shell command 4 above) and, as a matter of fact, we are currently operating under its linux directory. I have also, on a best-effort basis, modified the older official Debian patches included as some of them were failing to apply onto the newer 5.15.220 source. Additionally, I have included the source for the RTW89 module from upstream in a patch under the debian/patches directory, prefixed with metztli string. This latter inclusion, hilited in xiuhtzin, i.e., 'blue', in the following snapshot increases significantly the size of the Debian Packaging for 5.15.220 to around eight(8) MB:

Accordingly, I decided to use bzip2 to compress the patch shown in the snapshot above and subsequently attached towards the end of this post. Please, uncompress patch before executing the next task: testing if our patch will apply by specifying the --dry-run flag option.

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:

After succesfully patching, In order for our Debian Packaging for 5.15.220 to debianize our LTS source tree of the same version, we need to ephemerally alter its version. Remember, because the older Debian Packaging was targeted at 5.15.15 backports, we need to increase its patch version to match our LTS chachictetl, i.e., 'kernel', version. We peek at the current older patch version and backports string by the official Debian developer:

Shell

Subsequently, we use the stream editor (sed) to hack debian/changelog file, ephemerally increasing its patch version and doing away with the official Debian developer's backports string:

Shell

Let's debianize our 5.15.220 LTS source tree:

Shell

Update: 09-26-2026
Added drm/amd/display: Avoid flooding unnecessary info messages patch modified for 5.15.220 LTS: prevents spamming your dmesg output

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', utilities will not find the reiser4 Software Release Number (SFRN) 4.0.2 file system source.

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 17 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 directive just below the xiuhtzin, i.e., 'blue', Metztli IT logo 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 chachictetl, i.e., '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)...

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.