Building on previous work, where I had built GCC 1.40 using the OS/2 hosted Microsoft C compiler that shipped with this Pre-Release, and using MinGW to build Linux 0.11, it was time to combine the two, like chocolate & peanut butter!

Getting NT ready

The first thing I wanted was to install the Pre-Release onto a HPFS disk. I’ve uploaded this over on archive.org (Windows NT December 1991 prepped for Qemu). I took the CD-ROM image, removed all the MIPS stuff, built a boot floppy, and setup the paths so that the floppy can boot onto the secondary hard disk to a ‘full’ version of NT. This lets me format the C: drive as HPFS, and then do a selective install of Windows NT to ensure that that the software tools (compiler) are installed.

I use a specially patched vintage QEMU build, qemu-0.14.0.7z which kind of makes it ‘easier’, along with the needed disk images in dec-1991-prepped.7z

qemu.exe -L pc-bios -m 64 -net none -hda nt1991.vmdk -hdb nt1991-cd.vmdk -fda boot.vfd -boot a

This will bring up the boot selection menu. The default option is fine, you can just hit enter.

NT will load up and you now have to login as the SYSTEM user. We need the advanced permissions to format the hard disk.

From the desktop we first format the C: drive as HPFS. I made icons for all this stuff to try to make it as easy as possible.

You’ll get asked to confirm you want to do this, and give the disk a creative name.

And with the disk formatted it’s time to start the setup process.

Who are you?

And what slick account do you want? It doesn’t matter tbh.

I’m going to do a custom install as the NIC’s aren’t supported, and even if they were it’s just NetBEUI anyways.

And select your hardware platform. NT basically only supports this config, so it doesn’t matter.

The default target drive is our C drive, which we had just formatted to HPFS.

Next, I unchecked everything only leaving the MS Tools

It’ll offer the samples & help files. I always install them as I eventually need examples of stuff to steal, and to learn that including <windows.h> won’t work right unless you manually define a -Di386 on the command line. I’m saving you this pain right now up front.

Files will copy, and on a modern machine this takes seconds.

And there we go!

And Windows NT is installed.

Yay.

I put in a ‘CAD’ feature in this Qemu hitting control+alt+d will send the familiar pattern, and after a few times NT will reboot. We are pretty much done with NT for the moment, but congrats you’ve installed the December 1991 Pre-release onto a HPFS disk for those sweet long long file names!

Going over the strategy:

I’ve already built GCC 1.40 for NT, so what is the rest of the stuff needed to build Linux? It’s a quick checklist but here goes, in no specific order:

• GCC 1.40
• bin86
• binutils
• gas 1.38
• bison
• unzip
• zip

Luckily as part of building on Windows 10 using MinGW, I had fixed the weird file issues as MS-DOS/Windows NT/OS2 handle text/binary files, as we went through with how Github mangled MS-DOS 4.00.

The primary reason I wanted a working zip/unzip was to deal with long file names, and to auto convert text files. And this ended up being an incredible waste of time trying to get the ‘old’s code on the Info-Zip page.

I’m sure like everything else, the old versions are removed as they probably suffer from some catastrophic security issue with overflows. The issue I ran into is that the version 5 stuff uses so many features of shipping NT, to even 2000 that it was going to be a LOT of work to get this far. The quicker & easier path as always turned out to be a time machine.

Thankfully, since I had made a copy of the UTZOO archives, I was able to fish out, both version 3.1 from the archives. Also known as “Portable UnZIP 3.1”, parts 1/2/3. I also found version 4.1 as well. And people wonder why you want to save these ‘huge’ data sets. If the lawyers could have their way, they would obliterate all history.

I spent a lot of time messing with Makefiles, as linking & object conversion on old NT is a big deal, and not the kind of thing you want to do more than once. Another big pain is that large files become delete only. I don’t know what the deal with notepad is, but I could remove text, but not change or add. I solved that by wrapping a number of things by including it in another file with some #define work to go around it. Needless to say, that sucked.

One thing that constantly threw issues is that this version of Windows doesn’t handle Unix style signals. I removed all the signal catch/throw stuff, and the binaries ran fine. Why on earth does ‘strip’ need signals is beyond me, but it runs fine without them!

Bringing it together.

From my “Build artifacts from Building Linux 0.11 on Windows NT build 239, December 1991” page, grab the two files, bin.zip & source0.zip.

On Windows I just unzip the bin.zip file and leave source.0.zip intact into a directly say something like temp. Then I can use a cool feature of Qemu where it can mount a directory as a read-only FAT disk. This saves a lot of time!

Running Qemu like this:

