Metztli I. T.  Blog

Note: As opposed to previous posts where JPG and PNG images were the norm, in this post copious use of images in WebP format were used. I had to build the utilities to carry out such conversion from PNG formats:

webp_1.4.0-0.2_amd64.deb
webp_1.4.0-0.2_amd64.deb.SHA256SUM
libwebp7_1.4.0-0.2_amd64.deb
libwebp7_1.4.0-0.2_amd64.deb.SHA256SUM
libsharpyuv0_1.4.0-0.2_amd64.deb
libsharpyuv0_1.4.0-0.2_amd64.deb.SHA256SUM
libsharpyuv-dev_1.4.0-0.2_amd64.deb
libsharpyuv-dev_1.4.0-0.2_amd64.deb.SHA256SUM
libwebpdecoder3_1.4.0-0.2_amd64.deb
libwebpdecoder3_1.4.0-0.2_amd64.deb.SHA256SUM
libwebpdemux2_1.4.0-0.2_amd64.deb
libwebpdemux2_1.4.0-0.2_amd64.deb.SHA256SUM
libwebp-dev_1.4.0-0.2_amd64.deb
libwebp-dev_1.4.0-0.2_amd64.deb.SHA256SUM
libwebpmux3_1.4.0-0.2_amd64.deb
libwebpmux3_1.4.0-0.2_amd64.deb.SHA256SUM

Since 2022, when the last Reiser4 SFRN 4.0.2 kernel patch for Linux 5.15.xy was released, we had not released a Metztli Reiser4 netboot installer. I assumed if the reiser4 developer was not releasing any further patches, especially for the then upcoming 6.wx.yz kernel, interest would wane gradually. Notwithstanding, recently -- couple of years later, unexpectedly -- I received a thank you message from a gracious user who, quite frankly, prodded me to create another release for Debian (I assume since Bullseye was the target for the last Metztli Reiser4 release). I glanced at the SourceForge stable Metztli Reiser4 SFRN 4.0.2 downloading site and I was somewhat surprised the reiser4 netboot images and kernel components were still being downloaded. Indeed, I was still running Bullseye with reiser4 SFRN 4.0.2 5.17.12-2 kernel locally and in our remote server(s) but... Debian had already released Amatlocuilin, i.e., 'Bookworm', with kernel 6.wx.yz and I did not know whether a downgraded kernel would work. Further, since we are in effect hijacking...er, hacking , an official Debian netboot installer and by nicely asking 'pretty please' coercing it to install an reiser4 kernel and related utilities in our Metztli Reiser4 modification I knew I had to somehow purge the official kernel since the assumption is that the user has natively created a reiser4 file system on a disk storage medium which the official kernel will fail to boot into.

As a specific instance, below is what happens if the default Debian kernel -- with a higher major version than our reiser4 enhanced kernel -- were not purged and allowed -- accidentally or otherwise -- to boot into a reiser4 -formatted storage media:

(Once the video player has started, right selecting (or 'clicking') your device (or 'mouse') will show menu option, 'Open video in new tab', which will enable larger screen size.)

I became pensive, came out from my oztotl, i.e., cave, and looked up towards the Kamchatka pohpocatepetl, i.e., lit. 'smoking mountains' or 'volcanoes' as inanimate objects have no plural in Nahuatl, and I saw her, Xochiquetzal, consulting with the ephemeral appearance of Tezcatlipoca, 'Smoky Mirror' (see cover image), probably the fate of Tlalticpactli, 'the Earth', in these tumultuous times of potential change. As the 500+ years of the West exclusivity in engaging in genocide, plundering, outright lies, and theft of other peoples resources and destruction of their habitats -- a violent manifestation of a Nazi ideology and disregard for the human development of the recently so-renamed 'Global South' and, instead, forcefully imposing upon them the West's cliches of 'democracy', 'freedom', and 'human rights', which are mere euphemisms to keep their victims in perpetual destitution, displacement (forced, unnatural mass migrations), misery, and death -- are potentially coming to an end, at last!

