Metztli Information Technology Blog Bits

I happened to came across the need to enable advanced multi layered unification filesystem (Aufs) -- now at version 3.x (thus, Aufs3) -- module support into a GNU/Linux Debian deployment. It had been a while that I had done something similar by customizing the kernel to enable that feature. Well, surprise! Nothing has changed. Well, let me rephrase that, Aufs development continues; however, we still have to somehow hack the feature into the linux kernel tree version desired. Below I describe a procedure that worked on Debian and linux kernel 3.12.2, that is, the latest stable kernel source on this date.

Given the fact that cahuitl means the space of time in Nahuatl (Mexico's language par excellence), and a certain place, area, or surface in n-dimensional space is referred to as tlacauhtli, I was inspired to create a working directory appropriately named for the task at hand :P

mkdir -p --verbose /usr/src/tlacauhtli/build

Of course, prefixing sudo for the privilege to execute the above command (and similar others) is necessary if you are not already wielding root privilege; either way, the root (or super user) privilege is necessary to create directory(ies) at /usr/src directory since in Debian the default owner and group is root as shown with command:

ls -ld /usr/src
(sample output)...
drwxr-xr-x 8 root root 376 Nov 28 00:10 /usr/src/

We will not touch those default permissions but will manipulate those of the directories we initially created for our operations.

Now find out if your_username already belongs to Debian's src group:

groups your_username

Membership in the group src must be included in the output since, for security, we will want to operate as a non-root user. If the output does not show that your_user is a member of src group, then, wielding root privilege we should add the normal user who will be doing the Aufs3 and kernel build operations as a member of Debian's src group:

adduser your_username src

For the privileged permissions to take effect, your_username must logout and then login back again. Subsequently entering command again:

groups your_username

the output should show that your_username is a privileged member of Debian's src group (amongst others).

your_username should now be ready to begin her Aufs3 hack into the kernel tree.

But first root should grant and/or modify access permissions on our work area tlacauhtli and its subdirectory build, as below.

Still wielding root privilege, we subsequently grant src group ownership and writing privilege on the tlacauhtli directory where the operations will take place.

chmod -R g+w /usr/src/tlacauhtli

grants writing privilege to the group on directories tlacauhtli and its subdirectory build

chgrp -R src /usr/src/tlacauhtli

grants group ownership to the members of src group (which includes your_user) on directories tlacauhtli and its subdirectory build

Below is a rather verbose snapshot summary from bash shell on Debian:

Now, we assume the identity of a normal non-root user, of course, you will assume your_username that we elaborately granted src group membership and privileges to operate on tlacauhtli and its subdirectory build directories. Now empowered, we change to tlacauhtli directory:

$ cd /usr/src/tlacauhtli

We start by downloading the latest stable kernel by visiting The Linux Kernel Archives. For security you are encouraged to check integrity of the files downloaded and scan them for malware.

For instance, if you have clamav, you may scan the uncompressed files as:

$clamscan downloaded_file

If you already uncompressed the files, you can recursively check the directory trees and only print out if infected files were found as:

$clamscan -ri uncompressed-file_directory

(Please do man clamscan and read for further information).

NOTE: If your Debian does not have the clamav anti-virus, wielding root privilege download and install as: apt-get install clamav

Verify Integrity Of Your Downloaded Kernel Releases By Verifying The Corresponding Signatures...

Linux kernel releases PGP signatures

Assuming we downloaded the compressed linux kernel tree linux-3.12.2.tar.xz and it is at our current location, we download its corresponding signature with wget utility (all in a single line directive)

NOTE: If your Debian does not have wget and/or bzip2, wielding root privilege download and install as: apt-get install wget bzip2 bc (indeed, you will need bc - An arbitrary precision calculator language - in your kernel building efforts.

$wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.12.2.tar.sign

In order to be verified, linux-3.12.2.tar.xz should be decompressed and left in tar format (see Using GnuPG to verify kernel signatures ). As illustrated, the procedure can be accomplished step by step or in a one liner concatenation directive. I have decide to go with the latter:

$xz -dc linux-3.12.2.tar.xz | gpg --verify linux-3.12.2.tar.sign -

(sample output)...
gpg: Signature made Fri 29 Nov 2013 11:29:20 AM PST using RSA key ID 6092693E
gpg: Can't check signature: public key not found

I take as input the RSA key ID to download the public key from the PGP keyserver in order to verify the signature, thus:

$gpg --recv-keys 6092693E --keyserver subkeys.pgp.net

alternatively, if the above directive fails, try:

$gpg --keyserver pgp.mit.edu --recv-keys 6092693E
(sample output)...
gpg: requesting key 6092693E from hkp server subkeys.pgp.net
gpg: key 6092693E: public key "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)

I rerun gpg --verify...:

$xz -dc linux-3.12.2.tar.xz | gpg --verify linux-3.12.2.tar.sign -
(sample output)...
gpg: Signature made Fri 29 Nov 2013 11:29:20 AM PST using RSA key ID 6092693E
gpg: Good signature from "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

For this post, we will stop our verification process here. Nevertheless, you may decide to continue the procedure by following:

'You will now need to verify that the key used to sign the archive really does belong to the owner...'

I refresh my Debian repositories:

Shell

and download the necessary tools/utilities to build my kernel:

$apt-get install build-essential kernel-package patch fakeroot libncurses5 libncurses5-dev git


Now I change from my current tlacauhtli to subdirectory build

$cd build

and decompress my kernel, simultaneously untar'ing it:

$tar -xvJPf ../linux-3.12.2.tar.xz

"it becomes clear that 'Aufs was rejected. Let's give it up.' According to Christoph Hellwig, linux rejects all union-type filesystems but UnionMount."

Aufs at SourceForge

Since I am interested in building Aufs3 as a module, at this particular time the aufs3-standalone GIT tree enables that CONFIG_AUFS_FS=m option; hence, I download it:

git clone git://git.code.sf.net/p/aufs/aufs3-standalone aufs3-standalone.git

and change into the referenced directory:

$cd aufs3-standalone.git

and remember to specify the minor number of the kernel we are building. Thus, in our case, I have emphasized the minor number of the kernel 3.12 for inclusion in the next command:

$git checkout origin/aufs3.12

(sample output)...

Note: checking out 'origin/aufs3.12'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

HEAD is now at 4a7364f... aufs3.12 20131111

and proceed to create a couple of directories to prepare a patch for the linux kernel tree:

$mkdir --verbose ../x ../y

How you name those remains at your discretion but I named them x and y. The following sequence of commands should operate on the directory ../y/.

Code

In the above commands, the verbosty (-v) is optional.

Make sure to remove Kbuild:

$rm -v ../y/include/uapi/linux/Kbuild

else you should specify 'no' when prompted by the patch utility whether it should replace Kbuild in your linux kernel tree.

We go back to our previous directory, i.e., build:

$cd ..

And perform the following operations:

Code

We are ready to apply the patch; we change directory to our linux kernel tree source:

$cd linux-3.12.2

And apply the patch:

$patch -p1 < aufs.patch

You will observe a long output to your bash shell but no errors.

Yolahuialtia [Cheers!] You have just patched your latest stable linux kernel tree :)

As I am upgrading from my currently running linux kernel 3.12.0, I will import the relevant .config into my spanking new and Aufs-patched linux kernel tree:

$cat /boot/config-`uname -r` >.config

and do:

$make oldconfig
(sample output)...
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
*
* Restart config...
*
*
* Miscellaneous filesystems
*
[...]
SquashFS 4.0 - Squashed file system support (SQUASHFS) [M/n/y/?] m
Squashfs XATTR support (SQUASHFS_XATTR) [Y/n/?] y
Include support for ZLIB compressed file systems (SQUASHFS_ZLIB) [Y/n/?] y
Include support for LZO compressed file systems (SQUASHFS_LZO) [Y/n/?] y
Include support for XZ compressed file systems (SQUASHFS_XZ) [Y/n/?] y
Use 4K device block size? (SQUASHFS_4K_DEVBLK_SIZE) [Y/n/?] y
Additional option for memory-constrained systems (SQUASHFS_EMBEDDED) [N/y/?] n
[...]
OS/2 HPFS file system support (HPFS_FS) [M/n/y/?] m
[...]
Aufs (Advanced multi layered unification filesystem) support (AUFS_FS) [N/m/y/?] (NEW) m

Indeed, the directive above prompts as to whether install Aufs as a mdule, which I agree to by specifying to enable Aufs support as a module by typing: m

And subsequently follow additional options:
(sample output)...
Maximum number of branches
> 1. 127 (AUFS_BRANCH_MAX_127) (NEW)
2. 511 (AUFS_BRANCH_MAX_511) (NEW)
3. 1023 (AUFS_BRANCH_MAX_1023) (NEW)
4. 32767 (AUFS_BRANCH_MAX_32767) (NEW)
choice[1-4?]:
Detect direct branch access (bypassing aufs) (AUFS_HNOTIFY) [N/y/?] (NEW)
NFS-exportable aufs (AUFS_EXPORT) [N/y/?] (NEW) y
Readdir in userspace (AUFS_RDU) [N/y/?] (NEW) y
Respect the attributes (mtime/ctime mainly) of special files (AUFS_SP_IATTR) [N/y/?] (NEW)
Show whiteouts (AUFS_SHWH) [N/y/?] (NEW)
Ramfs (initramfs/rootfs) as an aufs branch (AUFS_BR_RAMFS) [N/y/?] (NEW) y
Fuse fs as an aufs branch (AUFS_BR_FUSE) [N/y/?] (NEW) y
Hfsplus as an aufs branch (AUFS_BR_HFSPLUS) [Y/n/?] (NEW)
Debug aufs (AUFS_DEBUG) [N/y/?] (NEW)

If I do a:

$make xconfig

I can observe and configure graphically Aufs support in the kernel tree:

The moment to build our Debian custom linux kernel has finally arrived! Do:

$fakeroot make-kpkg clean

And I proceed to build my kernel: Xonecuiltzin which :yes: prefixed with a leading dot, I provide as an argument to --append-to-version in the directive that follows:

$time fakeroot make-kpkg --append-to-version=.xonecuiltzin --stem aufs -j8 --initrd kernel_image kernel_headers

I also provide aufs as an argument to --stem because I want to know the main reason for my kernel customization. Additionally, I provide 8 as an argument to -j. Eight(8) represents the number of threads I wish to launch, hence I make it equal to the number of cores in my machine where I am building the kernel -- for optimum performance during compilation.

After a few minutes, the build procedure ends and I take a look a my newly created Debian kernel and headers DEB packages, thus:

$ls ..
(sample output)...
aufs3-standalone.git/ linux-3.12.2/
aufs-headers-3.12.2.xonecuiltzin_3.12.2.xonecuiltzin-10.00.Custom_amd64.deb x/
aufs-image-3.12.2.xonecuiltzin_3.12.2.xonecuiltzin-10.00.Custom_amd64.deb y/

To install our newly built Xonecuiltzin kernel on Debian, we need to acquire root privilege or prefix the command below with sudo:

$dpkg -i aufs-image-3.12.2.xonecuiltzin_3.12.2.xonecuiltzin-10.00.Custom_amd64.deb

... yeah, include the path if your kernel is not at your current directory location ;-)