qemu.exe -L pc-bios -m 64 -net none -hda nt1991.vmdk -hdb fat:temp -fda boot.vfd

Will drop to the bootloader. Hit enter to login, and you’ll be at the desktop. Hit enter again, and open a command prompt.

By default, the Numlock is messing with the arrow keys (I think it’s mapping to the old 83 key keyboard no matter what?) Hit num-lock and your arrow keys should kind of work. It’s a great time saver.

I copied the binaries & the ygcc.cmd file into the \bin directory, created a \proj directory and get ready to unzip all the source code. For some reason this version of unzip doesn’t understand the zip compression, so it’s just storing instead, much like TAR. It’s not that involved but unzip with the -d flag so it creates directories as needed.

This will let us keep long file names. HPFS is case insensitive, but it also preserves the case, so don’t worry about the names being all weird. It doesn’t matter.

One thing worth mentioning is that even though the C pre-processor does compile it just hangs when trying to run it. I’m not sure what is wrong exactly, but it’s just not worth fighting. Instead, I had the better idea, of using the Microsoft C compiler to pre-process the source. Apparently, this is how they originally built Windows NT, pre-processing on OS/2, then uploading the pre-processed files to a SUN workstation with the i860 compiler and downloading the objects to be converted & linked. Wow that must have been tedious!

I created a CMD file ‘ygcc.cmd’ to run the cl386 pre-processor, call CC1 & GAS and clean up afterwards.

cl386 -nologo /u /EP -I\include -D__GNUC__ -Dunix -Di386 -D__unix__ -D__i386__ -D__OPTIMIZE__ %2 > \tmp\xxx.cpp
\bin\cc1 -version -quiet -O -fstrength-reduce -fomit-frame-pointer -fcombine-regs -o /tmp/xxx.s /tmp/xxx.cpp
\bin\ax386 -v -o %1 /tmp/xxx.s
@del \tmp\xxx.s
@del \tmp\xxx.cpp

It’s not pretty but it works!

Building

Before you can build Linux, you need to create both a \tmp & \temp directory. Also the include files need to be copied to the \include directory to make the pre-processor happier.

I’ve tried to make this as simple as possible there is a ‘blind.cmd’ file which I built that’ll manually compile Linux. There is no error checking.

And saving everyone the excitement here is an animation of the build process

And there we go! All compiled!

From there it’s a matter of copying the Image file out of the VM, I used the boot floppy and 7zip’s ability to extract FAT images, and then boot up Qemu using the Image file as a ‘floppy’ as back in the day we used to rawrite these to floppy disks.

qemu.exe -L pc-bios -m 64 -net none -hda nt1991.vmdk -hdb fat:temp -fda boot\IMAGE -boot a

I don’t have a root filesystem, so the panic is expected, but yes, we just cross compiled Linux from Windows NT, circa 1991!

First off, I got a new VPS to house this on, size wise, I’d just plain outgrown the old one, even with SquashFS. Over on lowend box, I had spotted this one: LuxVPS

It’s not an AD, just thought the pricing seemed pretty good for 5€. One of the nice things about converting so much of my data to SquashFS is that moving single files is WAY easier to deal with!

Mice in my 1970’s teletype text editor?!

But editing text files had me facing off some feature of VIM I’d somehow not dealt with that Debian 11 set by default, and that is mouse integration!

CAN YOU BELIVE IT?

Somewhere out there, is people who use a mouse with a VI clone. 

It bares repeating

SOMEONE THINKS YOU NEED A MOUSE TO USE VI.

So much so, it’s the system default.

Good lord.

The fix is to edit /etc/vim/vimrc:

set mouse=
set ttymouse=

Problem solved. Obviously, I’m not going to remember this, but now I can right click/paste the way G’d intended it!

Stale encryption

The next source of annoyance is the ancient stunnel 4.17 that I use for altavista.superglobalmegacorp.com. I’m kind of trapped with this setup as it needs to be a 32bit ‘workstation’ OS, and I don’t want to run something as heavy as XP or Vista when NT 4.0 is more than enough. Anyways OpenSSL won’t talk to this ancient encryption, throwing this error trying to do a connection with “openssl s_client -connect 192.168.23.6:443”:

error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
Unable to establish SSL connection.

The fix, thanks to dave_thompson_085 is simple enough.

Basically, modify /etc/ssl/openssl.conf and place this at the top:

openssl_conf = default_conf
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

then place this at the bottom:

[ default_conf ]

ssl_conf = ssl_sect

[ssl_sect]

system_default = ssl_default_sect

