Networking on AIX 4.3

Well oslevel says, but you get the idea.

You’ll need to have the ethernet driver handy, or better loaded. Since I had disabled the NIC on install it’s not loaded. And since I’m still using a cellphone for internet I extracted the file somewhere else and copied in some patches. I’ve managed to reproduce this twice now, so I guess it’s good to go. Apparently, this just works in later versions, but this is very touchy.

To start how I’m running qemu:

./qemu-build/ppc-softmmu/qemu-system-ppc -M 40p -bios q40pofw-serial.rom -serial telnet::4441,server -hda disk0.vmdk-post-install -vga none -nographic -net none -device pcnet,netdev=ne -netdev user,id=ne,hostfwd=tcp::42323-:23 -cdrom /mnt/c/temp/pcnet-aix.iso

With aix booted, extract the tar file from the cdrom:

mount /cdrom
mkdir /pcnet
cd pcnet
tar -xvf /cdrom/pci.tar

Fix your terminal up… if needed (it probably is)

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

Now run smitty -> devices -> after ipl

Change the directory to /pcnet , and let it run It will give errors but thats okay. All being well it won’t crash AIX, otherwise you’ll want to restore your hardisk. You did make a backup beforehand right?!

I don’t think it matters but I run this afterwards:

odmchange -o CuAt -q "name=ent0 and attribute=busio" /cdrom/lance_ch.asc
odmget -q "name=ent0 and attribute=busio" CuAt
shutdown -h now
halting does take forever

As tempting as it is to kill the emulator, wait for it to complete. Otherwise you may have to do the whole thing agian.

For me the value attribute was never preserved, so we get to do it again on reboot/restart:

odmget -q "name=ent0 and attribute=busio" CuAt
mount /cdrom
odmchange -o CuAt -q "name=ent0 and attribute=busio" /cdrom/lance_ch.asc
rmdev -l ent0
mkdev -l ent0
ifconfig en0
ping -c 1

If everything went well this time you should get a ping reply! Great! Now to configure the system for real.

smitty -> communication -> tcpip -> minimum -> en0

simple slirp

As always I configure my system for slirp. We’re almost there! Now to pad the DNS records for slirp:

cat >> /etc/hosts slirp slirpdns

And now you can reboot!

If everything goes well, you will have a patched up pcnet driver that works (well mine does)

It works!

The big test is to of course reboot. Then you’ll know for sure.

I have tried this a few times, and yeah it can crash when adding the drivers, so I had to restore a few times. I would say 1/3 times worked flawlessly. So be patient. And backup!

Revisiting AIX 4.3 on Qemu

I had gone over the install a while ago, but I wanted to re-install on a newer machine. And going from GCC 7 to 11, well a number of things changed. And I found with experience that letting Qemu select as much as it wants leads to numerous dependencies that end up being problematic.

[email protected]:~/atar-boot/qemu/ppc-softmmu$ objdump -p qemu-system-ppc | grep NEEDED

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 @@
@@ -72,7 +72,6 @@
@@ -164,7 +163,7 @@
LIBS_QGA+=-lm -lgthread-2.0 -pthread -lglib-2.0
POD2MAN=pod2man --utf8

And this cuts down the needed dll’s to:

[email protected]:~/atar-boot/qemu/ppc-softmmu$ objdump -p qemu-system-ppc | grep NEED

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.

AIX 4.3 booted!

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.

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

Re-visiting an install of 386BSD 0.0

    I shall be telling this with a sigh
    Somewhere ages and ages hence:
    Two roads diverged in a wood,
            and I ---
    I took the one less traveled by,
    And that has made all the difference.
       "The Road Not Taken" [1916] -- Robert Frost