---

Nahuatl quote found in an IAEA Publication (PDF) titled: Analytic Number Theory & The Nuclear Level Density.

The quote is attributed to Cuauhtemoc, last ruler of the Mexicah. On August 13, 1521, after the death of some 250,000 Mexicah and besieged for 79 days, Cuauhtemoc's metropolis Mexico-Tenochtitlan fell to the large invading armies of indigenous enemies of the Mexicah led by a small number of Spanish mercenary plunderers. After being tortured unsuccessfully to reveal hidden gold by the avaricious Spaniards, Cuauhtemoc was revered by the surviving Mexicah as Xonecuiltzin, "The Limping one", the same name/title by which one of their Deities, Tezcatlipoca, was also known.

REFERENCES:
How To Roll A Kernel the Ubuntu/Debian Way
Kernel 3.9 on Debian Wheezy/Testing
Compile Debian Kernel (Squeeze) 3.0 and Above with Aufs and squashfs
COMPILING Linux kernel version 3..2.6 | r4mi5

DISCLAIMER:P although due diligence has been applied, this resource is made available for testing/evaluation purposes on an AS IS basis. The procedure only reflect my own modifications, my limited testing, and the potential user who executes the procedures assumes all risks.

Please do not hold me or Metztli Information Technology 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 who need Aufs support on Debian.

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.