Observing Xochiquetzal's gorgeous figure, I noticed her chichihualaapilol, i.e., large breasts, since -pilol describes something affected by Tlalticpactli's force of gravity, i.e., hanging in rhythmic pendular motion due to their massiveness property as she climbed the pohpocatepel. Prior to 1492, still free from the bricks of 'Old World' intellectually stunted, patriarchy-oriented, pseudo-religions, it is a fact that in Tlalnepantla, lit. mid-earth but subsequently renamed as 'mesoamerica' by alien European christian terrorist invaders, nudity was common place even at the tianquizco, i.e., the market spot or place -- where we find the -pilol description once again, although in a slightly different context and personified by Titlacahuan, allegedly none other than Teuhctli Tezcatlipoca who willed himself into the peculiar human form of a Huaxtecatl, a naked chilchonamacac, i.e., agglutinated sound of chilchotl∙namacac loosely translated as green chilli vendor¹, from the Huaxtecah peoples' homelands; the latter's region subsequently tainted into the alien vulgar Latin-derived Spanish scum dialect, christian fanatics -inspired, names such as 'Veracruz', 'Hidalgo', 'Querétaro', 'San Luis Potosí', with the possible exception of Tamaulipas (which name allegedly still derives from Huaxtecah language), these are 'states' nigh what is known today as the coast of the Gulf of Mexico.

¹

A fragment of 'History of Tohuenyo', which is generally accepted as referring to the Huaxtecatl human form which Titlacahuan had transformed into to destroy his Teuhctli nemesis, Quetzalcohuatl, by sexually provoking the daughter of Huemac, ruler at Tullan, and thus gain entry into the palace of the Toltecah power seat, ensues:

WARNING, the instance of an archetype of a beautiful female body visual art performance requires the user to be old enough -- and male enough in the West, i.e., unperturbed by the Russophobe Zionist Jew Soro's agenda -- and thus be able to appreciate the role of Huemac's daughter portrayed by АНЖЕЛИКА ≈ ANGELICA:

³

In other words, in Tlalnepantla clothing was optional, as some women often wore just a mesh over their genitalia with a string wrapped around and along their centerline separating their tzintamalli ('hind buns'), i.e., it took the christian fanatic stunted Europeans ~ 500 years to swipe a similar concept for their females!

Ангелина Кузнецова : Angelina Kuznetsova illustrates how the string concept has evolved:

Well, returning to my oztotl...

Needless to say, hacking a Debian Installer (d-i) to coerce it install Reiser4 kernel and reiser4prog file system utilities is -- if not complex -- a time consuming process. The potential for the individual UDEB components hacked to achieve the reiser4 feature to fail in the logic and/or shell scripting modifications is always there -- to bite unexpectedly -- as well as the upstream upgrade of a component, usually leaves our customized d-i crippled. This time busybox became notorious for halting the Metztli Reiser4 booting procedure and I really was stumped as to what was the cause. The Metztli Reiser4 splash came up beautifully during my initial test install into VirtualBox:

Notwithstanding, the satisfaction was short lived as pressing enter to proceed to Expert Install...

the subsequent screen made me panic:

(Approximate sample output begin)
Failed to execute /init (error -2)
Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-3+reiser4.0.2-amd64 #1 Debian 5.17.12-3+reiser4.0.2
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Call Trace:
<TASK>
dump_stack_lvl+0x47/0x5c
panic+0x108/0x2ec
? rest_init+0xd0/0xd0
kernel_init+0x11a/0x120
ret_from_fork+0x22/0x30
</TASK>
Kernel Offset: 0x16400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncyng: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. ]---
(Approximate sample output end)

I created several d-i builds, well into the dawn, during a couple of days, but the end result was always the same. I looked for potential solutions online: some had trouble with Debian recently released 12 Bookworm where 'after an upgrade' they experienced a similar issue; some others had to stick to a certain version of busybox because others (implying newer) produced the issue I was experiencing, and so on, and so forth. I knew I had hacked a newer busybox (1.36.1) than that found in d-i but still was perplexed as to why that would be an issue. Given the fact that I could not even create a running d-i environment to explore its innards, I did the next best thing I could, as root:

Shell

An snapshot summarizes all the above, and we observe the red arrow:

Accordingly, current d-i init expects busybox executable to be at /bin/busybox , but analyzing the Debian packaging for busybox 1.36.1-6 changelog, the path was changed to /usr/bin/busybox :

I had not built busybox for d-i in a couple of years and was unaware when the failing issue was introduced. But I was glad I could pinpoint the issue and implement the least disrupting modification in the Debian packaging for busybox so as to satisfy d-i.

The patch is trivial, of course:

Subject: [PATCH] Ic ce (first) commit enhancing Debian packaging for busybox 1.36.1-9 targeting current Debian Bookworm d-i
---
busybox-udeb.install | 2 +-
busybox-udeb.links | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
create mode 100644 busybox-udeb.links