I didn’t want to make my last post exclusively focusing on 386BSD 0.0, but I thought the least I could do to honor Bill’s passing was to re-install 0.0 in 2022. As I mentioned his liberating Net/2 and giving it away for free for lowly 386/486 based users ushered in a massive shift in computer software where so called minicomputer software was now available for micro computer users. Granted 32bit micro computers, even in 1992 were very expensive, but they were not out of the reach of mere mortals. No longer did you have to share a VAX, you could run Emacs all by yourself! As with every great leap, the 0.0 is a bit rough around the edges, but with a bit of work it can be brought up to a running state, even in 2022.

But talking with my muse about legacies, and the impact of this release I thought I should at least go thru the motions, and re-do an installation, a documented one at that!

Stealing fire from the gods:

Although I had done this years ago, I was insanely light on details. From what I remember I did this on VMware, and I think it was fusion on OS X, then switching over to Bochs. To be fair it was over 11 years ago.

Anyways I’m going to use the VMware player (because I’m cheap), and just create a simple VM for MS-DOS that has 16MB of RAM, and a 100MB disk. Also because of weird issues I added 2 floppy drives, and a serial & parallel port opened up to named pipe servers so I can move data in & out during the install. This was really needed as the installation guide is ON the floppy, and not provided externally.

VMware disk geometry

One of the things about 386BSD 0.0 is that it’s more VAX than PC OS, so it doesn’t use partition tables. This also means geometry matters. So hitting F2 when the VM tries to boot, I found that VMware has given me the interesting geometry of 207 cylinders, 16 heads, and a density of 63 sectors/track. If you multiply 207*16*63 you get 208656 usable sectors, which will be important. Multiply that by 512 for bytes per sector you get a capacity of 106,831,872. Isn’t formatting disks like it’s the 1970s fun? Obviously if you attempt to follow along, obviously yours could be different.

Booting off install diskette

Throwing the install disk in the VM will boot it up to the prompt very quickly. So that’s nice. The bootloader is either not interactive at all, or modern machines are so fast, any timeout mechanism just doesn’t work.

As we are unceremonially dumped to a root prompt, it’s time to start the install! From the guide we first remount the floppy drive as read-write with the following:

mount -u /dev/fd0a /

Now for the fun part, we need to create an entry in the /etc/disktab to describe our disk, so we can label it. You can either type all this in, use the serial port, or just edit the Conner 3100 disk and turn it into this:

vmware100|VMWare Virtual 100MB IDE:\
:dt=ST506:ty=winchester:se#512:nt#16:ns#63:nc#207:sf: \
:pa#12144:oa#0:ta=4.2BSD:ba#4096:fa#512: \
:pb#12144:ob#12144:tb=swap: \
:pc#208656:oc#0: \

As you can see the big changes are the ‘dt’ or disk type line nt,ns and nc, which describe heads, density and cylinders. And how 16,63,207 came from the disk geometry from above. The ‘pa’,’pb’… entries describe partitions, and since they are at the start of the disk, nothing changes there since partitions are described in sectors. Partition C refrences the entire disk, so it’s set to the calculated 208656 sectors. Partition A+B is 24288, so 208,656-24,288 is 184,368 which then gives us the size of partition H. I can’t imagine what a stumbling block this would have been in 1992, as you really have to know your disks geometry. And of course you cannot share your disk with anything else, just like the VAX BSD installs.

With the disklabel defined, it’s now time to write it to the disk:

disklabel -r -w wd0 vmware100

And as suggested you should read it back to make sure it’s correct:

disklabel -r wd0
wd0 labeled as a custom VMware 100

Now we can format the partitions, and get ready to transfer the floppy disk to the hard disk. Basically it boils down to this:

newfs wd0a
newfs wd0h
bad144 wd0 -f
mount /dev/wd0a /mnt
mkdir /mnt/usr
mount /dev/wd0h /mnt/usr
(cd /;tar -cf - .)|(cd /mnt;tar -xvf -)
umount /mnt/usr
umount /mnt
fsck -y /dev/rwd0a
fsck -y /dev/rwd0h

Oddly enough the restore set also has files for the root, *however* it’s not complete, so you need to make sure to get files from the floppy, and again from the restore set.