Coming from OS/2 and learning my first GNU/Linux commands at the OS/2 command shell -in an ported public domain Korn shell (ksh) emulated environment- I can not help but peek, once in a while, into the pond from which I emerged. A couple of days ago, I visited the OS/2 World forum and scrolled the initial page for something new. Perhaps, I thought, Serenity Systems International -the last vendor of an fixpacked OS/2 known as eComStation- might have developed an booting procedure or hack that emulated the Linux booting procedure.

If true, I continued submerged in my revery, then I could build an OS/2 instance into an virtual machine to be hosted in an Infrastructure as a Service (IaaS) provider like Amazon. To my dismay, I only found what I regarded as an mundane issue that could be resolved in a jiffy (if an OS/2er were to be a little more open minded) -that of accessing OS/2 created JFS partition from an GNU/Linux distribution.

In preparation for a migration from an OS/2 installed base to an modern Linux alternative, the user was interested in knowing how to access OS/2 created JFS partitions from an Ubuntu Live distribution. Her/his concerned lied in the fact that whenever he tried to mount an certain OS/2 JFS partition from the Live Ubuntu distribution, the message in his Linux shell output would be along the form:

mount: wrong fs type, bad option, bad superblock on /dev/xyz,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

Well I just happened to have reinstalled an Linux Debian unstable distribution. No, the install is not from a “live” CD but it will help to illustrate an potential solution to the OS/2 administrator evaluating methods to migrate existing OS/2 deployments into GNU/Linux.

