OS/2 2.11 SMP Bootable CDROM 10 Minute Installation Hack into VirtualBox

There was, still is, something appealing about OS/2 -- it was ahead of its time, Warp indeed -- The Integrating Platform. I came across some relevant resources and created an OS/2 2.11 Bootable CDROM media for VirtualBox -- as I heard, through the grapevine, that it was undoable. :))

OS/2 enabled me to learn Unix by utilizing the GNU/Linux utilities ported by OS/2 hackers. Accordingly, once IBM orphaned the OS/2 -- and the executives even balked at our multiple petitions to have the OS open sourced -- the transition to Linux was relatively painless. As a matter of fact, while creating this hack I had to bring my old ported GNU/Linux utilities, alternating between OS/2 2.0, 2.1x, and even Warp 3, environments so as to alleviate the shortcoming of 640x480 resolution.

Due to the scarcity of information, I usually operate by inductive reasoning. Notwithstanding, I came across the following 'nugget':
OS/2 has supported SMP for quite a while in special editions of OS/2. The first version was 'OS/2 2.11 for Symmetrical Multiprocessing'...
The diffences between the single-processor OS/2 and the SMP version are very small: 2 APIs for controlling the CPUs, an extra index for DosQuerySysInfo() and 4 APIs for dealing with spinlocks. I know that the 'SMP addendum' mentions a lot of other things, but they are server things, not SMP things.

'OS/2 2.11 SMP' supports up to 16 processors,...

Yet my build of VirtualBox, from source, under a Metztli Reiser4 Debian environment can only go up to 8 processors/cores and :no: higher resolution than 640x480...

(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. Alternatively, the video with larger screen size may be shown in the Calli, i.e., 'Home', collection front page)

Update 12-18-2022 : my personal development computing environment can only go up to eight(8) cores; however, I installed another Oracle VirtualBox 7.0.4 -- although 'headless' -- in one of my remote Metztli Reiser4 servers. I made use of VNC to make connection and although Remmina experience a buggy pointer (or mouse) I was able to bring up the SMP Monitor. I could not delay this event as it is not everyday that an OS/2 for Symmetrical Multiprocessing (SMP) Version 2.11 is seen running on 16 CPU/Cores!

OS/2 for SMP Version 2.11 remote instance accessed via VNC

(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. Alternatively, the video with larger screen size may be shown in the Calli, i.e., 'Home', collection front page)

View OS/2 for SMP v2.11 Reference
View OS/2 for SMP v2.11 Reference
OS/2 for SMP v2.11 Reference at Hobbes but requires OS/2 INF VIEW.EXE utility or 'INF READER'


Platform Specific Drivers (PSDs)

In OS/2 for SMP V2.11, all of the platform specific code has been removed from the operating system, and placed into a Platform Specific Driver. These drivers provide an abstraction layer for the underlying hardware by allowing the operating system to call generic functions to perform platform-specific operations without worrying about the actual hardware implementation. This allows OS/2 for SMP V2.11 to support new MP hardware platforms without modifying the operating system.

PSDs are 32-bit flat DLLs specified in CONFIG.SYS by using the PSD= keyword, and must conform to the 8.3 file naming convention (e.g. PSD=BELIZE.PSD). They cannot contain either drive or path information because OS/2 cannot process such information at the stage of the startup sequence when the PSD statements are processed. The root directory of the startup partition is first searched for the specified file name, followed by the \OS2 directory of the startup partition. If drive or path information is included in a PSD statement, an error is generated.

PSD parameters may be specified after the PSD's name, and may be a maximum of 1024 characters long. The parameter string is not interpreted or parsed by OS/2, but is passed verbatim as an ASCIIZ string when the PSD's Install function is invoked.

If multiple PSD statements are encountered, OS/2 will load each PSD in the order listed in CONFIG.SYS, and call the PSD's install function. The first PSD which successfully installs will be the one OS/2 uses.