diff --git a/busybox-udeb.install b/busybox-udeb.install
index 63576af..a075c9f 100644
--- a/busybox-udeb.install
+++ b/busybox-udeb.install
@@ -1,2 +1,2 @@
-b/udeb/busybox usr/bin/
+b/udeb/busybox bin/
debian/tree/busybox-udeb/* /
diff --git a/busybox-udeb.links b/busybox-udeb.links
new file mode 100644
index 0000000..1741b79
--- /dev/null
+++ b/busybox-udeb.links
@@ -0,0 +1 @@
+bin/busybox usr/bin/busybox
--
2.39.5

The end result can be examined once we successfully build our patched busybox again, integrate it and boot our kernel UDEB from our Metztli Reiser4 d-i ; we press Ctrl + Alt + Fn, where n is a TeleTYpewriter (TTY) digit, to open a pseudoterminal and we observe that, in effect, busybox is back under /bin directory and (see the bottom of TTY screen) /usr/bin/busybox is a symbolic link to /bin/busybox

Building a previous major version 5.wx.yz kernel with Debian Bookworm GCC12

The short answer is [kernel tree]/scripts/pahole-flags should be modified or else the kernel build halts midway.

Again, the patch is trivial and is included in the attached reiser4 -enhanced Debian packaging for for 5.17.11-1 towards the end of this post:
Subject: [PATCH] Ic ome (Second) commit Linux 5.17.12 scripts/pahole-flags.sh
modified for GCC12

---
scripts/pahole-flags.sh | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/scripts/pahole-flags.sh b/scripts/pahole-flags.sh
index e6093ad..7acee32 100755
--- a/scripts/pahole-flags.sh
+++ b/scripts/pahole-flags.sh
@@ -17,4 +17,8 @@ if [ "${pahole_ver}" -ge "121" ]; then
extra_paholeopt="${extra_paholeopt} --btf_gen_floats"
fi

+if [ "${pahole_ver}" -ge "124" ]; then
+ extra_paholeopt="${extra_paholeopt} --skip_encoding_btf_enum64"
+fi
+
echo ${extra_paholeopt}
--
2.39.2

Aware of that show stopper issue we leave it behind, and we proceed to fetch the official Debian packaging for 5.17.11-1 as well as linux kernel 5.17.13 source.

NOTE: I was not intending to illustrate the build procedure for another reiser4 -enhanced kernel, but simply show the most relevant Metztli Reiser4 installation screenshots. Notwithstanding, considering the snags I encountered during the previous build procedure of 5.17.12-3+reiser4.0.2, built in Debian Bullseye GCC10, made me realize that illustrating the issues and build procedure for a reiser4 -enhanced 5.17.13-1 kernel built under Debian Bookworm GCC12 was adequate.

As in previous post, we create a working directory totomichin, i.e., 'penguin', in Nahuatl because, why not? The Nahuatl language spoken by the real Mexicah predates all the vulgar Latin -derived dialects of the European invaders who built their lebensraum upon the genocide of upwards of fifty(50) million natives on this stolen continent. Think about it. That's many-fold more than the 'drama queen Zionist Jews' who always play the 'six million' victim card 'Holohoax' to justify their ongoing genocide of the most vulnerable Palestinians in Gaza: women and children. That's an irrefutable fact.

Shell

We verify the kernel signature:

Shell

If you get the message:
(sample output)

...
gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
gpg: Can't check signature: No public key

then,

Shell

and try again

Evidently, since our resources are one directory up from our current shell location, we pass the -r option to ln to create a link which works with the linux kernel string form expected by the Debian packaging:

Shell

Subsequently, we proceed to apply our reiser4 -enabled Debian packaging for 5.17.11-1 (download link is at the end of the blog post):

NOTE: We can assign our long patch name to a three(3) capitalized letter Debian Packaging Patch (DPP) variable:

Shell

Once we verify that our three capitalized letter variable is adequate, we give our patch a dry-run:

Shell

And then we enhance with reiser4 our Debian packaging for 5.17.11-1 using, again, our DPP variable but this time for real:

Shell

Since the linux kernel version in debian/changelog, 5.17.11, differs from that of our downloaded kernel, 5.17.13, we will use sed to ephemerally increase the patch number so as to enable the reiser4 -enhanced Debian packaging for 5.17.11-1 to cleanly debianize (almost) the linux source:

Shell

We proceed to Debianize, i.e., apply Debian bundled patches -- which includes our pahole-flags.sh for GCC12 compatibility patch, to our kernel 5.17.13 source:

Shell

We can now revert back to the original kernel patch level in debian/changelog:

Shell

Subsequently, after we apply the reiser4 SFRN 4.0.2 patch to our linux source we will use dch to increment/modify the debian/changelog 'the Debian Way.'

What we have done is a generic reiser4 -enhanced debianization of the linux souce code. Now we need to decide if we should build our reiser4 -enhanced kernel for Intel CPUs (default), slightly modify it for AMD Epyc/Ryzen CPUs, and/or apply the stable or experimental reiser4 patch to our kernel build.

Applying Reiser4, either Software Framework Release Number (SFRN) stable 4.0.2 OR unstable 5.1.3, and Optionally Customizing 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 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).

Shell

(sample output)

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.

It is also 'normal' to get a bonus 'Error 2'

Then we follow with,

Shell

We verify that our modified Reiser4 patch will apply cleanly onto our Debianized kernel 5.17.13...

Shell

and apply it:

Shell

The next task is to concatenate the string '+reiser4.0.2' to the abi in the file debian/config/defines which will indicate that our reiser4 SFRN 4.0.2 -enabled kernel is a tlilxochitl ['vanilla'] kernel targeted at Intel CPUs. We first peek four(4) lines from the top of the relevant file:

Shell

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

Shell

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

After we save our modifications, we can peek to verify the dch results reflected in the file debian/changelog:

Shell

The screenshot below summarizes the above elaboration, as well as our verification that both files we just modified above contain the proper Reiser4 Software Framework Release Number (SFRN) concatenated respectively:

Shell

Then we proceed with our next Debian incantation; as usual, we can expect a couple of errors in output stream:

Shell

Yet, in the ensuing Debian incantation only one error should be expected when directive finishes:

Shell

For the previous to last debian incantation (observe the red-underlined 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

We may pass the option pkg.linux.nokerneldbg build profile that excludes kernel debug bloat; it worked well under Debian Bullseye but I do not notice much, if any, build-bloat difference under Debian Bookworm:

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

The above 38 and 39 referenced directives are illustrated in the screenshot below:

bpftool_5.17.13-1+reiser4.0.2_amd64.deb
bpftool_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
bpftool-dbgsym_5.17.13-1+reiser4.0.2_amd64.deb
bpftool-dbgsym_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
hyperv-daemons_5.17.13-1+reiser4.0.2_amd64.deb
hyperv-daemons_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
hyperv-daemons-dbgsym_5.17.13-1+reiser4.0.2_amd64.deb
hyperv-daemons-dbgsym_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
libcpupower1_5.17.13-1+reiser4.0.2_amd64.deb
libcpupower1_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
libcpupower1-dbgsym_5.17.13-1+reiser4.0.2_amd64.deb
libcpupower1-dbgsym_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
libcpupower-dev_5.17.13-1+reiser4.0.2_amd64.deb
libcpupower-dev_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-compiler-gcc-12-x86_5.17.13-1+reiser4.0.2_amd64.deb
linux-compiler-gcc-12-x86_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-config-5.17_5.17.13-1+reiser4.0.2_amd64.deb
linux-config-5.17_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-cpupower_5.17.13-1+reiser4.0.2_amd64.deb
linux-cpupower_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-cpupower-dbgsym_5.17.13-1+reiser4.0.2_amd64.deb
linux-cpupower-dbgsym_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-doc_5.17.13-1+reiser4.0.2_all.deb
linux-doc_5.17.13-1+reiser4.0.2_all.deb.SHA256SUM
linux-doc-5.17_5.17.13-1+reiser4.0.2_all.deb
linux-doc-5.17_5.17.13-1+reiser4.0.2_all.deb.SHA256SUM
linux-headers-5.17.0-3+reiser4.0.2-amd64_5.17.13-1+reiser4.0.2_amd64.deb
linux-headers-5.17.0-3+reiser4.0.2-amd64_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-headers-5.17.0-3+reiser4.0.2-cloud-amd64_5.17.13-1+reiser4.0.2_amd64.deb
linux-headers-5.17.0-3+reiser4.0.2-cloud-amd64_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-headers-5.17.0-3+reiser4.0.2-common_5.17.13-1+reiser4.0.2_all.deb
linux-headers-5.17.0-3+reiser4.0.2-common_5.17.13-1+reiser4.0.2_all.deb.SHA256SUM
linux-headers-amd64_5.17.13-1+reiser4.0.2_amd64.deb
linux-headers-amd64_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-headers-cloud-amd64_5.17.13-1+reiser4.0.2_amd64.deb
linux-headers-cloud-amd64_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-image-5.17.0-3+reiser4.0.2-amd64_5.17.13-1+reiser4.0.2_amd64.deb
linux-image-5.17.0-3+reiser4.0.2-amd64_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-image-5.17.0-3+reiser4.0.2-cloud-amd64_5.17.13-1+reiser4.0.2_amd64.deb
linux-image-5.17.0-3+reiser4.0.2-cloud-amd64_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-image-amd64_5.17.13-1+reiser4.0.2_amd64.deb
linux-image-amd64_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-image-cloud-amd64_5.17.13-1+reiser4.0.2_amd64.deb
linux-image-cloud-amd64_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-kbuild-5.17_5.17.13-1+reiser4.0.2_amd64.deb
linux-kbuild-5.17_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-kbuild-5.17-dbgsym_5.17.13-1+reiser4.0.2_amd64.deb
linux-kbuild-5.17-dbgsym_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-libc-dev_5.17.13-1+reiser4.0.2_amd64.deb
linux-libc-dev_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-perf_5.17.13-1+reiser4.0.2_amd64.deb
linux-perf_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-perf-dbgsym_5.17.13-1+reiser4.0.2_amd64.deb
linux-perf-dbgsym_5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
linux-source_5.17.13-1+reiser4.0.2_all.deb
linux-source_5.17.13-1+reiser4.0.2_all.deb.SHA256SUM
linux-source-5.17_5.17.13-1+reiser4.0.2_all.deb
linux-source-5.17_5.17.13-1+reiser4.0.2_all.deb.SHA256SUM
linux-support-5.17.0-3+reiser4.0.2_5.17.13-1+reiser4.0.2_all.deb
linux-support-5.17.0-3+reiser4.0.2_5.17.13-1+reiser4.0.2_all.deb.SHA256SUM
usbip_2.0+5.17.13-1+reiser4.0.2_amd64.deb
usbip_2.0+5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM
usbip-dbgsym_2.0+5.17.13-1+reiser4.0.2_amd64.deb
usbip-dbgsym_2.0+5.17.13-1+reiser4.0.2_amd64.deb.SHA256SUM

Metztli Reiser4 / Debian installer (d-i) expert install option, accepting default partitioning scheme with reiser4, and installing Enlightenment Window Manager via a hack by typing relevant components in the field provided:

connman terminology enlightenment bluez bc pulseaudio packagekit udisks2 ddcutil gdb xorg

(Once the video player has started, right selecting (or 'clicking') your device (or 'mouse') will show menu option, 'Open video in new tab', which will enable larger screen size.)

---

¹It is highly likely that the reference to the so-often-emphasized 'green chilli' refers to the now well known Spanish scum dialect corruption, 'jalapeño', which implies its origin in Xalli∙atl∙pan, i.e., lit. Sand∙water∙upon ≈ 'spring [water emanating in] the sand', which, agglutinated in Nahuatl, is Xalapa, which again was corrupted into Spanish scum dialect as Jalapa, now the capital of so-called 'Veracruz' state, in that region of the Huaxtecah peoples.

Ofrendas de chile verde (chilchotl) en el calendario mexica : Offerings of green chilli (chilchotl) in the Mexicah Calendar

²Wired Humanities Nahuatl word: Tlapilotica

³ León-Portilla, M. «La Historia Del Tohuenyo: Narración erótica náhuatl ≈ The History of Tohuenyo: Nahuatl erotic narrative». Estudios De Cultura Náhuatl, vol. 1, mayo de 1959, pp. 95-112

"... in 1930, the distinguished Nahuatlahto, i.e., Nahuatl speaker, John H. Cornyn, based on the same Florentine Codex, published an English translation and in verse format of all what he called 'The Song of Quetzalcoatl', in which the 'History of the Tohuenyo' was included.⁸”

⁸Cornyn, John H.: ,The song of Quetzalcoatl, Yellow Springs, Ohio, 1930, 1930, pp. 83-94
...
"Finally, in 1952, Charles E. Dibble and Arthur J. O. Anderson, who have began the commendable task of paleographing and translating the complete texts of the often mentioned Florentine Codex, have already published the content material for book III, in which our history is included, as well.⁹"

⁹Dibble, Charles E. and Anderson, Arthur J. O.: Florentine Codex, Book Three, The Origin of the Gods, Santa Fe, N. Mex., 1952, pp. 17-20.

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.