Wyse Unix from floppy and tape images

(click here for installation instructions and files)

Here we go again!

Despite promising myself that after I'm done with Snoopy Calendar and Venix/86, my next post won't be related to virtuallyfun, there has been yet another impossible to avoid challenge! As usual, an obscure system that I knew nothing about. However, it is an Unix system, so there are some things that are known by default. First things first: get the floppy image to boot. The challenge page states "[...] made some modifications to get them to boot on VirtualBox". It seems that since then, Oracle has made some modifications to VirtualBox so that it no longer boots, instead failing with "cannot open root device", although that's only a floppy so far.

UPDATE 2015-10-12
Oddsocks pointed out that VirtualBox didn't boot because I failed to set the FDD geometry for 1.2MB diskette. I must say in my defence though, that the option is as easy to find as were the demolition plans for Arthur Dent's house.

Plenty of machines

Next try was QEMU (it's quite handy) - it flashed some text and then a blank window.
PCem with TVGA would start OK then garble the text. Apparently it did work, only the video memory was garbled. I remembered that 1. TVGA was just a little bit different at the time¹ and 2. PCem also emulates a Tseng ET4000 VGA. Once this was selected, surprise, the picture was fine. However, there is another problem with PCem. Despite detecting and partitioning the drive without a problem, it stops with an error when "Checking for bad sectors in the UNIX System partition..."

After various experiments to get rid of that error I concluded that it might be a timing problem and went for the real thing. That is, a 386 with 5.25" floppy. This would also allow me to eliminate any potential problem with conversion from IMD to raw, because I wrote the floppy with IMD. However, this 386 has a Trident VGA card inside, so... tough luck - the image is again garbled.
Two more tries (a Cirrus VLBus on a 486 and a PCI S3 on a Pentium) have the same problem. Now I'm thinking that maybe I should have tried the other diskette image (WYSEBASE.IMD) too, but I doubt it would have made any difference, the kernel from tape is different and shows the same problem. I think it might be possible to reconfigure the kernel though.

bochs to the rescue

When thinking what emulator to try next, getting desperate enough to think "where did I put those old Virtual PC kits?", I remembered bochs. Maybe it will have an older VGA and also not have problems with the HDD. I don't think I ever used bochs before, but I heard about it from a friend that is/was into OS building. Surprisingly, bochs' Slackbuilds page doesn't list any dependencies (quite rare, these days). I always like that. While it's compiling I play a little more with the real hardware (the other 2 tries above). Running bochs gives the same "blank" display as QEMU but this time with a clarifying message:
02292337304i[XGUI ] charmap update. Font Height is 16
So that's what's going on. And having a debug message on this, I gather there must be some possibility to de-activate this. Alas, no. All searches return various discussions from back in 2002 when probably this feature was developed. Nevertheless, bochs allows me to see what's on the screen by using its snapshot tool. A little cumbersome, but at least I get to see it not complaining about bad sectors. This gives me an idea. Apparently all that was stopping PCem from proceeding with creating the filesystem was that check. What if I use "blind" bochs to create the filesystem and take over from there using PCem? Around 10 snapshots later I have a bootable HDD image with only a single partition for root and usr (just in case) that has enough to continue installation from either tape or floppy. And indeed it works in PCem. I also made a clean copy of it, thinking I might trash it in my further experiments.

Getting around Unix with low resources

The above heading seems quite absurd, right? I'm talking available programs. When booting from HDD the installation script can't easily be stopped (by Ctrl-C, say), while the one on floppy is only too happy to drop me to the prompt, I try and continue installation while booting from floppy. Tenox has already given a good pointer for using tape images so I only need access to a minimal Unix in order to do more or less the same. The installation filesystem is slightly less than minimal.

# ls
ls: not found
# cat
cat: not found
# echo *
INSTALL INSTALL2 LABEL addparts bin core dev etc mkfs.data mnt readfloppy shlib
tmp unix usr yes
# echo bin/*
bin/-sh bin/chgrp bin/chmod bin/chown bin/cp bin/cpio bin/dd bin/ed bin/expr bin
/find bin/ln bin/mkdir bin/mv bin/rm bin/sh bin/sleep bin/stty bin/su bin/sync

No ls? No problem, echo * is almost good enough and dd if= replaces cat.² I already knew from looking at the tape sections that this time cpio is used instead of tar and it's available in bin.

Preparing the archive

I looked around the bootdisk image for the installation commands and everything was in plain sight. The relevant command is:
CPIO -icmduB < /dev/rct/c0s0n > /dev/null 2>&1
(a little above in the script /bin/cpio is copied to /bin/CPIO)
I padded the 00001 section with a few K to make sure it would fit with the HDD geometry and then:

(I used the geometry PCem suggested)

I resisted the temptation to reboot from the HDD and see how it works with this partial restore. I was going to do this right. I extracted all the sections in a temp directory under files with:

for i in ../0000? ; do cpio -icmdu <$i ; done

This has to be done as root. I checked twice to ensure it won't use absolute paths!

That would extract the entire structure in a directory on my machine. I also created a directory for aclock and copied all the sources there to have them handy (this was a small mistake, old UFS has 14 characters filename limit so the names were truncated).
The script I saw on the bootdisk also ran a lot of other commands to setup devices, runlevel scripts and so on. I copied the whole bunch of commands into a file (h_inst). I noticed that chroot is available under etc/ - that would come in handy.

find | cpio -oc >../nt.cpio

Created a "new tape" file that I again padded with 512K of zeroes, just to be safe and not care about geometry.

First full install

Using the "clean" HDD image from an earlier step as first HDD and my padded "nt.cpio" as secondary HDD I booted (PCem) from the WYSEBOOT floppy, stopped the installation process, got to the shell and then:

# mount /dev/dsk/0s1 /mnt
mount: warning: <rootus> mounted as </mnt>
# cd /mnt
# cpio -icmduv </dev/rdsk/1s0
<SNIP>
# sync
# etc/chroot /mnt /bin/sh
# ./h_inst

That would execute the "after restore" installation script that starts with a trick question, "Enter your terminal type:". What to answer here? vt100 seems safe, although since it's about the console implemented in Wyse the question seems kind of superfluous.
The script runs more or less successfully; it didn't ask me for the root and install passwords but I ignored that for the moment. At the end, sync; exit; sync; cd / ; umount /mnt; sync³ then eject the floppy, close and restart PCem (for some reason something is not really reset on Hard reset so Wyse would not boot twice on PCem). Then, to my joy, I was presented with the boot-up sequence of an installed Wyse Unix. However, all was not yet good. After login the system would hang before the prompt. Eventually I conclude that it doesn't work on PCem 386 (perhaps not real 386 either) and it requires 486. On 486 everything seems to be in order.⁴

Nearly there but the login would hang on this 386. Maybe it's the lack of a math coprocessor?

Did you notice that time is standing still? I didn't.

aclock woes

After the succesful login, I notice the 14 characters filename problem and identify the proper aclock to compile. The K&R version seems to compile fine, but on running it hangs after drawing half a clock. It does this no matter what machine I choose to emulate, it always hangs at the same point.

Four half quarters of aclock

I try the same hdd image on the (invisible ink) bochs and I see that aclock runs fine on it. Time to dig deeper into the charset problem. Not noticing that bochs has a curses mode I modify the sources to ignore charset changes, rebuild it and it works! Sort of. The clock is running way too fast, but I'm already worried about priority for the challenge so I shoot a quick e-mail to Tenox, just in case.
I then look at the bochs configuration in detail and notice that the Clock & CMOS options configuration menu, where I can set Synchronisation method to realtime (from none) and also Sync RTC speed with realtime: yes (default no). After that the clock is running fine, so I send another mail and post a comment on the challenge page. Something else I noticed was that for some reason Ctrl-C would not return me to the terminal (although it would stop aclock). Remembering DOS days I try Ctrl-Break and it works, returning to the shell. Nice of bochs to pass Ctrl-Break through.

First successfull and complete run on bochs

A few refinements

Being now at ease with the challenge, I look for ways to improve things. Sometime during the above frentic search for solutions I thought about using MAME/MESS as well and started a compile on it. It's taking a while (I think it passed the hour mark). In the meantime I make some more tries with PCem and notice that in fact the system clock in PCem is not advancing. Each date invocation returns the same time. Well that explains the hangs (it also would hang on shutdown, not only running aclock).
When building of MAME/MESS is finished, I set out to finding the "at386" and "at486" packages and notice that the default VGA card for those packages is the same Tseng ET4000 that I knew worked in PCem. A quick hdd conversion (chdman createhd -i wyse_1000_16_63.img -o wyse.chd) and configuration later, my hdd image proves to be working in MESS. However, MESS doesn't seem to be able to use 2 HDDs for a machine, so while it can be used to run the system, it can't be used for installation.
Only at this point I realise that both bochs and QEMU have a curses mode. Of course, in curses there would be no charmap problem. Indeed, when trying the currently built image, it works fine in both cases.⁵
The next improvement is avoiding to use the script copied from inside the BOOT image. I instead modify the boot image to restore from second HDD insted of tape. This results in the install script running correctly (and asking for root password).

# shutdown -y -g1

Shutdown started.    Mon Sep 21 19:35:12 PDT 2015


Broadcast Message from root (console) on awyseclk Mon Sep 21 19:35:12...
THE SYSTEM IS BEING SHUT DOWN NOW ! ! !
Log off now or risk your files being damaged.


# 
INIT: New run level: 0
The system is coming down.  Please wait.
System services are now being stopped.
cron aborted: SIGTERM
! SIGTERM Mon Sep 21 19:35:18 2015
! ******* CRON ABORTED ******** Mon Sep 21 19:35:18 2015
Print services stopped.

The system is down.

Reboot the system now.

Thank you for reading

¹ The reason I remember this is because 20 years ago I had to run the DOS Z80 emulator with -xv option for "400-line VGA (for some Tridents)".

² You should read the classic horror story found here (among other places). If link is dead, here is a local text copy.

³ sync; sync; reboot (on old SCO Unix box, perhaps others as well). I don't know if so many syncs are really needed (the last one should be enough) but their install script is full of them, so I play it safe.

⁴ ...All right, Gordon. Your suit should keep you comfortable through all this.

⁵ My version of QEMU (2.3.0 compiled from slackbuilds a while ago) seems to be having some problems with storage. I noticed it happening with DOS guests and now it's happening with Wyse as well - rare random read errors from the virtual HDD. Switching to qcow2 format from raw doesn't help. Fortunatelly the newest version (2.4.0) seems to work fine.

Published 2015-09-21 by Mihai Gaitos - contact hawk.ro