One of the annoying things about this install is that VMware crashes trying to boot from the hard disk, so this is why we added 2 floppy drives to the install so we can transfer the install to the disk. Also it appears that there is some bug, or some other weird thing as the restore program wants to put everything into the ‘bin’ directory just adding all kinds of confusion, along with it not picking up end of volume correctly. So we have to do some creative work arounds.

So we mount the ‘h’ partition next as it’s the largest one and will have enough scratch space for our use:

mkdir /mnt/bin
mount /dev/wd0a /mnt/bin
mount /dev/wd0h /mnt/bin/usr
cd /mnt/bin/usr

Now is when we insert the 1st binary disk into the second floppy drive, and we are going to dump into a file called binset:

cat /dev/fd1 > binset

Once it’s done, you can insert the second disk, and now we are going to append the second disk to binset:

cat /dev/fd1 >> binset

You need to do this with disks 2-6.

I ran the ‘sync’ command a few times to make sure that binset is fully written out to the hard disk. Now we are going to use the temperamental ‘mr’ program to extract the binary install:

cd /mnt
mr 1440 /mnt/bin/usr/binset | tar -zxvf -

This will only take a few seconds, but I’d imagine even on a 486 with an IDE disk back then, this would take forever.

The system is now extracted! I just ran the following ‘house cleaning’ to make sure everything is fine:

cd /
umount /mnt/bin/usr
umount /mnt/bin
fsck -y /dev/rwd0a
fsck -y /dev/rwd0h

And there we go!

Now for actually booting up and using this, as I mentioned above, VMware will crash attempting to boot 386BSD. Maybe it’s the bootloader? Maybe it’s BIOS? I don’t know. However old versions of Qemu (I tested 0.9 & 0.10.5) will work.

With the system booted you should run the following to mount up all the disks:

fsck -p
mount -a

I just put this in a file called /start so I don’t have to type all that much over and over and over:

Booting from Hard Disk, under Qemu

On first boot there seems to be a lot of missing and broken stuff. The ‘which’ command doesn’t work, and I noticed all the accounting stuff is missing as well:

mkdir /var/run
mkdir /var/log
touch /var/run/utmp
touch /var/log/wtmp

Will at least get that back in action.

The source code is extracted in a similar fashion, it expects everything to be under a ‘src’ directory, so pretty much the same thing as the binary extract, just change ‘bin’ to ‘src’, and it’s pretty much done.

End thoughts

I think this wraps up the goal of getting this installed and booting. I didn’t want to update or change as little as possible to have that authentic 1992 experience, limitations and all. It’s not a perfect BSD distribution, but this had the impact of being not only free, but being available to the common person, no SPARC/MIPS workstations, or other obscure or specialized 68000 based machine, just the massively copied and commodity AT386. For a while when Linux was considered immature, BSD’s led the networking charge, and I don’t doubt that many got to that position because of that initial push made by Bill & Lynne with 386BSD.

Compressed with 7zip, along with my altered boot floppy with my VMware disk entry it’s 8.5MB compressed. Talk about tiny! For anyone interested here is my boot floppy and vmdk, which I run on early Qemu.

And there we go!

Revisiting Windows NT 4.0 MIPS on QEMU

(This is a guest post by Antoni Sawicki aka Tenox)

This was previously well covered by Gunkies and Neozeed, however as almost a decade passed, some improvements could be made and annoyances fixed.

Firstly NT MIPS now works in 1280×1024 resolution under QEMU. It previously had issues with mouse tracking, but this is now fixed. So the new image has a higher resolution.

Secondly the old images were made with FAT filesystem which I didn’t like too much. The reason for that is the infamous RISC NT osloader needs to be placed on a FAT partition. Then, if NT is installed on a second NTFS partition the default drive will be D:\, C:\ being the just the osloader drive. This was super annoying in practice. So a common procedure was to just have one FAT partition for both osloader and winnt. I have fixed it by supplying a pre-partitioned disk and specified the second partition for osloader and the first for NT.