First of all, to exercise administrative duties in enterprise Linux, the user becomes root (or super user). Please note that from the perspective of Debian cfdisk utility, OS/2 created JFS partitions will be seen as of file system (FS) Type: Unknown (35). The reason may possibly be due to the fact that the LVM.EXE or LVMGUI.CMD disk management utilities of an appropriately upgraded OS/2 require a created physical partition to be of type LVM; otherwise formatting in the OS/2 implementation of Journaling File System (JFS) will not proceed. Hence, the GNU/Linux cfdisk utility does not appear to recognize the type of the OS/2 created partition and regard those as Unknown (35).

Observe the screenshot below:

cfdisk /dev/hda

Additionally, note that if you hard drive is IDE, of course, you will see the Primary partitions as hda1, hda2, and hda3. Partition hda4 represents the whole extended partition; when this latter is sub-partitioned, the first extended (sub)partition is hda5, hda6, etc.. Also note from the snapshot that if Primary partitions hda2 and/or hda3 are non existent, their places are reserved; as can be observed, the very first logical (sub)partition skips over the reserved slots for Primary partitions and starts at hda5. Obviously, if your hard disk is SCSI the device seen with the cfdisk utility will be of the form sda1, sda2, etc..

Please note that Red Hat and Fedora, at the very least, may also refer to IDE drives as sda1, sda2, etc.. I just want to call your attention to the fact that under all conditions, you should verify that the Linux operating system and you are on the same page. Fedora 11, in my limited tests, was able to mount JFS partitions. Notwithstanding, for this blog I used Debian.

BACK UP YOUR JFS PARTITIONS DATA.

Avoid unnecessary woes by diligently backing up all your OS/2 JFS partitions data during the migration planning stage. Technology, being a human creation and subject to unanticipated variables, is not perfect.

Additionally, please verify that you have the Debian jfsutils package. As root user, from the command line in your Linux shell you can simply type:

apt-get update

apt-get install jfsutils

Or if you prefer to install those visually with the synaptic package manager, from the Debian desktop menu, select System, Administration, and subsequently press the Synaptic Package Manager item from the cascading options.

Alternatively, as the root user, you may just type:

synaptic

and the package manager will come into existence, as well. Either way you access Synaptic, press the Search button from the wide menu of the utility and when the search utility appears, proceed to enter the text string "jfs" into the field. After some seconds, the jfsutils will be listed among other packages that met the criteria. Selecting the item jfsutils from the list will provide additional information: Utilities for managing IBM's Journaled File System (JFS) under Linux. Hence, after installtion of the package, you will have in your Linux Debian distribution: fsck.jfs, logdump, logredo, mkfs.jfs, xchkdmp, xchklog, xpeek.

MAKE SURE YOUR TARGET DEVICE IS NOT MOUNTED.

Reading the man page for jfs_fsck (or fsck.jfs) we note the warning: serious damage may occur if we check a mounted file system in other than READ ONLY access.

man jfs_fsck

After verifying that our target JFS partition(s) is(are) not mounted, and scrolling further down in the man jfs_fsck information, we come across the command to form to check our OS/2 created JFS partiton(s): jfs_fsck -v -f /dev/hdxy.

As an specific example, I selected the 26GB /dev/hda10 seen in the initial cfdisk snapshot at the beginning of this blog. Accordingly, if the hypothetical Linux user xiuhtecuhtli became root (or super user) of his GNU/Linux Debian sytem, he would enter the following command to check and fix (-f) his previous OS/2 created and formatted JFS partition:

jfs_fsck -v -f /dev/hda10

