Download: jfs-5.11-for-5.10.15.patch

Downloading: jfs-5.11-for-5.10.15.patch Reiser4 and Linux version Macuilli.Matlactli, i.e., 5.10

Your download will start shortly...
If nothing happens, please click here.

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[330]: WARNING **: Configuring 'bootstrap-base' failed with error code 1
main-menu[330]: WARNING **: Menu item 'bootstrap-base' failed.

Debian Installer (d-i) kernel read not supported for file /test-exec (pid: 10077 comm: debootstrap)

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

kernel read not supported for file usr/lib/systemd/systemd (pid: 1 comm: run-init)

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 obnoxious¹ 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] ixcuatolli [веки : eyelids] are reminiscent of the way the original Mexicah women colored their own.

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:

Linux kernel 5.10.14-2+reiser4.0.2

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:

Shell

mkdir --verbose macuilli-matlactli
cd macuilli-matlactli
git clone -b sid --single-branch https://anonscm.debian.org/git/kernel/linux.git

After the cloning, we proceed to analyze the contents of the new linux directory and finish by peeking into its changelog:

Shell

head linux/debian/changelog

git clone Debian packaging for Linux

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.

Shell

wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.17.tar.xz https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.17.tar.sign
xz -dc linux-5.10.17.tar.xz | gpg --verify linux-5.10.17.tar.sign -
tar -xPf linux-5.10.17.tar.xz

Enlightenement Window Manager terminal emulation, EFL -based Terminology, displays gravatar of the kernel developer who signed the Linux source as I hover my pointer over his email address.

fetching and verifying upstream Linux kernel source

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:

Shell

cat patches/linux-5.10.14-enable-kernel-read-on-reiser4m.patch | patch -d linux-5.10.17 --fuzz=0 -p1

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:

Shell

cat patches/jfs-5.11-for-5.10.15.patch | patch -d linux-5.10.17 --fuzz=0 -p1

applying linux-5.10.14-enable-kernel-read-on-reiser4m.patch

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:

Shell

cat ../patches/reiser4-gcc8-metztli-debian-packaging-for-5.10.17-1.patch | patch --fuzz=0 -p1

Reiser4 / GCC8 -enabling Debian packaging for Linux

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!

Shell

debian/rules orig

Debianizing the Linux source code under Debian packaging environment

We should expect a couple of errors during the next Debian packaging tools incantation:

Shell

debian/rules debian/control

debian/rules debian/control

And finish this session with Debian packaging tools sourceing incantation:

Shell

fakeroot debian/rules source

debian/rules source

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:

Testing whether reiser4 stable patch will still apply onto more recent kernel

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.

Shell

gzip -dc ../patches/reiser4-for-metztli-5.10.13-stable.patch.gz | patch --no-backup-if-mismatch --fuzz=0 -p1

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:

Shell

iztaccihuatl debian/config/defines

concatenate proper Reiser4 SFRN string to ABI in debian/config/defines

and proceed to annotate similar in debian/changelog -- as well as incrementing the kernel version to reflect the additional patches we have applied:

Shell

dch -v 5.10.17-2+reiser4.0.2 -D metztli

Utilizing Debian tool dch to modify debian/changelog

We verify that both files we just modified contain the proper Reiser4 Software Framework Release Number (SFRN) concatenated respectively:

Shell

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

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:

Shell

debian/rules debian/control

debian/rules debian/control expect couple of errors

Notwithstanding, only one error should be expected when the next Debian incantation finishes:

Shell

fakeroot debian/rules debian/control-real

fakeroot debian/rules debian/control-real expect single error

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:

Shell

fakeroot make -f debian/rules.gen setup_amd64_none_amd64

Again, we are ready to build our kernel hack the 'Debian way'... Tlayecuel : Поехали : Let's go!

Shell

dpkg-buildpackage -F -us -uc -jX -T binary-arch,binary-indep

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.

Metztli Reiser4 -enabled Debian Linux macuilli.matlactli build completes

We Eat Our Own Digital Cooking!

Reiser4 root fs and Linux 5.10.17-2

References:
Виктория Одинцова : Viktoriya Odintcovo ~ Viki- Xochiquetzal's Instagram

¹ 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, i.e., meritocracy, than on who is friends with whom.

the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

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.

Mon	Tue	Wed	Thu	Fri	Sat	Sun
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30
<< <				> >>

	`mkdir --verbose macuilli-matlactli`
	`cd macuilli-matlactli`
	`git clone -b sid --single-branch https://anonscm.debian.org/git/kernel/linux.git`

	`wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.17.tar.xz https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.17.tar.sign`
	`xz -dc linux-5.10.17.tar.xz \| gpg --verify linux-5.10.17.tar.sign -`
	`tar -xPf linux-5.10.17.tar.xz`