PSD statements are processed before BASEDEV, IFS, and DEVICE statements."



NOTE: If you want to acquire this OS/2 2.11 SMP Bootable CD/ISO image hack, it comes in a bottle opener USB stick:

Bottle opener USB stick
Bottle opener USB stick

and includes the IBM base OS/2 2.1 floppy images on which the hack was loosely based.

Device Drivers and MultiMedia
Device Drivers and MultiMedia


OS/2 2.1 installation diskettes
OS/2 2.1 installation diskettes

1 EDM/2 SMP - Symmetrical Multiprocessing

OS/2 2.11 SMP in VirtualBox 6.1.32
OS/2 2.11 SMP in VirtualBox 6.1.32

Ольга Пронина (Monika9422) её видео

'One of the biggest advantages of my hobby is that a motorbike disciplines you. Thanks to him, I'm in perfect physical shape because motorbikes are not for weak women.'~ Olga spoke in her blog of her motorbike as if it was a person1

Subsequent her tragic death, I had posted her video to one of fascist 'Murika's censorship...er, 'social,' media platforms. Recently, however, I came across it in my local storage media and... well, here it is:

1 Queen of bikers killed in horrific crash leaving her teenage daughter motherless
Ольга Пронина

Hacking an OS/2 2.1 Floppy Set or CDROM Into a Bootable CDROM Media / ISO Image

(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. Alternatively, the video with larger screen size is shown in the Calli collection front page)

Although IBM OS/2 3.x Warp and higher indigitalizations have been hacked into bootable CDROM media / ISO images, I believe this is the first OS/2 2.x which has been morphed into such an unique entity. The procedure was not easy -- and obviously not intuitive. The work required to make the cdboot hack complete the first phase of the OS/2 2.1 installation was substantial; and once I achieved it I thought that whatever else needed to be done would be easier. I was mistaken. I had to compile an utility to search for and replace strings in the OS/2 2.1 CONFIG.SYS file at the end of the first phase of the OS/2 installation -- as I could not find an appropriate binary one in my extensive local collection of Hobbes CDROM media, etc., nor online at Hobbes site and/or elsewhere.

Had IBM released the OS/2 code as free and/or open source software (FOSS) instead of being so indifferent to the multiple petitions to do so (for instance those in which I personally took part at the OS2World site before I left the site for good -- as I had moved on to GNU/Linux Debian) the avaricious plutocrat Bill Gates' mediocre 'creation', backdoored software, idiotically named as a mundane household notion, 'windows,' would not have spread like the virus it emulates.

Generating an OS/2 2.1x bootable CD under GNU/Linux Debian -based Metztli Reiser4:


genisoimage --b boot/boot.img -c boot/boot.catalog -o os2bootcd.iso .

Generally speaking, even if your bootable two(2) disk image is successfully created, if  it can not make the transition to the OS/2 disks layout on the CD, i.e., can not detect it due an older driver like IBM1S506.ADD (see snapshot below), the boot procedure will stop with the output:

The system cannot find the file "A:\COUNTRY.SYS". This device driver, program, or data file is not located in the default path or the path specified for it in the CONFIG.SYS file. Install this file in the correct directory, or correct the appropriate CONFIG.SYS file statement.

The system is stopped.

Correct the preceding error and restart the system.

OS/2 2.1.x Bootable CD error due to older IBM1S506.ADD
OS/2 2.1.x Bootable CD error due to older IBM1S506.ADD


cmd /"PACK bundle.list bundle /L"

If, unlike myself, you are not using the Korn Shell under OS/2, then the command delimited by double quotes is sufficient.
OS/2 PACK a list of files
OS/2 PACK a list of files

Creating bootable CD-ROMs

(work in progress)

Social engineering scam ALERT: "Subject: Hackers have access to your device. Check details ASAP!"

Spoofed email bitcoin scam
Spoofed email bitcoin scam

Not in our name, Mofos!

