The reiser4 file system patches currently available for Linux kernel 5.10 (as of February 20, 2021) have not been updated to address the 'historic ditching [of] defunct addressing artefact... called set_fs()'. Although the patch series introducing that change in the then still upcoming Linux kernel 5.10 date back from circa August 2020: remove the last set_fs() in common code, and remove it for x86 and powerpc, I can only speculate the reiser4 developer did not anticipate the disruptive effect it was going to have on his work -- as he released reiser4 patches for both stable Software Framework Release Number (SFRN) 4.0.2 and unstable SFRN 5.1.3, aka 'reiser5', for the kernel 5.10. Notwithstanding, I find it odd that I had not read of any bug reports as to the suitability of reiser4 to the Linux 5.10 kernel. But then I created a set of reiser4 -patched Linux 5.10.1 RC kernels for Metztli Reiser4 / Reiser5 d-i installers: None of them worked!
This post represents, thus, an overview of the regression procedure to have reiser4 file system re-enabled in the Linux 5.10 kernel series.
kernel read not supported for ...
Upstream patches reiser4-for-5.10.2.patch.gz and/or reiser4-for-5.10-rc3.patch.gz produce the kernel read not supported for ... text string pattern in my custom Debian Installer (d-i) operation halted:
debootstrap: /usr/sbin/debootstrap: line 1596: /target/test-exec: Invalid argument
kernel: [ 1018.632648] kernel read not supported for file /test-exec (pid: 10077 comm: debootstrap)
debootstrap: E: NOEXEC
debootstrap: EF: Cannot install into target '/target' mounted with noexec or nodev
base-installer: error: exiting on error base-installer/debootstrap-failed
main-menu: WARNING **: Configuring 'bootstrap-base' failed with error code 1
main-menu: WARNING **: Menu item 'bootstrap-base' failed.
and/or boot failure followed by a kernel panic verbose output after a reiser4 -enabled kernel 5.10.x replacement and reboot:
kernel read not supported for file usr/lib/systemd/systemd (pid: 1 comm: run-init)
kernel panic -- not syncing: Attempted to kill init! exitcode=0x00000100
Unable to figure out what was going on, I emailed the reiser4 developer: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\) -- providing an elaborate explanation and including snapshots. After a few hours, the reiser4 developer replied, carbon copying the Linux kernel development mailing list and requesting input from the developer of the patch series -- specifically -- singling out commit 4d03e3cc59828c82ee89ea6e27a2f3cdf95aaadf in that series as the reason for the failures:
This is because of VFS changes in Linux-5.10.X. Specifically, because of the following patch: https://lkml.org/lkml/2020/8/17/174 In the upstream git repository it is commit 4d03e3cc59828c82ee89ea6e2
So, Christoph, what to do now for file systems which implement ->read() method of file operations? It seems that chroot doesn't work for them. And people are not able to release distros with upgraded kernels..
A few days passed-by and the obnoxious1 indifference of the Linux kernel developer of that patch set was glaring. I engaged in further research online and came across Seth Robertson's On undoing, fixing, or removing commits in git. Not being a git pro myself, I thought the interactivity of the resource was cool and began my attempt to strip away the commit of reference after I git cloned the Linux kernel 5.10 source. A day or two passed and I realized that such specific commit was too embedded so as to be stripped away cleanly. Nevertheless, I tried a couple of kernel 5.10 builds using the kernel source tree minus whatever extraction of the referenced commit I was able to achieve. The result was additional 'kernel read' failures. Inductively I gained no insight into the problem.
While reviewing my notes and pondering on stripping more thoroughly the commit of reference, I came across a previously saved RuTube link to a красивое девичье лицо thumbnail resource -- which in the past required several loops to jump through. Notwithstanding, this time clicked on the link and -- to my surprise -- it was available!
WARNING, although it is an instance emanating from an archetype of a beautiful female body visual art, you are required to be old enough -- and male enough in the West -- to appreciate it. Катрин's xiuhtzin [бирюзовый : turquoise] eyelids are reminiscent of the way the original Mexicah women colored their own eyelids.
I continued my online research; in the nvidia forums someone experienced another aspect of 'kernel read not supported' and complained 'it was not trivial reverting this patch and here’s all the work that got into removing set_fs() et al...'
Well, that last link made me ponder whether the patch set was interdependent and -- unless one were a professional kernel developer/maintainer -- no single commit could be stripped away as it might depend on other(s) which were modified in a complementary scheme. Accordingly, I split the patch set into its individual commits and began utilizing the patch -R utility against the then current kernel 5.10 branch. My initial approach was to begin with first (as listed in the patch set file) commit but as I worked incrementally through the procedure I realized some overlap was occurring. Thus, I decided to begin with the last commit (as listed at the end of the patch set file) successively decrementing the procedure. That seemed to work best. Once I finished reverting most of the patch set in a judicious manner, I noticed non-AMD architecture arch/Kconfigs remained and I removed them -- as my main motivation was to create as streamed down kernel patch as possible to re-enable reiser4 on Linux 5.10 on the AMD64 architecture. That is how I ended up creating the patch applied to this kernel running in the computing environment where I am writing this blog post:
Overview of our hack to create a Reiser4 -enabled Linux 5.10 kernel build the 'Debian way' with GCC 8 targeted at Buster backports
Prior post Exposing Hacks for ZSTD -compressed Metztli Reiser4 / Debian Buster bps Linux 5.5.caxtolli∙omome and initramfs walked us on how to reiser4 -enable a Debian packaging for Linux x.y.z release by analyzing the target files and utilizing text utilities like sed to modify relevant sections. We then created patches in order to ease the burden of manual conversion(s) to reiser4. Here, we will be utilizing patches already created in the manner illustrated a priori to create another typical reiser4 -enabled Linux 5.10 kernel. Please find the patches attached at the end of this post.
Starting a one-off kernel build we create our working directory and git clone Debian packaging for 5.10.17-1 for Sid (unstable), still UNRELEASED:
After the cloning, we proceed to analyze the contents of the new linux directory and finish by peeking into its changelog:
We can see that the Linux packaging has been updated for Linux 5.10.17-1. Nevertheless, it appears that Debian Linux kernel unstable source available is still version 5.10.13-1 at the moment. We will fetch the Linux upstream release to match our downloaded Debian packaging for 5.10.17-1. We will verify its integrity, as well as untar the linux source tree.
Now I have created a patches directory where I have generated symlinks to my patches (attached below, too) -- as I have them in different local directory locations. From the patch directory I will be applying the relevant patches to carry out our hack on linux-5.10-17 directory. I begin by applying the patch to revert the issue expanded at the beginning of this post and thus enable Linux 5.10 'kernel read' on reiser4 file systems:
Notice in the above command that I passed the -d option to the patch utility so that it operates on the directory given.
I follow the above operation by applying the JFS for 5.11 patch onto linux-5.10.17 source directory:
As can be observed the patches applied smoothly and what we need to do now is create an orig directory -- and inside -- create a symlink to the linux-5.10.17 which will help Debian packaging find the linux source tree.
Subsequently, I change location to the Debian packaging linux directory and apply the patch to enable generation of Reiser4 modules and utilize the GCC8 for our build:
The next command will debianize the Linux 5.10.17 source tree (thus operating on the previously symlinked ../orig/linux-5.10.17 source, quilting the debian/patches onto the linux-5.10.17 source tree directory -- bringing the debianzed linux source tree to our current linux directory location inside the Debian packaging environment. We are all set!
We should expect a couple of errors during the next Debian packaging tools incantation:
And finish this session with Debian packaging tools sourceing incantation:
Reiser4 -patching the Debianized Linux kernel source tree
At this inflection point we can apply either of Reiser4 Software Framework Release Number (SFRN) 5.1.3 unstable, aka reiser5 OR 4.0.2 stable -- both attached at the end of this post. But Note that fsck.reiser4 still doesn't work with 5.1.3. Consequently, I will be applying reiser4 stable.
Passing the --dry-run option to the patch utility we can verify that the patch I previously modified for kernel 5.10.13 still applies smoothly to our current kernel 5.10.17 source:
Then I apply the patch for real -- passing the --no-backup-if-mismatch option to the patch utility (yes, I have already compared any backups to their patched modifications) so as not to leave an .orig backup file around.
As shown in the clip above, no errors should occur and no .rej files should be generated.
I use a text editor (xvi, tiny vi clone) in iztaccihuatl wrapper -- as in previous Exposing Hacks for ZSTD -compressed Metztli Reiser4 / Debian Buster bps Linux 5.5.caxtolli∙omome and initramfs -- to modify debian/config/defines file, concatenating the character string +reiser4.0.2 to its ABI:
and proceed to annotate similar in debian/changelog -- as well as incrementing the kernel version to reflect the additional patches we have applied:
We verify that both files we just modified contain the proper Reiser4 Software Framework Release Number (SFRN) concatenated respectively:
and proceed with our next Debian incantation; as elaborated in Exposing Hacks for ZSTD -compressed Metztli Reiser4 / Debian Buster bps Linux 5.5.caxtolli∙omome and initramfs, we can expect a couple of errors in output stream:
Notwithstanding, only one error should be expected when the next Debian incantation finishes:
For the previous to last debian incantation you may want to redirect the output and any potential errors, if any, into a log file to analyze afterwards. It is a fact that if any errors are logged during the make procedure the build will fail:
Again, we are ready to build our kernel hack the 'Debian way'... Tlayecuel : Поехали : Let's go!
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)
(Please read man dpkg-buildpackage)
After a while, depending on your computing power, our Metztli Reiser4 hack of Linux macuilli.matlactli build completes.
We Eat Our Own Digital Cooking!
1 Linux has a problem, which is that with success it is attracting people with more skill than what it started with, and it is not doing a very good job of handling that. In fact, it downright stinks at it, behaving in the worst way it could choose for handling that. We have lost quite a number of FS developers who just don't want to deal with people who know less than they do but are obnoxious and disrespectful to submissions because they enjoy powertripping...
[Linux] should develop a culture in which acceptance is more based on whose code measurably performs well than on who is friends with whom.
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.