After performing the adequate JFS modifications on the OS/2 partition, the jfs_fsck front end utility for fsck.jfs finishes; and xiuhtecuhtli would be able to mount his 26GB OS/2 created JFS partition in an relevant directory created under /mnt, be typing:

mount /dev/hda10 /mnt/hda10

Please note that the above procedure will not work on OS/2 Logical Volume Manager (LVM) volumes spanning multiple devices/partitions. If an user tries to access one of the spanned entities composing an OS/2 LVM volume, the mount process will fail; also, if an file system check is performed on a device/partition component of the spanned OS/2 LVM volume, it may corrupt the target. Accordingly, make sure that you know -from the OS/2 side- which units are part of an spanned OS/2 LVM volume. For instance, see this snapshot of an past OS/2 Java-based utility that can be invoked as lvmgui.cmd in your OS/2 command shell environment.

Java 2 SE 1.4.1 native port for OS/2 is by Golden Code Development (GCD).

One final note. If an GNU/Linux root (or super user) mounts an OS/2 created and formatted partition -even if JFS checks and fixes are performed from the Linux side- an regular non-root user will likely not be able to view the contents of that file system. The reason is because all or most of that data will not have appropriate permissions, as seen in this sample ls -l command operating on the directory /mnt/hda10/xxe-std-3_5_1:

ls -l /mnt/hda10/xxe-std-3_5_1

total 28
d--------- 7 root root 256 2007-02-02 18:00 addon/
d--------- 7 root root 4096 2007-02-02 12:17 bin/
d--------- 2 root root 4096 2007-02-24 14:52 binHTML/
d--------- 9 root root 4096 2007-02-01 17:06 demo/
d--------- 17 root root 4096 2007-02-01 17:06 doc/
d--------- 2 root root 256 2007-02-24 12:44 Xiuhtecuhtli/
d--------- 2 root root 4096 2007-02-02 20:13 webstart/
---------- 1 root root 6778 2007-02-24 12:33 XXE-STD-3_5_2.zip

What the OS/2 turned Linux admin needs to do is to apply pertinent permissions to the files so that regular users are able to use and/or access the data. For an specific instance, if the root user needs to modify all the files in a directory to be world readable and or writable (r or w) use the chmod command with -R option to specify recursively all of the files in that directory.

chmod -R a+r /mnt/hda10/xxe-std-3_5_1

ls -l /mnt/hda10/xxe-std-3_5_1

total 28
dr--r--r-- 7 root root 256 2007-02-02 18:00 addon/
dr--r--r-- 7 root root 4096 2007-02-02 12:17 bin/
dr--r--r-- 2 root root 4096 2007-02-24 14:52 binHTML/
dr--r--r-- 9 root root 4096 2007-02-01 17:06 demo/
dr--r--r-- 17 root root 4096 2007-02-01 17:06 doc/
dr--r--r-- 2 root root 256 2007-02-24 12:44 Xiuhtecuhtli/
dr--r--r-- 2 root root 4096 2007-02-02 20:13 webstart/
-r--r--r-- 1 root root 6778 2007-02-24 12:33 XXE-STD-3_5_2.zip

Additionally please note that for an user in Linux to be able to use data s/he may need additional permissions such as being the owner and/or group member allowed to manipulate the data. Accordingly, the OS/2 admin turned to Linux admin (root user) should make use of the chown command to achieve her/his purpose.

As the OS/2 remains anchored in the past and with no supporting organization providing continued development -much less a clear road map for its future- OS/2 admins will be forced to migrate. Metztli Information Technology will be glad to provide migration and/or support services provided the target platform is resilient, secure, open source - open standards: GNU/Linux.

---

DISCLAIMER Please do not hold me or Metztli Information Technology 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 OS/2 users and/or administrators considering GNU/Linux as their organizations' migration platform.

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 reserves the right to modify the content of the post or even to delete it altogether.

Note: This list collection of ia32-lib packages was successfully tested on x64 Fedora 10. I did not test them on x64 Fedora 11 nor x64 Fedora 12. Recently, however, I realized that the packages listed here do not even exist in x64 Fedora 13. Accordingly, I updated the list of packages in this list to reflect modifications done in the x64 Fedora 13 distribution. In order to minimize confusion, I deal with the issue and make available the relevant updated list in another blog entry: Hosting Providers Embrace of The Cloud Enabled by Open Source Virtualization Technologies. 08/10/2010

---

