The virtualization of a working SCO Unix box.

(Note: This is from a doc I created years ago from my hospital job. It was a fun challenge and I’m glad my persistence paid off.)

I have already converted a working Mandrake Linux box to a VM so doing the conversion of a SCO Unix box seemed to be a breeze. Not quite.

Some of my techniques did work and that is where I started. I booted the system with a Ghost boot disk. I have access to a Ghost server so I used that to create a ghost image file.  If you have Ghost, so you should be fine to convert to a file on a separate hardrive.

I created a VM with a drive as big as the one that physical box had. Whether you allocate the space now is up to you and how much performance you require.  Now the task is to apply that ghost image to the drive. I keep a Windows based “Helper VM” around for just such purposes. I have tried using a ghost boot disk with mixed success. For that reason, I prefer to use Ghost32 in Windows. I have had imaging freeze up using DOS based boot disks.

Before booting up my helper system, I attach the vmdk file from the VM I created earlier. I don’t move the file.  I browse to the new VM folder and use it from there. Once I boot up the Helper VM, I use Ghost32 to apply the .gho image of the Linux box to the second drive. Once the imaging is done, shutdown the Helper VM. To avoid error messages later, remove the second drive from the Helper system.

Of course with the VM system you are trying to create, you want to make sure you add any non-standard devices you need such as COM ports and Parallel ports.  Also, I tried to keep the memory size the same. When booting up the Mandrake system, it seemed more like my curious cat in a new house. I thought it wouldn’t work because it’s on new hardware. Instead, it just keep noticing new devices and prompting to install them. With Mandrake, the only real task I had to do was to configure the former systems’ TCPIP settings on the new AMD Pcnet family NIC it now had. I rebooted and the machine was pingable and our apache based page worked just fine from my windows system.

SCO Unix was a different story. I did the same method for the SCO box but with quite different results. The system started booting and stopped at a Boot: prompt. I pressed enter and the system started up displaying some memory errors. Things got worse, as the system stopped dead with a Kernel Panic and a second Double Panic message.

I searched around and found a page with some SCO notes. I found out about this command for the memory problems:


I entered it at the Boot: prompt and the memory errors went away. The kernel panics didn’t. 

Research on the error message didn’t give me any concrete leads.  I thought perhaps the differences between the hardware was the biggest factor.  I thought I could borrow a Windows trick and try installing SCO Unix over the existing VM. This wouldn’t work as none of the old settings stuck.

Looking deeper into what was out there, the “repair” method really involves a fresh install and restoring from a backup. I didn’t have much viable options. The old system had a tape drive but that wasn’t much of an option as I cant use that with a VM. The graphic interface’s backup program offered either a 3.5″ floppy disk or a 5 ¼” floppy disk. Not very attractive option with a 6.4 gig drive! There were options to remote to a backup system. I got to learn about setting up rlogin to login as root on a remote system sans password. This was needed for the remote backup to work. This remote option would either work with the floppies or any tape drives.  If someone tries it, the tape option might work but I never had the chance. The tape drive was defective. I had hoped to back up locally to the physical boxes tape drive and remotely restore from it on the VM. Back to the drawing board as the cliché goes.

I thought if I could at least recreate the kernel panic on the physical box, I would be much farther ahead. The physical system had a scsi card for the tape drive. I tried removing the scsi card and I got the same panic.  Great! I put the card back in. Now to see how to make the physical box forget about the scsi card. I learned about a command called hwconfig (.scsi_cdrom) and used that to remove the only scsi device listed which was a cd-rom drive (it didn’t have one). I removed it anyway thinking maybe it treated the tape drive as such. I booted again with the tape drive disconnected and no panic. I doubt the CDROM part mattered. I did find information online about removing devices. I mostly had to know the name of the device.

When SCO Unix starts, you see the device name as it starts each one. I simply checked what came after the point that the VM crashed. The device name I saw was ALAD. In the example I got, the main trick was to navigate to where the startup device files are.  I had to use Vi to change the Yes column in this file (required) to a No. Now after a lengthy shutdown process, I tried booting again without the SCSI card. Success! No errors at all.

This meant I had to recreate my Ghost image and my virtual disk. The VM booted without a problem this time.

Like with Mandrake, I need to configure the new nic.

Ode to Jack Tramiel – SYS64738

My first computer, such great memories!

I’m starting this blog as a way to dump some of my knowledge to the web. I have a few motivating factors behind this. I want a way to keeps notes of solutions that I have found that could also help others. I also want some of my knowledge to be available for my daughters to later have use of it and to also have a way to know the IT side of their Papa (Dad).

The brunt of what I will showcase will be advanced techniques geared towards people already comfortable with IT and want to either go further or are simply stuck when trying to solve a problem they are dealing with.


I always intended to start this blog with the oldest command I remember. That is SYS64738 which is the code to soft reset a Commodore 64. You could call this the C64’s Ctrl-Alt-Del.  With the passing of Jack Tramiel, I have to say thanks to him as I got my start with a Commodore 64. The first time I saw one was in my grade 5 class. We had it set aside in a corner with two chairs and a sheet for everyone to sign up for their turn. I found myself hanging around watching even when it wasn’t my turn. I was doing that so much that the teacher was surprised to hear I hadn’t gotten my turn 🙂 Jack’s system gave birth to a sense of wonder in me for technology that has never gone away to this day.  I made use of it for years. It was the first plug and play system with instant on. We still strive to have this now.

Yes I played some games like everyone else and tried to make myself in Fancy Face. Speedscript was the word processor of the time. I felt like somewhat of a pioneer as I always switched to the non-default Insert mode (otherwise you overwrote your own text). It also got me started in programming. I learned to appreciate counting line numbers by 10 to leave room for additions.

I created a few programs to keep track of information. My first big program was creating a poker program that imitated the popular machines everyone liked. It really made my mind work in figuring out how to generate random cards without repeating. I had to determine what hand was on screen and how to display the right cards. It wasn’t perfect as after long play bugs did appear but it was fun.  I gave a copy to a friend but had to do it via tape drive. I had a 5 1/4 floppy drive (1541-II) which never seemed to have the same alignment as the 1st gen 1541 drives. I eventually got an old dot-matrix printer to get around my incompatible floppy issue as I could never print at school.  It was insanely loud and I usually ended up putting a pillow on it to try to muffle the noise.

A lot of great memories that started with Jack Tramiel. I didn’t know who created the C64 at the time but I now appreciate what he did. Thanks Jack for all the careers you inspired. May you rest in peace.

Solutions found through research, scripting and hard work.