Coyolxauhqui is another attempt to thoroughly elaborate the intricacies I encountered during my build iterations of reiser4-patched kernels for Debian jessie/stretch-backports; these generated UDEBs are components to subsequently build Metztli-Reiser4 Debian-Installer (d-i). Indeed, I have created a couple of prior posts on the subject; notwithstanding, the procedure in each that worked for the prior Linux kernel 4.xy minor series would fail in the next series as a result of the debian packaging maintainers' modfications. As a matter of fact, in Linux 4 minor versions 11 and 12, I had some trouble figuring out why, after a minor series increase, the linux-headers-*-common_*deb was not being built anymore. Accordingly, the following procedure does build the linux-headers-*-common_*deb and as added bonus generates DEB source and documentation. For illustration purposes I will be building current kernel (as of date creating this post). Finally, I will illustrate again the actual editing of the relevant debian packaging files -- yes I have created a patch that I use but it will be outdated possibly in a couple of kernel minor increments as the Debian maintainer modifies his code. Please bear with me.

Free and Open Source is promoted on the mantra of TECHNICAL MERITOCRACY., but...

One of the fundamental principles of free and open source (FOSS) is that a developer should not be prevented from modifying source code of the software s/he wants to customize. Hence, the more knowledge and options the developer has available to her, the more likely her success in building reiser4 components for her project. Thus a word of advice is pertinent: just do it! because...

If you submit a patch and/or feel like contributing to established FOSS communities, do not be discouraged by those who cherry-pick moralities to suit their narcissism -- and hence ignore the technical meritocracy of your submission(s) to make reiser4 more widely available to their users.
Fact is technology, and specifically FOSS, is a collective effort by humans who are not perfect and are subject to irrationality. Indeed, we could easily point out the double-standards practiced by gatekeepers (a.k.a. maintainers) of established FOSS communities, as they have no qualms about being employed by and/or associated to large companies with an exponentially darker past than the creator of reiser4 himself. With that issue left behind, let's start our reiser4 kernel hack.

Build Reiser4 -patched kernel from Debian Sid (unstable) or from Maintainers' official stretch-backports Linux Source.

Since we are interested in building a relatively recent kernel for stretch-backports, we can do either. In the ensuing elaboration I will be using what Linux kernel and debian packaging source was available at this particular moment of writing. In previous blog I showed how to build the kernel from debian maintainers' official jessie-backports; the procedure for stretch-backports is similar. Accordingly, I will be reiser4 -customizing an unofficial stretch-backports from Debian Sid(Unstable) Linux kernel source.

Note: before you begin, make sure you have installed your kernel proper:

• linux-headers-x.y.t-[]-amd64_x.y.z-[]_amd64.deb
• linux-headers-x.y.t-[]-common_x.y.z-[]_amd64.deb
• linux-kbuild-x.y_x.y.z-[]_amd64.deb
• linux-compiler-gcc-5-x86_x.y.z-[]_amd64.deb

Also, since I am building a newer kernel I will be making extensive use of stretch-backports repository. Evidently, make sure to have the proper directive in /etc/apt/sources.list (open & modify only with a text editor, i.e., xvi tiny vi-clone) As matter of fact, in my builds of Metztli-Reiser4 netboot for Debian Stretch AMD64, nano is dropped in favour of xvi UDEB inclusion and one of the final scripts makes sure to include the repository directive:

deb http://ftp.us.debian.org/debian/ stretch-backports main contrib non-free

and since I am building my own reiser4 Linux source hack, i.e., from unofficial stretch-backports source, I need to include the Sid(Unstable) source repository:

deb-src http://ftp.us.debian.org/debian/ sid main non-free contrib

included as well in /etc/apt/sources.list. Save your modifications.

then, (sudo)

Shell

now, sudo not required, of course, and you may use any text string to name your tekitl directory:

Shell

Modify Debian Packaging to Generate Reiser4 Components

Shell

As elaborated in my first blog on this topic, Building A Reiser4-Patched Development Linux Kernel Package 'The Debian Way'., we need to create a couple of reiser4-modules files and modify contents of three(3) existing ones, which relative paths are:

1. debian/installer/amd64/modules/amd64/reiser4-modules
2. debian/installer/modules/reiser4-modules
3. debian/installer/amd64/package-list
4. debian/installer/package-list
5. debian/config/amd64/defines

We accomplish 1 and 2 above, via a one liner for each:

Shell

Shell

Shell

Add the following two directives before the Package: fat-modules directive:
Package: reiser4-modules
Priority: standard

Shell

Insert next five(5) lines just one blank line below the Package: jfs-modules
Important please observe the correct formatting, i.e., begin the line below 'Description' with a single blank space.

Package: reiser4-modules
Depends: kernel-image, crc-modules
Priority: extra
Description: Reiser4 filesystem support
 This package contains the Reiser4 filesystem module for the kernel.

Shell

Well this last modification is not relevant to reiser4 but simply to decrease the time and amount of data created with debugging, which I will set from default true to false. Additionally, since I am just a lowly hacker -- not an official Debian maintainer -- to prevent my kernel build from failing, I need to specify string to override module signature signing:
signed-modules: false