[ssl_default_sect]
MinProtocol = TLSv1
CipherString = DEFAULT:@SECLEVEL=1

Now when I connect to stunnel, I can verify that I am indeed using ancient crap level security:

New, SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 19D20D30E0026E8417E00402DE939E90770D4658C3A9CFE4DB4E5F2A5454DE9D
    Session-ID-ctx:
    Master-Key: 498C648E77E9B9C944A8B1D16242240A161A05A087881C6AD300718DD9B8C443EA12FB76440B666B7C6634A7E7DBE9D5
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1718352960
    Timeout   : 7200 (sec)
    Verify return code: 10 (certificate has expired)
    Extended master secret: no
---
DONE

I don’t care about the encryption, I could as a matter of fact just run without it, as I only need the reverse proxy aspect of it, to make the AltaVista web server accessible over the LAN/WAN/INTERNET. It’s all fronted with CloudFlare so from the end use POV it’s all encrypted anyways

A rainbow of happiness

Another nice side benefit of this SquashFS setup is that I can forever rebase the disks as the content never changes.

#!/bin/bash
# rebase the disk
rm /usr/local/vm/AltaVista/altavista-c.vmdk
rm /usr/local/vm/AltaVista/altavista-d.vmdk
rm /usr/local/vm/AltaVista/altavista-u.vmdk

qemu-img create -f vmdk -b /usr/local/vmdk/AltaVista_C/altavista-c.vmdk -F vmdk /usr/local/vm/AltaVista/altavista-c.vmdk
qemu-img create -f vmdk -b /usr/local/vmdk/AltaVista_D/altavista-d.vmdk -F vmdk /usr/local/vm/AltaVista/altavista-d.vmdk
qemu-img create -f vmdk -b /usr/local/vmdk/AltaVista_U/altavista-u.vmdk -F vmdk /usr/local/vm/AltaVista/altavista-u.vmdk

qemu-system-i386 -vga std -cpu pentium -m 64 \
        -vnc 192.168.23.1:6 \
        -net none  \
        -hda /usr/local/vm/AltaVista/altavista-c.vmdk \
        -hdb /usr/local/vm/AltaVista/altavista-d.vmdk \
        -hdd /usr/local/vm/AltaVista/altavista-u.vmdk \
        -device pcnet,netdev=alta,mac=5a:00:11:55:22:22  \
        -netdev tap,ifname=tap6,id=alta,script=/usr/local/vm/AltaVista/alta-up,downscript=/usr/local/vm/AltaVista/alta-down

One thing is for sure, it makes hosting AltaVista a bit easier to deal with. And for the sake of archiving, I uploaded a pre-loaded & indexed dataset Altavista Pre-Loaded (squashfs). I found that you can just copy the databases into a new VM, as long as you keep the drive letters the same as your source. So luckily, I had kept the OS on C:, installed AltaVista on D: with all the usenet posts on U:. Even better, for those strapped for space, you don’t technically need the U: drive, if you just want to search. Of course, you probably do want to look at them, but we’ve gone down this road before. And we know where it leads.

Some of you may remember some 9 years ago, I had put together a package to compile Linux 0.10 under Windows.

Time goes on, and things are lost, and it’d come up somewhere about actually building Linux from Windows, so I thought I’d show it off.

The one thing is that modern machines are just so fast, that it’s almost hard to believe that a 386DX 16 with 4MB of ram would struggle for seemingly hours, what an i7 can churn out in mere seconds.

Time sure flies!

It’s my usual ‘DO IT LIVE’ style, I tried to clean up the audio, but I lost the steps… One day I’ll try to script & build a PowerPoint so it’s more cohesive.

But today is not that day.

It’s a problem that we will all face sooner or later in shared environments, running out of disk space. Back in the old days we would just run stacker and be done with it, but what on earth can we do in this modern age?

Well, there is squashfs which is great at creating ultra-compressed read-only filesystems! Well, that is great, but it is READ-ONLY after all, so that is going to suck right? Well thanks to the magic of file system overlays, we can compress our website, and get the much-needed COW (Copy on Write) to another directory giving us the best of both worlds. It’s a common thing in many live CD’s or any seemingly appliance-based OS where you have a hardened read-only OS core that a user cannot delete/infect but gives the appearance of allowing you to update files. Well, that’s all nice but how do you do it manually?

The first thing I did was shut down Apache so I could get a clean compress of my web document root: mksquashfs is pretty easy to use, and in a few minutes of downtime I was able to create a read-only version of my blog’s filesystem. (NOTE that this doesn’t include the database! so anyone wanting to quick & easily archive WordPress, remember there is always more than just the files!).