In an past how-to blog entry I described an procedure to install the 32-bit IBM Lotus Symphony office productivity suite under an 64-bit GNU/Linux Fedora 9 distribution. I mentioned that I had used the GNU/Linux 64-bit Debian ia32-libs suite package as a guide to figure out which packages would provide equivalent functionality in 64-bit Fedora 9 distribution. Notwithstanding, I was forced to realize that metztli-F9-ia32-libs.text, the list of packages that I made available for others as an aid to solve an similar issue as my own, was version specific. This short post is an update on metztli-F9-ia32-libs.text so as to make the list of packages more generically applicable to Fedora 9, Fedora 10, and Fedora 10+.

An kind comment by an user that used the pseudonym "Nobody" actually drew my attention to the need for the packages listed in metztli-F9-ia32-libs.text not to be version specific. At the time of Nobody's comment, well, I thought that making the packages listed in metztli-F9-ia32-libs.text version agnostic would be achieved simply by editing the file with vim, Elvis, or any other text editor. As an way of illustration, I downloaded metztli-F9-ia32-libs.text and opened it with my vim text editor:

In effect, once metztli-F9-ia32-libs.text had been opened for editing in the vim text editor, pressing the Esc key at our keyboard and following that with the colon character ":", the percent character "%", and the letter "s" for substitution, we achieve 77 substitutions at once. Below is an snapshot of the end of metztli-F9-ia32-libs.text file showing the substitutions in that relevant section:

Nevertheless, there are a few files that require special attention --if they are to support 32-bit applications in an distribution release agnostic GNU/Linux 64-bit Fedora. Those are listed below, first as the file was listed in the older metztli-F9-ia32-libs.text and subsequently as listed in metztli-Fedora_agnostic-ia32-libs.text:

• compat-libstdc++-33-3.2.3-63.i386 to compat-libstdc++-33.i386
• libaio-0.3.106-4.2.i386 to libaio.i386
• jack-audio-connection-kit-0.109.2-1.fc9.1.i386 to jack-audio-connection-kit.i386
• java-1.6.0-openjdk-1.6.0.0-0.15.b09.fc9.i386 to java-1.6.0-openjdk.i386
• compat-expat1-1.95.8-4.i386 to compat-expat1.i386
• libgcrypt-1.4.0-3.i386 to libgcrypt.i386

And I had a duplicate of jack-audio-connection-kit-0.109.2-1.fc9.1.i386 ; hence metztli-F9-ia32-libs.text should have contained a list of 80 74 packages (a big thanks to "an observer" 06-09-2009), instead of the 81 that I asserted in the post IBM Lotus Symphony 1 on 64-bit GNU/Linux Fedora 9 Sulphur. referenced initially.

Well, after detailing the procedure that I followed to generalize the prior 64-bit Fedora 9 specific package support for 32-bit applications listed in metztli-F9-ia32-libs.text, I now make available metztli-Fedora_agnostic-ia32-libs.text. This file will list version agnostic 32-bit packages that should work under 64-bit Fedora 9, Fedora 10 and possibly higher, since the packages providing the equivalent of Debian ia32-libs package likely are Fedora distribution release independent.

As referenced in the alluded past how-to blog entry, after the user downloads metztli-Fedora_agnostic-ia32-libs.text to his 64-bit Fedora distribution, s/he should install the listed packages by entering suggested commands at her 64-bit GNU/Linux Fedora shell terminal.

As an specific illustration, we assume that the user has become the root or super user in her 64-bit GNU/Linux Fedora 9, Fedora 10, or later; we further assume that the file metztli-Fedora_agnostic-ia32-libs.text was downloaded to her current file system location in her shell. Then the super user or root should install the support for 32-bit applications under her 64-bit Fedora by typing below commands:

for i in $(< metztli-Fedora_agnostic-ia32-libs.text); do yum -y install $i; done

DISCLAIMER although due diligence has been applied, the metztli-Fedora_agnostic-ia32-libs.text resource is made available for testing/evaluation purposes on an AS IS basis. Those files listed in the resource only reflect my own modifications on my limited testing --as expounded above and elswhere-- and the potential user that manipulates any or all of those (files) assumes all risks.

Please do not hold me or Metztli Information Technology 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 AMD 64-bit GNU/Linux Fedora 9, Fedora 10 and higher distribution release, users.

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 Information Technology

...An [almost] infinite capacity for taking pains [engineering]¹:

IT solutions based on free and open source software (FOSS) and select open standards proprietary alternatives.

¹Jane Ellice Hopkins, Work Amongst Working Men, 1870
Camp's Unfamiliar Quotations From 2000 B.C. To The Present.