Also I only had just a bare/vanilla image with no additional software installed. The new image includes most of the available apps, including IE3, some editors, Reskit and Visual Studio.

Lastly I wanted to figure out all the right settings and flags for qemu as they were discrepancies between different sources and nothing seem to work smoothly. The correct flags seem to be:

qemu-system-mips64el -hda nt4.qcow2 -M magnum -global ds1225y.filename=nvram -L . -rtc "base=1995-07-08T11:12:13,clock=vm" -nic user,model=dp83932

The -rtc flag is not really needed if you are ok with having the current date in the guest.

Thanks to Neozeed for figuring out the network settings! Unfortunately the old/legacy -net nic -net user is no longer working while the new -device doesn’t like dp83932. The documentation was quite helpful.

Thanks to reader Mark for pointing out the correct NVRAM settings! See comments below.

The new image with all the apps preinstalled is here and a plain “vanilla” here.

Curiously this now works right out of the box on QEMU 6.1 and is pretty smooth and stable compared to what it was before. Good job QEMU team and thank you! Just in case I still keep the old binaries for Windows made by Neozeed here.

Update: I built Yori for NT MIPS! You can download here!

Re-visiting Gopher on A/UX

Rather unintentionally some 7 years ago (to the day!) I was playing with an early gopher server on Linux, musing that one day it’d be cool to run it fully on A/UX (what is it anyways?!). And thanks to Qemu’s 68040 support the time is at hand.

First off I need to run this on Linux so I’ll need to build the appropriate branch myself. Thankfully Cat_7 has boiled it down to a really simple formula:

git clone -b q800.upstream q800-upstream
cd q800-upstream
./configure --target-list=m68k-softmmu --enable-gtk --enable-sdl

In my case I remove the gtk and sdl as I’m running this headless.

Now onto the OS itself. While I had numerous images built over the years for Shoebill there was one major issue when compared to Qemu, and that is Shoebill loads the kernel directly while Qemu emulates the hardware so it will boot MacOS 7 directly. While on the surface this is mundane that does mean however that none of my images will actually work on Qemu as they don’t include a blessed copy of System 7. Not that I care that much I could always do a simple dump/restore [ dump.bsd 0f – /dev/rdsk/c0d0s0 | (cd /mnt; restore xf -) ] of my A/UX stuff that I care about anyways. Luckily since I had added that SCSI file support to Cockatrice I could still partition out some disks and install from there.

Now for the further bit of bad news for me is that I found that the 68020 based Shoebill ran 3.0.0 far more stable than 3.0.1 or 3.1. So I’d built everything around 3.0.0. And of course trying to boot 3.0.0 on a Quadra 800 just gives you a hard lock up. I don’t have the setup disk for 3.0.0 but mounting the CD-ROM gives you access to the disk tool (the 3.0.0 version doesn’t check for the Apple string on SCSI ROMS so you can partition with that as well). Anyways too much time thinking I’d done something wrong until this had to be pointed out to me:

Compatibility matrix from penelope

That’s right, 3.0.0 doesn’t run on the Quadra 800. Much longer ago I had a Quadra 950, fantastic beast of a machine, and yes it ran 3.0.0 just great. So shockingly running the right versions got me up to a working system just fine.

Now of course back in the Shoebill days I got ‘3.0.1’ kind of working by cheating. The /mac programs didn’t work on Shoebill however I could copy them over from 3.0.0 to get a working system. Could I substitute a 3.0.1 kernel & /mac directory onto a 3.0.0 system?

So first up the System 7 install from A/UX 3.0.0 is too old for a Quadra 800. Obviously just use the one from 3.0.1. Great.

This lead to a problem where the root filesystem always needs to be checked in single user mode. Something that is shockingly hard to do when your Quadra runs so fast as you have less than a second to hit the ‘top’ button to halt the autoload.