root@ukweb:/srv/www/blog# mksquashfs . /usr/local/blog.sqshfs
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on /usr/local/blog.sqshfs, block size 131072.
[===================================================================================================-] 67497/67497 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
        compressed data, compressed metadata, compressed fragments,
        compressed xattrs, compressed ids
        duplicates are removed
Filesystem size 4604333.36 Kbytes (4496.42 Mbytes)
        82.78% of uncompressed filesystem size (5562424.58 Kbytes)
Inode table size 480413 bytes (469.15 Kbytes)
        33.86% of uncompressed inode table size (1418977 bytes)
Directory table size 430607 bytes (420.51 Kbytes)
        32.31% of uncompressed directory table size (1332573 bytes)
Number of duplicate files found 519
Number of inodes 38856
Number of files 32640
Number of fragments 7872
Number of symbolic links 0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 6216
Number of ids (unique uids + gids) 2
Number of uids 2
        www-data (33)
        root (0)
Number of gids 2
        www-data (33)
        root (0)

Before compression the blog sat at 5.6GB worth of space. After compressing, it now sits at 4.4GB. Not that awesome, but not that bad either! the blog.sqshfs file can be easily mounted on the command-line like this:

mount -o loop /usr/local/blog.sqshfs /srv/www/blog

And it mounted up just fine, and astonishingly the blog worked. Although it being a read-only filesystem means that I cannot upload new content so all the media would be frozen in time, just as I would no-longer be able to make any updates to the pluggins or the software.

Enter the overlayfs, which lets you specify an ‘upper’ and ‘lower’ level for your filesystem where you can have a read-only lower level, and a read-write upper level. Perfect!

I moved the blog read-only mount to /srv/www/blog-ro created a blog-tmp & blog-rw directories as well and mounted up in overlay mode like this:

mount -t overlay -o lowerdir=/srv/www/blog-ro,upperdir=/srv/www/blog-rw,workdir=/srv/www/blog-tmp overlay /srv/www/blog

You’ll notice that despite all the documentation mentioning overlayfs, along with all the posts, as of Linux 5.15 it’s now called overlay.

root@ukweb:/lib/modules/5.15.0-101-generic/kernel/fs/overlayfs# ls
overlay.ko

At least that was easy enough to find.

But you might say, THATS ALL MANUAL! How on earth are you going to deal with a reboot? rc.local?!

Well, you could but /etc/fstab is much easier!

/usr/local/blog.sqshfs /srv/www/blog-ro squashfs ro,defaults 0 0
overlay /srv/www/blog overlay defaults,lowerdir=/srv/www/blog-ro,upperdir=/srv/www/blog-rw,workdir=/srv/www/blog-tmp 0 2

And just like that, I now have a read-only version of the blog data, in a single easy to backup file, along with writes going to a much more manageable directory for updates.

I guess I should add that for sites that use caching, you’ll want to purge the wp-content/cache directory as it’ll become stale, and there really is no point having a read only version of the chache.

If you can see this, then clearly the site is working!

**UPDATE

So I do have a qemu image piggy-backing on my VPS that runs the Apache on NT 3.1 (superglobalmegacorp.com) site. It’s not very complicated, just NT 3.1 with my terrible apache site. Content doesn’t change, it’s a “just because I can” thing.

So you can happily shut down the VM, and in this case I’m using VMDK’s but it really doesn’t matter, I just like having a more neutral container if I want to move stuff around. Just squash the VMDK by itself into a new squash fs file:

# mksquashfs nt31as.vmdk /usr/local/vmdk/NT31_AdvancedServer.vmdk.squashfs
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on /usr/local/vmdk/NT31_AdvancedServer.vmdk.squashfs, block size 131072.
[=====================================================================================================-] 1390/1390 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
        compressed data, compressed metadata, compressed fragments,
        compressed xattrs, compressed ids
        duplicates are removed
Filesystem size 72383.38 Kbytes (70.69 Mbytes)
        40.68% of uncompressed filesystem size (177925.66 Kbytes)
Inode table size 3918 bytes (3.83 Kbytes)
        69.64% of uncompressed inode table size (5626 bytes)
Directory table size 31 bytes (0.03 Kbytes)
        93.94% of uncompressed directory table size (33 bytes)
Number of duplicate files found 0
Number of inodes 2
Number of files 1
Number of fragments 0
Number of symbolic links 0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 1
Number of ids (unique uids + gids) 1
Number of uids 1
        root (0)
Number of gids 1
        root (0)

The disk image went from 174MB to 71MB. Not bad!

Next, setup a mount point in /etc/fstab