Social engineering mass email campaign(s) where spoofed email addresses -- including at least one of ours -- have been used by Internet scum mofos targeting the hard earned finances of unsuspecting users. Below is one of two identical ones that we came across.

'Hello there
Let me introduce myself first - I am a professional programmer, who specializes in hacking during my free time.
This time you were unlucky to become my next victim and I have just hacked the Operating System and your device.

I have been observing you for several months.
To put things in a simple way, I have infected your device with my virus while you were visiting your favorite adult website.

I will try to explain the situation in more details, if you are not really familiar with this kind of situations.
Trojan virus grants me with full access as well as control of your device.
Hence, I can see and access anything on your screen, switch on the camera and microphone and do other stuff, while you don't even know that.

In addition, I also accessed your whole contacts list at social networks and your device too.

You may be questioning yourself - why didn't your antivirus detect any malicious software until now?

- Well, my spyware uses a special driver, which has a signature that is updated on a frequent basis, hereby your antivirus simply cannot catch it.

I have created a videoclip exposing the way you are playing with yourself on the left screen section, while the right section shows the porn video that you were watching at that point of time.
Few clicks of my mouse would be sufficient to forward this video to all your contacts list and social media friends.
You will be surprised to discover that I can even upload it to online platforms for public access.

The good news is that you can still prevent this from happening:
All you need to do is transfer $1350 (USD) of bitcoin equivalent to my BTC wallet (if you don't know how to get it done,
do some search online - there are plenty of articles describing the step-by-step process).

My bitcoin wallet is (BTC Wallet): 1NToziZKcJfyxHpwkcxbafwghGasme4NUf

Once I receive your payment, I will delete your kinky video right away, and can promise that is the last time you hear from.
You have 48 hours (2 days exactly) to complete the payment.
The read notification will be automatically sent to me, once you open this email, so the timer will start automatically from that moment.