Naturally the standalone runs fine, with no errors.

Thinking that it’s the start-up scripts I remove all the fsck’s and then get this message:

Great a kernel panic. ialloc: dup alloc. Thinking that maybe it’s confusing the UFS, I go ahead and format the disk in SYSV and restore the image onto that.

This gets me another kernel panic, this time no root filesystem. Surprise the SYSV filesystem was made optional in a default install. I run ‘newconfig sysv’ from 3.0.1 and copy that kernel back, and for good measure the shared libraries from 3.0.1. Now I get a different error:

Interesting, I try to hit restart, and instead I get dumped into text mode!


So here we are a 3.0.1 kernel with a 3.0.0 userland! I’m going to use this as a server anyways so I don’t really care about the Mac UI. Naturally so many twists and turns I’ll just skip to the end. Networking didn’t work correctly. Maybe I should have copied all the network stuff from 3.0.1 over but at this point it’s basically a 3.0.1 system so why even bother?

So the next thing of course is just to setup Qemu to listen on a loopback and add some disks. A lot of disks.

./qemu-system-m68k \
-L pc-bios \
-m 256 \
-M q800 \
-vnc \
-serial stdio \
-bios Quadra800.rom \
-net nic,model=dp83932,netdev=ne -netdev user,id=ne,hostfwd=tcp:,hostfwd=tcp:,hostfwd=tcp: \
-drive file=pram-aux.img,format=raw,if=mtd \
-device scsi-hd,scsi-id=0,drive=hd0,vendor="SEAGATE",product="ST225N",ver="1.0" \
-drive file=scsi0.vmdk,media=disk,format=vmdk,if=none,id=hd0 \
-device scsi-hd,scsi-id=1,drive=hd1,vendor="SEAGATE",product="ST225N",ver="1.1" \
-drive file=scsi1.vmdk,media=disk,format=vmdk,if=none,id=hd1 \
-device scsi-hd,scsi-id=2,drive=hd2,vendor="SEAGATE",product="ST225N",ver="1.2" \
-drive file=scsi2.vmdk,media=disk,format=vmdk,if=none,id=hd2 \
-device scsi-hd,scsi-id=3,drive=hd3,vendor="SEAGATE",product="ST225N",ver="1.3" \
-drive file=scsi3.vmdk,media=disk,format=vmdk,if=none,id=hd3 \
-device scsi-hd,scsi-id=4,drive=hd4,vendor="SEAGATE",product="ST225N",ver="1.4" \
-drive file=scsi4.vmdk,media=disk,format=vmdk,if=none,id=hd4 \
-device scsi-hd,scsi-id=5,drive=hd5,vendor="SEAGATE",product="ST225N",ver="1.5" \
-drive file=scsi5.vmdk,media=disk,format=vmdk,if=none,id=hd5 \
-device scsi-hd,scsi-id=6,drive=hd6,vendor="SEAGATE",product="ST225N",ver="1.6" \
-drive file=scsi6.vmdk,media=disk,format=vmdk,if=none,id=hd6
Yeah well… great!?

One nice thing is that since we are on Qemu I don’t have to use raw disk images, I can zero stuff out and use VMDK’s. Nice. I guess I could bridge the VM later, but for now NAT is fine enough as all I need is telnet & gopher. So I grab gopher2_3.1.tar.gz, rebuild and move over my gopher site from Linux into A/UX and I’m up and running in no time. It was shockingly easy. I update a few things to reflect it running on A/UX now.

Currently 2 days of uptime!

And just like that I took my semi popular gopher site, and moved it to A/UX seven years after thinking that this would be a ‘good idea(tm)’. I’m sure it won’t backfire spectacularly.

I don’t know if any of this is useful or interesting but it was to me. It’s been nice that Qemu has been able to keep uptime in several days, I had 3 days of uptime before I took it down to max out the storage so I could possibly do more with it.

Naturally it’s still available as gopher://