/usr/local/sqshfs/NT31_AdvancedServer.vmdk.squashfs /usr/local/vmdk/NT31_AdvancedServer squashfs ro,defaults 0 0

Now we create the backing file to point to the original VMDK where all write operations will take place. And of course this means that the site can be reverted very quickly if something goes wrong.

qemu-img create -f vmdk -b /usr/local/vmdk/NT31_AdvancedServer/nt31as.vmdk -F vmdk nt31as.vmdk

And just like that, we’ve now up and running!

So after basically facing defeat, I thought I’d give Linux on the PS3 another shot. Last time things just didn’t work for some reason, and although I could boot Linux from the USB, I couldn’t get it to partition the hard drive. And running from USB 2.0 is just insanely slow.. Especially when it’s trying to run X11.

I followed the instructions here: psx-place.com.

Having already installed CFW 4.90 Evilnat Cobra 8.4 [CEX] on my PS3, I downgraded to the suggested REBUG_4.81.2_REX_EMER_INIT_PS3UPDAT.PUP version of the firmware.

Loading is a bit weird requiring you to load, then entering safe mode, re-installing, then recovering again.

One silly thing to note, is that although a USB keyboard got me through the majority of this, you ABSOLUTELY NEED a PS3 controller to his the PS button to continue in safe/recovery mode. I ended up buying a new controller for £12 on eBay. Used ones were selling for the comparable price, so why buy something with ick on it? Sadly, this did double my budget to £24.

But rest assured just keep pushing through.

Although my FLASH was clearly re-partitioned, with it not changing as I had expected the recovery boot didn’t work, so I had to jump the instructions, and install REBUG_TOOLBOX_02.03.02.MULTI_.16.pkg and select boot into safe mode from there, and re-apply the firmware.

over and over….

But eventually success!

Finally on enough reboots, I got to the setup screen for a clean system!

Re-installing the toolboox took me to repartitioning the flash (again), powering off, then loading petitboot for NOR flash (well mine is NOR), powering off, then prepping the USB, and this time booting with the ‘use current’ option.

While I had busybox & running from initrd/USB before so far so good, nothing looks different.

HOWEVER:

This time the create_hdd_region.sh actually did what it should do! Excited I rebooted back to ‘gameos’ and checked the system status

I’m not sure why it kept failing before, but this time it did what it should have done. Obviously, I screwed up something before, and I’m not sure what.

Booting back to the USB drive, Red Ribbon booted up in X11, allowing me to run run the installer.

The volumes by default are fine.

It does give the ability to set locale, region, and machine name. I don’t know why but I tried it twice and it failed every time.

So I just hit defaults, just setting input & language to EN-us for American English in Alaska. I mean why not. I gave up on just fighting and just let it go with defaults.

And with that I had the PS3 up and booting!

Sadly it wasn’t all sunshine and rainbows, I was noticing some important software like m4, unzip, gdb, autoconf/automake/libtool file, htop/ncurses to say a few!

Compiling however lead me to kernel crashes & panics.

Eventually it’ll hard lock.

I speculate its probably my PS3. The optical drive doesn’t work so I’ve never played a game on it, or done anything intensive until compiling software. I did find that disabling the swap space to video ram stopped it from crashing. As a matter of fact I disabled a bunch of things to get back some performance.

In the /etc/rc2.d just rename the S*** to K*** for the following to disable all of this stuff..

K01nmbd K01ps3-eyetoy K01ps3-rsx-swapon K01samba-ad-dc K01xrdp K02smbd K03bluetooth

The other thing was to just plain disable X11. I’m going to ssh across the network, so I don’t need the PS3 hogging my TV:

(live)neozeed@redribbon:~$ cat /etc/X11/default-display-manager
none
(live)neozeed@redribbon:~$

So yeah, not sure why I had goofed this up so bad, but in the end I got what I wanted, a big endian machine on a budget. What is interesting about this Red Ribbon thing, is that the kernel looks 64bit, but it’s all a 32bit userland. I don’t know if it matters so much. The place to get deb’s is long gone, so I guess Id have to find something with source this was based off of to build the missing stuff, or just keep going on, and building from source. I’m find with either, but I don’t need it as a desktop so my motivation is already waning. I can’t imagine even trying to use a 256MB PS3 as a desktop. It’s just pain.

Again I’m not sure why the swap to video ram thing kills the PS3, but I can live with avoiding it.

Thanks to dazzaXx, for the instructions.

There is a LOT of warnings about breaking your system, bricking things, so of course I’m not going to buy something nice, and I found this beauty on eBay

What a beauty! Only £23 with shipping! The way inflation is going its like McDonalds money.