Now to save us some work the next time need to add reiser4 support to our debian packaging for Linux 4.xy.z, lets create a quick patch:

Shell

Hence, next time you can just patch your debian packaging for Linux 4.xy.z with debian-packaging_reiser4-support.patch and save yourself some work.

Applying Debian Packaging for Linux 4.13.4-2 to Potentially More Recent Upstream Kernel.

we take a peek into the debian packaging changelog inside linux/ directory:

Shell

hmmm, it is debian kernel is 4.13.4-1 and debian packaging debianizes kernel to 4.13.4-2; notwithstanding, upstream kernel.org Linux kernel 4.13.7 was just recently released. Now, due to his responsibility a debian maintainer is source-pedantic and probably would criticize the following hack. Nevertheless, if superb reiser4 was formally in the linux kernel tree we would not have to engage in these dirty hacks which provide satisfactory results after all -- at the very least for me, as reiser4 is all that I compute on.

So my current relative directory location is tekitl-4.13. As detailed previously I have downloaded debian packaging for Linux 4.13.4-2 Sid branch, as well as debian kernel 4.13.4-1 Sid source. I will now download the latest Linux 4.13.7 pristine source from upstream kernel.org.

Shell

and verify its signature:

Shell

Now observe the cosmetic generic name difference between debian Linux source file[1] and the newer Linux source from kernel.org [2]:
[1] linux_4.13.4.orig.tar.xz
[2] linux-4.13.7.tar.xz

this suggests that we can move debian Linux source file out of our tekitl-4.13 directory and replace it with a symbolic link of the same name but will be pointing at the newer linux source file we downloaded last, i.e.,

Shell

illustrating the above:

Now we need to create directory orig/, change location to there, and then create another symbolic link from linux-4.13.4 debian packaging expects to find to the newer linux-4.13.7:

Shell

yes, we need to leave the lower minor version symbolic link as otherwise the debian packaging routine scripts attempt to expand the linux source from parent directory but will fail because it finds a directory already there.

Shell

It is usually the case that a newer kernel from upstream will already have applied some of the patches found at linux/debian/patches. moreover, the debian packaging maintainer probably has not realized it but a section of his patch file
debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch has already been implemented upstream, i.e.,

You may edit the file for this particular case or you may download: series and:

Shell

Accordingly, after some trial and error I realize quilt tries to apply some patches listed in debian/patches/series already applied upstream in Linux source 4.13.7. Thus I proceed to prefix a couple of '##' to the relevant directives:

You may edit the file for this particular case or you may download: drivers-media-dvb-usb-af9005-request_firmware.patch and:

Shell

So now debian packaging for linux-4.13.4-2 should apply smoothly to Linux kernel 4.13.7 source downloaded from kernel.org

Shell

...

Shell

(we can expect a couple of errors)

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
debian/rules:104: recipe for target 'debian/control-real' failed
make[1]: *** [debian/control-real] Error 1
make[1]: Leaving directory '/usr/src/build/kernel/tekitl-4.13/linux'
debian/rules:93: recipe for target 'debian/control' failed
make: *** [debian/control] Error 2

Shell

seems only necessary when rt kernel is to be built, as well.

Now apply proper patch from Reiser4 file system for Linux OS; in this particular case, I had downloaded latest reiser4-for-4.13.0.patch.gz that matched the Linux kernel minor number, i.e., 13:

Shell

...

Now we need to modify Application Binary Interface (ABI) -- I will append the string: +reiser4.0.1, i.e., reiser4 current Software Format Release Number (SFRN) 4.0.1

Shell

Shell

dch warns that metztli is not a recognised distribution

Indeed, I saw that warning and Pressed RETURN to continue...

I will repeat command 33, and I should expect a couple of errors as also previously illustrated.

Shell

Then the following command should only yield one expected error:

Shell

Then we specify target architecture AMD64:

Shell

...

then proceed to reaiser4-customize our Linux kernel 4.13.7 configuration:

Shell

Shell

Note: switch -j8 in command implies 8 cores -- please adjust to your own computing environment.
Additionally, make sure to install required dependencies dpkg-buildpackage may complain about in the above command. Nevertheless, if you know that your Debian Stretch has those dependencies, consider the use of the -d switch as extra argument to dpkg-buildpackage. Do man dpkg-buildpackage for further enlightenment

Kernel build will begin, it will generate source and documentation, too. And more importantly, will generate linux-header-*-common-* package that eluded me for a while.

And, of course, generate reiser4-modules-* UDEB required component for Metztli-Reiser4 netboot debian-installer (d-i).

Now, if I could just move forward and make time to create the nahui posts for the rest of the series (sigh)

---

Nahuatl Glossary:
Coyolxauhqui: 'She who has [jingle] bells [painted] over her face'.
tekitl: work
nahui: four
nahuifs: 'filesystem4'

---

References:
INAH on Twitter: Coyolxauhqui.
La escultura y pintura mexica utiilizaba sólo los colores azul, blanco, rojo, negro y ocre. Foto Héctor Montaño INAH.
Fwd: bug#22113: Initial Reiser4 patch for Parted

---

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 interested in Reiser4 -patched kernel/modules to be embedded in Debian Installer (d-i).

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 and/or even delete it, including blog post, without previous notice.