Qemu’s Macintosh Quadra in alpha usability! (runs A/UX!)

I’m being a bit unfair as far as Alpha’s go it’s rough to get going but wow it’s GREAT! For starters it’s a Quadra 800 so System 7.1 through 8.1 will work. Also this has full 68040 capabilities so yes that means MMU and YES A/UX (and NetBSD!) will run

As always you can find more on emaculation, the best source for news and info on emulating the Mac.

Additionally you can find the setup guide here.

Many of my Shoebill/Cockatrice III images didn’t work at all. Some at least were picked up as blank disks. I had less luck with freshly created raw/vmdk or qcow2 disks. Not sure at all. My minimal 7 2gb disk worked fine as a donor, and even converting to a vmdk was fine. Sooo YMMV. But hey it’s an Alpha and YES IT CAN WORK.

Another plus is that the idle loop works fine so it won’t burn 100% of your CPU. This could possibly be a great gopher server!? Time will tell.

Installing Debian Linux 5.0 on the Qemu Dec Alpha

Years ago I’d written this terribly vague, and generic quickie post that Debian 5 will in fact boot inside of Qemu. I didn’t really want to get into it as it’s a little complicated and a lot painful. People have cried out over the years, but I figured I’d help people.

Linux for the Dec Alpha

For operating system tourists, I’ll save you the story, just go here, and download qemu-2.2.50-DecAlphaDebian.7z. You’ll quickly find out it’s borderline useless, and go onto your next thing. You’re welcome.

First thing this was running in 2014, and newer Qemu’s seem to behave… strange. So I stuck with a late 2014 build of Qemu. If you deviate from here , you are on your own. I did dig up quite a few other Dec Alpha AXP emulators and put them on -But that’s totally up to you, again I’m sticking with 2014’s Qemu.

The BIOS/Pal on Qemu’s Alpha is far from complete and cannot read disks, so no boot sectors, boot loaders, no on disk kernels. All is not lost, you can inject a kernel and initrd, however this is where the fun is. Obviously to install you need to extract both from the ISO file. Also make sure the kernel is decompressed, add a .gz extension and de-compress it, as it should be around 6MB.

qemu-system-alpha.exe -net nic -net user -drive file=alpha.vmdk,if=ide,media=disk -drive file=debian-5010-alpha-netinst.iso,if=ide,media=cdrom -initrd initrd.gz -kernel vmlinux

This is vaguely how to boot up the installer. Partition, make sure hda1 hda2 hda3 etc are created and all is fine.

Now the next amount of fun is that you need to extract the created initrd as the installer initrd always launches the installer. The busybox cannot create tar files, there is no ftp or scp, also I couldn’t get it to even try to mount NFS images.

However on Windows 10 with WSLv2 or a Linux machine you can mount the disk image (keep it raw? or convert it?)

losetup /dev/loop0 myimage.disk 
partprobe /dev/loop0
mount /dev/loop0p1 /mnt/myimage

These three steps will let you mount the disk in this case /dev/loop0p2 which is the root filesystem. Debian didn’t have partprobe installed so I had to apt-get install parted

Now that you can mount it, you can copy the boot/initrd.img-2.6.26-2-alpha-generic file.

We do need to tell Linux where the root filesystem is so to finally run Qemu it’s like this:

qemu-system-alpha.exe -net nic -net user -drive file=alpha.vmdk,if=ide,media=disk -initrd initrd.img-2.6.26-2-alpha-generic -kernel vmlinuz-2.6.26-2-alpha-generic -append "root=/dev/hda2"

Obviously this was a lot more time consuming than it should be, but now I can do useful things.

Also sometimes Qemu just sits there with a black screen. the UI is waiting for something ,not sure what. It’ll either come to life on it’s own or you got to bang it.

Using Qemu in 2020

So I wanted to dive back into old BSD, and I wanted to use the new native Qemu on OS X. That means having to “learn” the new crazy syntax that has drifted a LOT over the last 10+ years.