Anyways a mere 3 days later, and it showed up!

The cover promptly fell off, and I was a bit worried. I hooked up the power, and the red light came but but it didn’t turn on. The power switches are these weird sensors, and it looked like the power one was pushed in. I guess its more of an antenna rather than closing a circuit, so I genitally bent it apart, and it sprang to life. There was no video, but it did chirp pretty loudly so I assumed it was working. I figured there was no disk, so I found the process to reset the video (turn on, holding power and it’ll power off. Power on again, and wait for it to do 2 chirps while holding power down, then let go, and it’ll hopefully lower all video to minimal levels on both composite and HDMI. And yeah, it sprang to life!

The PS3 had version 4.50 loaded, and the first step to bringing back otheros was to update to 4.90. The last version that had otheros was 3.16, so sadly it’s long gone.

Updating was pretty uneventval.

But now starts the real fun.

It’s scratched pretty bad, but you can make out it’s a CECHK03.

, meaning it’s NOR type flash. This matters as the launch devices used NAND, and a heck of a lot more too! And of course totally incompatible. So yeah be careful!

So the first thing to do is to patch the flash. And shockingly this is VERY very easy… It’s so scary it’s easy! Just open the browser after you’ve flashed to 4.90 and go to

https://www.ps3toolset.com/bgtoolset/

Yep it’s a web browser exploit that should terrify you.

Using FLASH buffer overflows we’re going to reprogram the FLASH. WOW could you imagine a world where iPhones ran Adobe Flash?

From the web page, it’s a snap to backup the flash to USB, and then you can download and merge the flash patch right from the UI

With the image loaded and merged, we can now re-flash the PS3.

It’s really this easy.

wow.

Now you need to power it off.

Next up is to install the Evilnat CEX 4.90 hacked firmware. It’s pretty simple, much like the production image, it installs from the XMB after copying the file to USB in the appropriate directories. I downloaded “CFW 4.90 Evilnat Cobra 8.4 [CEX].rar“.

And now you are a reboot away into modified OS

There was a bunch of users, and installed games, I removed the users, deleted the games, and formatted the disk. I’m not going to be playing games anyways.

Now it was a bit more things to do.

Partition the flash, and re-program it again with the otheros support. And then now finally you can boot to the BusyBox ramdisk.

I’ll have to touch on this part a bit more, it’s involved, and again you can brick your PS3. If you worry about it, now is the time to do it, as many are being sold effectively as garbage.

For the heck of it, I exploded out an old Red Ribbon ISO, and was able to ‘live image’ boot it from USB.

So this gets me part of the way here.

The next thing to figure out is if I can downgrade the OS to something where I can partition part of the hard drive for Linux. And how to get that installed.

So I’m going to have to leave it here, at least for my usage case I may have to just be happy using the slow USB for the root filesystem. I’m pretty sure when it comes to partitioning the disk you need the lower OS version to do so. Obviously for me I can leave it there if it runs, as I don’t care about playing games on this one anyways.

Which I’m sure won’t be as bad once I turn off X11 and everything ‘nice’ for a user.

Also you probably want to get a PS3 controller, as at any point you need to do a recovery you need to be able to hit the ps3 button. And that’s where I am currently stuck, but not bricked.

Just a quick thing I saw before going to sleep, 68katy-musashi! It’s a very simple 68000 machine, based on the big mess o\ wires 68-katy!

I had issues with 64bit, but I jumped over to Windows, stripped out the termios and had something running in seconds!

Another note is that I had to manually enable -O2 flags, which made a tremendous difference!

the debs are kpe tin /var/cache/apt/archives

So a simple script like this:

ls -l *.deb | awk '{print $9}' | sed -e 's/_/\ /g' | awk '{print "apt-get install "$1}' > /tmp/missing

Will go ahead and prep a simple script to re-add everything. Obviously I don’t pass it into a sudo’d bash, but heh it works.

Probably one of my quicker recoveries, since I had all the data & config’s just lost the OS.

Nov 17 12:04:25 ukweb pppd[4943]: Using interface ppp0
Nov 17 12:04:25 ukweb pppd[4943]: Connect: ppp0 <--> /dev/pts/0
Nov 17 12:04:25 ukweb pptpd[4942]: GRE: Bad checksum from pppd.
Nov 17 12:04:25 ukweb systemd-udevd[4944]: Using default interface naming scheme 'v249'.
Nov 17 12:04:25 ukweb pppd[4943]: peer from calling number 1.1.1.1.1 authorized
Nov 17 12:04:25 ukweb pppd[4943]: MPPE 128-bit stateless compression enabled
Nov 17 12:04:27 ukweb systemd-networkd[592]: ppp0: Link UP
Nov 17 12:04:27 ukweb systemd-networkd[592]: ppp0: Gained carrier
Nov 17 12:04:27 ukweb pppd[4943]: found interface br0 for proxy arp
Nov 17 12:04:27 ukweb pppd[4943]: local  IP address 192.168.0.1
Nov 17 12:04:27 ukweb pppd[4943]: remote IP address 192.168.23.10
Nov 17 12:05:28 ukweb systemd[1]: Stopping PoPToP Point to Point Tunneling Server...
Nov 17 12:05:28 ukweb pppd[4943]: Terminating on signal 15
Nov 17 12:05:28 ukweb pppd[4943]: Connect time 1.1 minutes.
Nov 17 12:05:28 ukweb pppd[4943]: Sent 0 bytes, received 6937 bytes.
Nov 17 12:05:28 ukweb systemd-networkd[592]: ppp0: Link DOWN
Nov 17 12:05:28 ukweb systemd-networkd[592]: ppp0: Lost carrier

With the emphasis on “local IP address 192.168.0.1”. Which is *NOT* in my config. I went as far as adding a bridge to satisfy the proxy arp! Netplan is some yaml thing and yeah not a big fan.

    ethernets:
        eth0:
            addresses:
            - PUBLICIP/24
            gateway4: GATEWAY
            match:
                macaddress: AA:BB:CC:00:00:01
            nameservers:
                addresses:
                - 1.1.1.1
                - 8.8.8.8
    bridges:
      br0:
        dhcp4: no
        addresses: [192.168.23.1/24]
    version: 2

my /etc/ppp/pptpd.conf had the options set, but no matter what it *ALWAYS* went to 192.168.0.1

option /etc/ppp/pptpd-options
logwtmp
localip 192.168.24.1
remoteip 192.168.23.30-250

And then I found it after doing what i should have done, and grep around to find out that pptpd.conf should actually live in /etc

Yeah that’s right, there is 2 of them although they should be the same. A symlink and a restart later, and now I get this:

Nov 17 12:19:56 ukweb kernel: [  112.718861] PPP MPPE Compression module registered
Nov 17 12:19:56 ukweb pppd[1002]: MPPE 128-bit stateless compression enabled
Nov 17 12:19:58 ukweb systemd-networkd[599]: ppp0: Link UP
Nov 17 12:19:58 ukweb systemd-networkd[599]: ppp0: Gained carrier
Nov 17 12:19:58 ukweb pppd[1002]: found interface br0 for proxy arp
Nov 17 12:19:58 ukweb pppd[1002]: local  IP address 192.168.23.1
Nov 17 12:19:58 ukweb pppd[1002]: remote IP address 192.168.23.10

MUCH much better. I don’t know if this is anything worth wriging about, but if I can save someone else an hour of wondering why the config isn’t working and why their pptp is always defaulting to 192.168.0.1 and why it’s wreaking havoc with any default home router, where here it is.

jsteve@piorun:~/atar-boot/qemu/ppc-softmmu$ objdump -p qemu-system-ppc | grep NEEDED
NEEDED libvdeplug.so.2
NEEDED libncursesw.so.6
NEEDED libtinfo.so.6
NEEDED libz.so.1
NEEDED libxml2.so.2
NEEDED libpixman-1.so.0
NEEDED libutil.so.1
NEEDED libnuma.so.1
NEEDED libnettle.so.6
NEEDED libgnutls.so.30
NEEDED libfdt.so.1
NEEDED libgthread-2.0.so.0
NEEDED libglib-2.0.so.0
NEEDED librt.so.1
NEEDED libstdc++.so.6
NEEDED libm.so.6
NEEDED libgcc_s.so.1
NEEDED libpthread.so.0
NEEDED libc.so.6

So using the same atar qemu git dump, I found the newer config string a bit more refined:

./configure --target-list=ppc-softmmu --disable-sdl --disable-vnc --disable-gtk --disable-gnutls --disable-nettle --disable-gcrypt --disable-spice --disable-numa --disable-libxml2 --disable-vde --disable-werror --disable-seccomp --disable-capstone --disable-vhost-net --disable-vhost-crypto --disable-vhost-scsi --disable-vhost-vsock --disable-vhost-user --disable-tpm --disable-live-block-migration

Another fun think is that there is submodules from other servers, and it seems their certs have expired.. Which also means it’s inevitable at some point this will become impossible to build. Be sure to set this environment variable in order to build:

export GIT_SSL_NO_VERIFY=true

As always Qemu will try to sneak a few things in there that we don’t need like audio support. As an example here is what I trimmed from config-host.mak:

$ diff -ruN config-host.mak config-host.mak-cutdown
--- config-host.mak 2022-11-08 09:37:41.104441392 +0000
+++ config-host.mak-cutdown 2022-11-08 09:37:25.084441253 +0000
@@ -27,8 +27,8 @@
CONFIG_SLIRP=y
CONFIG_SMBD_COMMAND="/usr/sbin/smbd"
CONFIG_L2TPV3=y
-CONFIG_AUDIO_DRIVERS=oss
-CONFIG_AUDIO_OSS=m
+CONFIG_AUDIO_DRIVERS=
+CONFIG_AUDIO_OSS=n
ALSA_LIBS=
PULSE_LIBS=
COREAUDIO_LIBS=
@@ -72,7 +72,6 @@
HAVE_STRCHRNUL=y
CONFIG_BYTESWAP_H=y
CONFIG_TLS_PRIORITY="NORMAL"
-CONFIG_TASN1=y
HAVE_IFADDRS_H=y
HAVE_FSXATTR=y
HAVE_COPY_FILE_RANGE=y
@@ -164,7 +163,7 @@
DSOSUF=.so
LDFLAGS_SHARED=-shared
LIBS_QGA+=-lm -lgthread-2.0 -pthread -lglib-2.0
-TASN1_LIBS=-ltasn1
+TASN1_LIBS=
TASN1_CFLAGS=
POD2MAN=pod2man --utf8
TRANSLATE_OPT_CFLAGS=

And this cuts down the needed dll’s to:

jsteve@piorun:~/atar-boot/qemu/ppc-softmmu$ objdump -p qemu-system-ppc | grep NEED
NEEDED libncursesw.so.6
NEEDED libtinfo.so.6
NEEDED libz.so.1
NEEDED libpixman-1.so.0
NEEDED libfdt.so.1
NEEDED libglib-2.0.so.0
NEEDED libm.so.6
NEEDED libgcc_s.so.1
NEEDED libc.so.6

which is a bit better. I’m still annoyed at it’s reliance on pixman despite not having any framebuffer support, I’m guessing I could amputate it if I looked further.

Since nothing has fundamentally changed, I can still use my original bootflags:

./qemu-system-ppc -M 40p -bios q40pofw-serial.rom -serial telnet::4441,server -hda disk0.vmdk-post-install -vga none -nographic -net none -cdrom /mnt/c/temp/xlc13-gzip.iso

And for the heck of it, this is the steps I used to get xlC 1.3 up and running:

restore -f /tmp/xlc/xlccmp2
restore -f /tmp/xlc/xlccmpmE2
chmod +x /usr/bin/xlc
chmod +x /usr/lpp/xlc/bin/xlcentry
chmod +x /usr/lpp/xlc/bin/dis
cp /usr/lpp/xlccmp/inst_root/etc/xlc.cfg /etc
cp /tmp/xlc/cpp /usr/lib/cpp
chmod +x /usr/lib/cpp

and with that all in place we can compile a simple hello world!

# cat mt.c
#include <stdio.h>
void main(){
printf("hi from C\n");
}
# xlc -v mt.c -o mt
exec: /usr/lpp/xlc/bin/xlcentry(xlcentry,mt.c,mt.o,mt.lst,-D_ANSI_C_SOURCE,-D_IBMR2,-D_AIX,-D_AIX32,-qansialias,NULL)
exec: /bin/ld(ld,-H512,-T512,-bhalt:4,-o,mt,/lib/crt0.o,mt.o,-lc,NULL)
unlink: mt.o
# ./mt
hi from C
#

xlC is also capable of building a running GNU Chess. And I updated the git so that book building works. Not that I expect anyone to care.

Chess
book
Compiling book, please wait…
186 games added, 3384 positions added, 3383 total positions in book

It has the same desire to move pieces back and forth for thousands of moves, but it’s doing a heck of a lot more than any modern C compiler.

Since we don’t have any networking, Everything is on the console. I’ve found making CD-ROM images being a much easier way to get data in, and I’m still using uuencode to get data out from the console. I guess I should setup Z-modem at some point but that’s very futuristic. Or just break down and learn how to use C-kermit.

My go to quality of life startup is:

export TERM=vt100
stty erase ^?
export LIBPATH=$LIBPATH:/usr/lib
export PATH=/usr/local/bin:$PATH

Sure not perfect but it makes it slightly more usable. As a follow on, I got networking working here: Networking on AIXI 4.3