Don't bother trying to reply my email, because it won't change anything (the sender's email address has been generated automatically and taken from internet).
Don't try to complain or report me either, because all my personal information and my bitcoin address are encrypted as part of blockchain system.
I have done my homework.

If I discover that you have tried forwarding this email to anyone, I will right away share your kinky video to public.

Let's be reasonable and don't make any stupid mistakes anymore. I have provided a clear step-by-step guide for you.
All you need to do is simply follow the steps and get rid of this uncomfortable situation once and for all.

Best regards and good luck.

The above is copied verbatium from two identical emails from two(2) different email address senders of which one of them is spoofed from at least one of our legit email addresses used by our organization. We did not email the above crap!

Hacking a Reiser4/Zstd (SFRN 4.0.2) -patched Build of Debian Linux 4.14.Cempohualli-Ce for AMD64.

(Use your right mouse pointer on image to show video controls and/or to Open video in new tab -- recommended)

Official 4.14.x iterations of Debian kernel packaging for Unstable (Sid) ended with 4.14.17-1. Accordingly, there is no Debian kernel packaging for current upstream release Linux 4.14.20 and much less named its Nahuatl equivalent: Cempohualli: twenty and Ce: one. Moreover, the currently available Reiser4 patch is for kernel 4.14.1+; thus I had to find a way to debianize last kernel packaging if it was to successfully wrap around pristine kernel.org's Linux 4.14.20. The latter, i.e., Cempohualli, is a beautiful number; full of symbolism for existing Nahuatl speaking real Mexicah. What follows are my annotations to carry out the somewhat involved build procedure.

First oddity. Beginning with upstream kernel 4.14.18, Debian kernel packaging for 4.14.17-1 will fail to build:

LD vmlinux.o
MODPOST vmlinux.o
arch/x86/entry/syscall_64.o: In function `x32_enable':
syscall_64.c:(.init.text+0x8): undefined reference to `system_call_fast_compare_end'
syscall_64.c:(.init.text+0xe): undefined reference to `system_call_fast_compare'
syscall_64.c:(.init.text+0x19): undefined reference to `system_call_mask_compare_end'
syscall_64.c:(.init.text+0x1f): undefined reference to `system_call_mask_compare'
syscall_64.c:(.init.text+0x33): undefined reference to `system_call_fast_compare'
syscall_64.c:(.init.text+0x3f): undefined reference to `system_call_mask_compare'
make[5]: *** [vmlinux] Error 1
[]/build/kernel/tekitl-4.14.18/linux/Makefile:998: recipe for target 'vmlinux' failed
make[4]: *** [sub-make] Error 2
Makefile:146: recipe for target 'sub-make' failed
make[3]: *** [__sub-make] Error 2
Makefile:24: recipe for target '__sub-make' failed
make[3]: Leaving directory '[]/build/kernel/tekitl-4.14.18/linux/debian/build/build_amd64_none_amd64
make[2]: *** [debian/stamps/build_amd64_none_amd64] Error 2
debian/rules.real:190: recipe for target 'debian/stamps/build_amd64_none_amd64' failed
make[2]: Leaving directory '[]/build/kernel/tekitl-4.14.18/linux'
make[1]: *** [binary-arch_amd64_none_amd64_real] Error 2
debian/rules.gen:24: recipe for target 'binary-arch_amd64_none_amd64_real' failed
make[1]: Leaving directory '[]/build/kernel/tekitl-4.14.18/linux'
make: *** [binary-arch] Error 2
debian/rules:50: recipe for target 'binary-arch' failed
dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2

Accordingly, if I wanted to build current upstream Linux 4.14.20 'the Debian way', i.e., to generate DEBs as well as UDEBs suitable for Metztli-Reiser4 netboot Debian-Installer (d-i), I had to figure out the issue above.

After considerable effort I found there are a few updated patches we must apply from current Debian kernel packaging master 4.15.4-1 git repository to our Debian kernel packaging unstable (Sid) 4.14.17-1 for this latter to build my downloaded Linux 4.14.20 from upstream:


Additionally, I modified 4.14.17-1 packaging

because 4.14.20 newer kernel already had these security fixes applied.

Now, assuming the Debian kernel packaging default , i.e., to build the real-time (RT) kernel and headers, we get second oddity.

Although the first set of patches for the Debian 'vanilla' kernel applied smoothly, if the developer desired to build the real-time (RT) kernel and headers to subsequently patch all with reiser4 -- which I did -- I had to implement another small hack to fix the following issue:

Applying patch features/all/rt/preempt-lazy-support.patch
Applying patch features/all/rt/ftrace-Fix-trace-header-alignment.patch
Applying patch features/all/rt/x86-preempt-lazy.patch
1 out of 5 hunks FAILED
Patch features/all/rt/x86-preempt-lazy.patch does not apply (enforce with -f)
debian/rules.real:145: recipe for target 'debian/stamps/source_rt' failed
make[2]: *** [debian/stamps/source_rt] Error 1
make[2]: Leaving directory '/[]/build/kernel/nahui.matlactetl_onnahui.cempohualli/linux'
debian/rules.gen:989: recipe for target 'source_rt_real' failed
make[1]: *** [source_rt_real] Error 2
make[1]: Leaving directory '/[]/build/kernel/nahui.matlactetl_onnahui.cempohualli/linux'
debian/rules:26: recipe for target 'source' failed
make: *** [source] Error 2

Evidently debian/patches/features/all/rt/x86-preempt-lazy.patch applied by quilt with fuzz=0 fails at arch/x86/include/asm/thread_info.h since the latter has an extra line of code in the Linux 4.14.20 source tree:
u32 status; /* thread synchronous flags */

which quilt attempted to patch thread_info.h to be subsequently copied over into RT kernel build directory:

thus I modified slightly debian/patches/features/all/rt/x86-preempt-lazy.patch 1 so it could apply after the above referenced line of code.

It worked...

Otherwise, if you do not want to build the real-time (RT) kernel and headers, edit with a text editor (like xvi &#59;)
xvi debian/config/defines

and locate the lines:

enabled: true

and change 'true' text string to false, i.e.,

enabled: false

save your changes and close debian/config/defines

In summary. I used last 'official' Debian kernel packaging 4.14.17-1 for Unstable (Sid) as base. I then applied the above operations plus other reiser4 hacks for Stretch elaborated in previous post(s); thus generating a Metztli Reiser4 Debian kernel packaging for 4.14.Cempohualli...er, 20, suitable to build a stretch-backports kernel and which resulting source code I subsequently uploaded to Github.

Hacking a Reiser4/Zstd (SFRN 4.0.2) -patched Build of Debian Linux 4.14.Cempohualli-Ce for AMD64.
Real Mexicah used a base Cempohualli, i.e., twenty, for their number theory and cherished the expressiveness, non-linearity, of their language: Nahuatl. Those characteristics enhanced their mathematical acumen to apprehend, appreciate, and imitate, nature and Nehnencacitlalli ['the cosmos']. In stark contrast, pseudo-'Mexicans' from 1821 onward, i.e., descendants of Spanish scum invaders who -- like their mother country Spain -- lag several centuries behind in science and technology[1], only have tainted their colonized masses with infinite ignorance.

[1] Kant.

Building Reiser4/Zstd (SFRN 4.0.2) stretch-backports Linux 4.14.Cempohualli-Ce for AMD64

Assuming a proper development environment to build our kernel 'the Debian way' as elaborated a priori in other post(s), we can build upstream Linux kernel 4.14.20, thus:

mkdir --verbose nahui.matlactetl_onnahui.cempohualli
...er, well that's Nahuatl for 4.14.20 -- which you could name your working directory. I will just make a symbolic link:

ln -s nahui.matlactetl_onnahui.cempohualli 4.14.20

cd nahui.matlactetl_onnahui.cempohualli

Download Debian kernel packaging hacked for Linux 4.14.20 from GitHub:
git clone https://github.com/Metztli/reiser4-debian-kernel-packaging-4.14.20.git linux

(Do something while it downloads as it approaches 1Gb of data)

After the cloning procedure finishes, we make a linux sym link:

ln -s reiser4-debian-kernel-packaging-4.14.20 linux

then download kernel 4.14.20 from upstream:
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.14.20.tar.xz

Let's create a symbolic link in the format that Debian kernel packaging expects:
ln -s linux-4.14.20.tar.xz linux_4.14.20.orig.tar.xz

and change into linux directory
cd linux

Edit debian/changelog:
xvi debian/changelog

Locate the text string:

linux (4.14.17-1) unstable; urgency=medium

and remove the number 17 and insert 20, instead, i.e.,

linux (4.14.20-1) unstable; urgency=medium

save your changes.

Now we are ready to build the kernel 'the Debian way' as we did in previous post(s).

Added bonus &#59;)
Likely fix for Bug#885166: instability with 4.14 regarding KVM virtualization

since referenced commit:
https://lists.debian.org/debian-kernel/2018/02/msg00173.html seems to be already applied to Linux kernel source tree 4.14.20.

YES! Bug#885166 has been fixed in 4.14.20!...
"If I used git correctly, then 4.14.20 already has 2a266f23550be997d783f27e704b9b40c4010292, so I tried 4.14.19. 4.14.19 on the one virt host that had the most violent failures failed in the first hour of operation, but with a slightly different error behavior that I was used to. I am therefore not sure whether we are not talking about multiple issues, one of them having been fixed somewhere in between 4.14.13 and 4.14.19."

1 RE: x86: Support for lazy preemption in Debian Linux 4.14.20 AMD64

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 reflects 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 desire reiser4 on GNU/Linux Debian.

Nevertheless, 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 download and/or implement the procedure and/or shell commands described here s/he or them, do so at her, his, or their own risk. You have been forewarned.

Jose   ,   Feb 25 / 06:23
Categories: reiser4