I want to run NetBSD 1.0 and tear into the GCC 2.x patches required back in the day

In the old days, I was using Qemu 0.13 and had it working using the following:

qemu.exe -L pc-bios -hda netbsd-1.0.vmdk -net nic,model=ne2k_isa -net user -redir tcp:42323::23 -m 64 -no-reboot  -rtc base=localtime -k en-us

Thankfully I was using VMDK containers, probably as I’m sure I installed it under VMware, with it’s better floppy support, but pulled it back to Qemu to have NE2000 support. Now let’s look at the dmesg to where the source of the problem is, the network card:

NetBSD 1.0 (QEMU) #0: Thu Sep 22 06:45:37 PDT 2016
    [email protected]:/usr/src/sys/arch/i386/compile/QEMU
CPU: Pentium (GenuineIntel 586-class CPU)
real mem  = 67764224
avail mem = 62312448
using 852 buffers containing 3489792 bytes of memory
pc0 at isa0 port 0x60-0x6f irq 1: color
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
lpt0 at isa0 port 0x378-0x37f irq 7
wdc0 at isa0 port 0x1f0-0x1f7 irq 14
wd0 at wdc0 drive 0: 1023MB 2080 cyl, 16 head, 63 sec <QEMU HARDDISK>
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
fd0 at fdc0 drive 1: density unknown
pci0 at isa0 port 0x0-0x665: configuration mode 1
pci0 bus 0 device 0: identifier 12378086 class 06000002 not configured
pci0 bus 0 device 1: identifier 70008086 class 06010000 not configured
pci0 bus 0 device 2: identifier 11111234 class 03000002 not configured
ed0 at isa0 port 0x320-0x33f irq 10: address 52:54:00:12:34:56, type NE2000 (16-bit)
npx0 at isa0 port 0xf0-0xff: using exception 16
biomask 4040 netmask 412 ttymask 12
changing root device to wd0a

So the important thing here is that the NE2000 is the ed0 device using an IO of 0x320 and IRQ 10. I’m pretty sure back then I cheated, and just recompiled Qemu to remove the default definition that doesn’t work properly with trying to share IRQ 9.

Keeping this in mind, let’s build this for the new Qemu:

qemu-system-i386 -net none -device ne2k_isa,iobase=0x320,irq=10,netdev=ne -netdev user,id=ne,hostfwd=tcp::42323-:23 -drive file=netbsd-1.0.vmdk,if=ide,index=0,media=disk,cache=writeback,format=vmdk -rtc base=localtime -k en-us

So the first important thing is to disable any/all defualt NIC’s with the ‘net none’ flag. Next to add in the NE2K_ISA type device manually so I can specify the iobase & irq manually. Note the netdev as this is used to tie in the emulated device, to the backend that will process the packets. The next part is the redirect to have the host listen on port 42323 and redirect them into port 23 of the VM. Again the syntax to redirect ports has drifted significantly. The hostfwd now is bound directly to the netdev user, in this new syntax it allows for multiple NIC’s to be bound to multiple user NAT’s if needed.

-device ne2k_isa,iobase=0x320,irq=10,netdev=ne -netdev user,id=ne,hostfwd=tcp::42323-:23

The next ting is the hard disk, before ‘hda’ worked fine, although like everything else that is subject to change in the future, so dealing with it now, use the drive flag:

-drive file=netbsd-1.0.vmdk,if=ide,index=0,media=disk,cache=writeback,format=vmdk

It could be my personal opinion but the drive syntax, although much longer is easier to work with. The key parts being what interface to use (IDE), and what port/index to plug the device in (0), along with the media type, the cache strategy, along with the encoded format, which is more so important when dealign with RAW devices, as unidentified media will be tagged as raw, however it’ll be mounted read-only unless it is directly specified as above.

For additional fun, the serial port can be set to a MS Mouse port, although I haven’t tested it as of yet.

-serial msmouse

Have fun QEMU’ing!

Qemu 5 was recently released

It’s been jumping numbers like crazy, and I’m still holding onto 0.9 because I’m weird. Anyways there is something amazing hiding in all those release notes and stuff:


The m68k emulation is good enough to run Linux! Granted the target machine is the Macintosh 800, although the Mac ROM doesn’t boot enough to do anything Apple enough, using a serial console however does get us into the system. On my ancient Mac Pro I get emulation in the speed range of a 1Ghz G4!

[email protected]:~# cat /proc/cpuinfo 
CPU: 68040
MMU: 68040
FPU: 68040
Clocking: 1304.9MHz
BogoMips: 869.99
Calibration: 4349952 loops

Absolutely amazing!

Installation is a bit tricky as there is no true bootrom / boot process, so I had to load the installer with a dummy ‘raw’ disk, and tar the kernel & initrd to that raw disk so I could later extract it on the native OS to boot into the disk. I followed mostly the instructions here.

And what is that? NeXT CUBE emulation?

The peripherals are nowhere near complete enough to boot, HOWEVER it does boot the PROM, complete with keyboard support.

qemu-system-m68k -M next-cube -bios Rev_2.5_v66.BIN

It’s fun enough to play with. And thanks to Qemu’s fast emulation, perhaps this is a speedy way to run stuff in the future?

Now isn’t that cool?

How not to store optical media

Or how I finally broke down and bought that MkLinux book after all these decades. When I did own a PowerPC Mac as my daily driver it was an iMac back in 1999 and I ran OS X Server. I later bought a G4 to only find out that OS X didn’t support the G4. Linux had issues too and I ended up running OpenBSD on the G4. Which was fun, although for the ‘work at home’ bit, I ended up needing Windows NT 4.0, so I ran that in OS 8 on SoftPC. Yay.

I didn’t have any luck with Linux on Power as MkLinux wanted the beige hardware, and by the time I felt like digging in again to Linux, OS X had finally been ported to the G4 Sawtooth’s so it really didn’t matter.

What secrets lie inside?

I’d seen this book in a store but it was pretty expensive, and geared to such a tiny market. Although Mach does compile on the i386, why they didn’t include it was well to push Mach/Linux as a platform well that’s beyond me. Then again looking at the stunning success of Darwin on i386/x86_64 I guess the reality is, why bother.

I ordered this on Ebay, for the usual $5 plus $10 to ship, and it just showed up today! What mysteries lie on the CD-ROMs? I know others have posted stuff, but I wanted to hold them in my hands myself.


I didn’t know if the CD-ROM’s were included, and I first thought I got lucky: not only were they included, neither had been opened up before! These CD’s had been packed way like this for the last 22.5 years! Now for the bad part.

Ink transfer

See that stupid leaflet in the back? Yeah well it turns out that it was a really stupid idea. No doubt this thing sat in the bottom of a stack for decades where the ink had been pressed for so long against the disk that it has transferred to the surface.


Gag me with a spoon…

So yes, they actually advertise the book, namely the one that I had bought with some crap ink leaflet in the CD-ROM pouch and it’s transferred to the disc.


I tried rubbing alcohol but that had no effect. I tried rubbing with a credit card, and it got a little off, but I fear I’m just going to damage the surface more.

I can only imagine what other CD-ROM’s out there that haven’t been archived are sitting under hundreds or thousands of pounds of book weight having nonsense imprinted onto them.

At least the second CD-ROM doesn’t suffer this defect and I’ll be uploading it later.

No book review yet, I’m just sitting here with this impacted CD.


Thanks to Shawn Novak for uploading the R3 images so I can at least pull up the compatible machines:

The latest Qemu can pull it the image fine, however trying to boot up looks like the Mach kernel just isn’t compatible enough with the emulated Mac99 machine (which isn’t surprising).

I’ll need to mess with stuff to see if the G3beige can boot Linux on Qemu, and if the BootX (I think it’s bootx?) can load the mach kernel.