Hi,

machmal macht man ja Dinge, die nicht 100% rational erklärbar sind, aber man kann dann doch nicht aus seiner Haut, und so.

Wie der eine oder andere weiss, ist mein Arbeitsplatzrechner zu Hause ("das Ding mit Maus, Tastatur und Bildschirm dran") ein SCO Unix, genauer gesagt, ein SCO Open Server 3.0.

Installiert im März 1993(!). Ja, wirklich. Eine Betriebssystem-Installation, die seit über 16 Jahren stabil und ohne reinstall ausgekommen ist (und das ist gut, weil die Original-Boot-Diskette vermutlich nicht mehr lesbar ist, und ob mein aktueller Streamer die Original-Install-Bänder noch lesen kann, weiss ich auch nicht).

Natürlich ist die Hardware nicht ganz so alt - 1993 war das ein "echter" 386er mit 40 MHz und 16 Mbyte RAM, wurde dann mal zu einem 486 aufgerüstet (Asus SP3, das erste PCI-Mainboard auf dem Markt, signifikante Fehler in eigentlich jedem Chip auf dem Board) und später zu einem Pentium-200 (Tyan Tomcat-Board). Nach zwei Mainboard-Ausfällen aufgrund eines defekten Netzteils (grrr) ist inzwischen ein AMD K6-450 drin, mit gigantischen 384 Mbyte DRAM.

Die Platte wuchs von etwa 500 Mbyte (Fujitsu SCSI, 3.5" volle Bauhöhe, an einem Adaptec 1542B ISA-SCSI-Controller) zu meinem Traum: gespiegelte 2x 9Gbyte Ultra2-SCSI IBM an einem ICP/GDT Cache-RAID-Controller, PCI natürlich.

Die Graphikkarte entwickelte sich von einer Tseng ET4000 über eine MIRO S8 (die erste PCI-Graphikkarte auf dem Markt, S3 805 mit diskret aufgebauter PCI-Logik - volle Baulänge! - liegt hier im Museum noch rum) über eine Miro 20SV (S3 968) - wohlgemerkt: alle noch mit Original-SCO-Treibern! - zu einer Matrox MGA G450 mit einem selbst nach SCO portierten XFree86 3.3.6 (inklusive Kernel-Patch für mmap()-Unterstützung von PCI-Memory). Allerdings ohne Dual-Head, das geht erst ab XFree86 4.x und das war mir dann doch zu heftig.

Aktuelle Software ist auf dem System leider aus verschiedenen Gründen kaum noch zum Laufen zu bringen:
- kein Thread-Support im System
- keine unix sockets
- kein IPv6
- "kein Linux" (und ja, für heutige Software-Autoren ist das ein echtes Hindernis)

... weshalb ich seit Jahren den Firefox von Neko's Linux-Rechner per Remote-X11 verwende - tut prima, hat aber das Problem, dass der Rechner (AMD Athlon 900) auch gerade ausgemustert wird, und nachdem Neko inzwischen total verMACt ist, geht das damit nicht mehr.

Also: neuer Rechner, aktuelle Hardware (auf der das SCO nicht mehr booten würde, wegen "was ist das für ein Prozessor? was ist das für ein Bus? was ist das für eine Netzwerkkarte? *PANIK*"), Dual-Head-Graphikkarte, und so.

Aber gleichzeitig soll das venerable SCO natürlich weiterlaufen - und noch einen Rechner, der dauernd an ist, und Strom frisst, braucht's hier wirklich nicht.

Die Idee

Mit meinem Spielwindows habe ich es erfolgreich praktiziert, warum soll das nicht auch mit SCO gehen? Einfach virtualisieren. VMware workstation oder VMware server, "tut einfach".

Googeln gegangen: ja, es gibt Erfahrungsberichte, dass das geht (hier, hier oder insbes. hier). Dass es zwar mit Schmerzen verbunden ist (SCSI-Controller, Treiber, ...), aber es haben Leute erfolgreich hingekriegt. Allerdings nur mit OSR 5.0.<aktuell>, nicht mit 3.0 - welches wirklich ein paar Generationen älter ist.

Interessantes Tidbit am Rande: einer der SCO-Entwickler, mit dem ich früher viel zu tun hatte (Bela Lubkin), ist jetzt bei VMware und damit natürlich die Adresse für knifflige Fragen in diesem Zusammenhang. Bela hat sogar noch einen Account auf dem Rechner, um den es geht

Der Plan

Hier steht grad eh' ein Superduper-Server für einen Kunden, der da einen Teil seiner Altlasten (einen Windows-Server und ein SCO OpenServer 5.0.5) virtualisieren will. Xeon-Dual-Core, 2G RAM, schnelle Platten, damit macht das doch Spass

Unix-Platten "einfach so" in VMware-Disk-Images verwandeln geht nicht. Also:

• in einer VM ein SCO 5.0.x installieren, Install-Medien liegen hier eh noch rum
  
• in dieser VM eine zusätzliche Festplatte einbinden, etwas grösser als auf dem alten System
  
• via "dd" das System blockweise rüberkopieren (über Netz vom laufenden System in die VM/disk1)
  
• die zusätzliche Festplatte als primäre Platte einer neuen VM einbinden
  
• booten, freuen, Treiber für Netzwerk, X11, usw. fixen
  

Die Umsetzung, und die lustigen Probleme

Tja, wenn das mal alles so einfach wäre.

Der erste Teil ("SCO OSR 5.0.x installieren") hat verblüffend gut geklappt. Die Boot-Disketten waren alle noch lesbar, die Installation hat funktioniert, und meinen "free for private use"-License-Key aus der Zeit, wo SCO noch an "Leute verwenden unser Produkt!" interessiert war habe ich auch gefunden.

Netzwerk & die Einbindung der neuen Platte waren auch einfach, Fingerübung.

Die alte Platte mit "dd" kopieren war schon aufregender. Eigentlich war der Plan gut, aber ich vergass ein Detail: SCO ODT 3 hat keinerlei Support für Files grösser 2 Gbyte.

Das heisst:

# dd if=/dev/hd00 bs=512k | rsh neu dd of=/dev/hd10 bs=512k

hat zwar prima funktioniert, aber nur 2G von 9G kopiert, dann Abbruch mit Fehler.

Die wichtigen Sachen waren aber dabei (Partitionstabelle, Boot-Sektor, Root-Filesystem). Den Rest hab' ich dann halt Filesystem für Filesystem kopiert (SCO! es gibt Unix-Partitionen, und in diesen drin dann "divvy"-Slices, und da drin sind dann die Filesysteme) - statt einer Platte bzw. zwei Partitionen waren halt dann etwa 10 "dd...rsh..."-Aktionen nötig. Etwas nerviger als nötig, aber immer noch viel weniger Arbeit als "Partitionen und Filesystem von Hand anlegen und dann 10000e von kleinen Files per rsync kopieren" (was auf dem Zielrechner auch erstmal gar nicht drauf war, usw.)

So, dann also mal sehen...

... neue VM gebaut, besagte Platte als "primär" eingebaut, gebootet...

crash boom, Kernel Panic zu Besuch - klar, er findet sein Root-Filesystem nicht.

SCO Unix ist ein altes System, von dem die anderen gelernt und 10 Jahre verbessert haben - sprich: so nette Automatismen wie heute unter Linux "finde einfach die erste Platte im System und binde sie ein, und dann schau mal, wie weit Du kommst - und zur Not sagt man root=/dev/hda17 am Boot-Prompt" gab's halt nicht, die Zuordnung Devices<->Controller ist fest in den Kernel kompiliert.

Das war mir eigentlich klar, ich wollte auch nur sehen, ob's überhaupt zumindest den Kernel lädt - was es getan hat, also frisch ans Werk...

... die Device-Treiber und die Boot-Festplatte

Die grundlegende Vorgehensweise war ganz klassisch, wie man das auch im Zweifel bei einem echten Problemrechner machen würde - nicht-bootende Festplatte in einen anderen Rechner einbauen, dort den Kernel fixen, dann wieder zurückbauen und testen. Bei VMware geht das natürlich einfacher, weil man einfach abwechselnd die SCO 5 und SCO 3 VM hochfahren kann.

In der SCO 5 VM (wo die SCO 3-Platte als "disk 1" dranhängt) kommt man dann mit

# mount /dev/i1.root /mnt

# chroot /mnt /bin/sh

# cd /etc/conf/cf.d

# <kernelconfig verfummeln>

# ./link_unix

# exit

# umount /mnt

# init 0

ziemlich schnell zu einem neuen Kernel. War natürlich trotzdem nicht so einfach, denn SCO 3 hat ab Werk keinen Treiber für den emulierten BusLogic PCI-SCSI-Controller, und der Treiber für SCO 5 (den da oben alle referenzieren) tut nicht, denn die interne PCI-Bus-Logik hat sich zwischen SCO 3 und SCO 5 dann doch geändert - es linkt nicht, mit einer klaren "hier geht's nicht weiter" Fehlermeldung:

undefined                       first referenced

 symbol                             in file

pci_readbyte                        /etc/conf/pack.d/blc/Driver.o

pci_finddevice                      /etc/conf/pack.d/blc/Driver.o

pci_readword                       /etc/conf/pack.d/blc/Driver.o

... und das klang erstmal nicht gut. Also weitergesucht, und tatsächlich ein Treiberpaket für SCO 3.0 und BusLogic-Controller gefunden (auf der Mylex-Webseite, die BusLogic irgendwann mal gekauft haben). Das Paket bestand natürlich aus einem DOS-.exe, was dann eine Unix-BTLD-Diskette erstellt... gah. Aber mit einer Windows-XP VM, Samba und einem Floppy-Image in VMware ging das dann auch.

Installation in der SCO 3 chroot-Umgebung ("btldinstall /mnt", wohin vorher /dev/rfd0138ds18 gemounted war, in /etc/conf/cf.d/mscsi den Treiber für die erste Festplatte auf "blc" umstellen) hat auch geklappt, Kernel hat sich auch linken lassen, aber beim Booten trotzdem crash boom, kein SCSI-Controller gefunden.

Auf dem Weg noch ein paar kleinere Probleme gefunden:

• In der SCO 5.0-VM hatte ich "snapshots" aktiviert, damit sind die Änderungen an der SCO 3.0-Platte nicht auf die Platte geschrieben worden, und die neuen Kernel sind gar nicht erst angekommen (lösbar, snapshots abschalten)
  
• Aus irgendwelchen widrigen Gründen war die "SCSI"-Festplatte für die SCO 3.0-VM im VMware kein SCSI mehr, sondern IDE (lösbar, im .vmdk-File von controller="ide" auf controller="buslogic" umstellen - mit einer Linux-Boot-CD verifiziert: jetzt SCSI!)
  

Ging aber alles trotzdem nicht. Resümee: der SCO 3.0 blc-Treiber spielt nicht mit VMware-Buslogic-Controllern. (Bin grad noch dran, das Thema mit Bela zu diskutieren, weil "jetzt wollen wir's wissen" ).

Mmmh, was nun. IDE disks?

Bei einer Neuinstallation ist das kein (grosses) Problem, nachdem IDE ja "wd1003" kompatibel sind, und dieser Controller alt genug ist, dass SCO ihn wirklich unterstützt (mein erstes SCO wurde noch auf einer echten MFM-Platte an einem WD1006 installiert). Schwierig ist die Umstellung.

Einen anderen SCSI-Treiber zu verwenden ist ganz einfach - den neuen Treiber installieren (legt einen Haufen Zeug in /etc/conf/{pack.d,sdevice.d,...} ab), in /etc/conf/cf.d/mscsi die Zuordnung Platte<->Treiber anpassen, neuen Kernel bauen, rebooten, gut ist.

Das Problem mit dem IDE-Support ist aber, dass der bei SCO nicht als "SCSI"-Treiber läuft, und sich mit den normalen Bordmitteln für "mach mir einen neuen Controller / eine neue Platte" (mkdev hd) nicht um eine IDE-Platte erweitern lässt - das System sagt "wenn ich jetzt ein SCSI-System bin, wäre ich beim nächsten Booten ein IDE-System (Reihenfolge im System), und deshalb supporte ich diesen Prozess nicht".

Egal. Grosser Hammer, und nachher die Scherben richten

In /etc/conf/cf.d/mscsi erstmal dem SCSI-Subsystem alle Geräte weggenommen, und in /etc/conf/sdevice.d/$treiber die ganzen SCSI-Treiber abgeschaltet. Dann in /etc/conf/sdevice.d/wd den generischen WD-Treiber aktiviert (erste Spalte auf "Y"), festgestellt, es reicht nicht, und die "Instanzen 0 und 1" (.../sdevice.d/wd0 und .../wd1) auch aktiviert. Das ist bei SCO 5 anders, da gibt es nur einen Treiber "wd", der sich um alle Controller und die Platten kümmert.

Also, neuen Kernel als Boot-Kernel abgelegt, SCO 5 VM runtergefahren, die Platte wieder auf controller="ide" umgestellt (jetzt soll sie ja eine IDE-Platte sein), frohgemut die SCO 3 VM gebootet, und... bah... crash boom. Die Disk-Geometrie gefällt ihm nicht, und der SCO 3 "wd"-Treiber kann auch keine Platten grösser als 8 Gbyte - wir haben hier 9...

Jetzt war's aber einfach, denn der "proof of concept" ist erbracht. Also zwei IDE-VM-Disks mit jeweils 5G angelegt, die zwei Unix-Partitionen mit ihren ganzen Filesystemen von der 9G-Platte rüber-dd-t (also genauer: die Partitionen angelegt, die Filesysteme in "exakt gleich gross" angelegt, dann die Filesysteme dd't - es ist einfach schneller als rsync).

... und siehe da...

... es tut!!!

... Netzwerk?

Im alten System war im Lauf der Zeit so diverses drin - erstmal gar kein Netzwerk (1993? Ich bitte Euch, das war teuer! Und ich hatte auch nur einen Rechner...), dann eine günstig erstandene WD8013 aus einer Insolvenz (100 Mark für 2 Stück haben die damals gekostet, glaube ich - dafür war es eine 16-Bit-ISA-Karte mit BNC und 10BaseT und AUI!!), später dann mal eine DEC 21143-basierte 100Mbit-Karte (memory-leak im Kernel, ganz schlecht) und jetzt ist da so was billig-Realtek-basiertes drin, was 100Mbit spricht, einen SCO 3-Treiber mitbringt, und einfach funktioniert.

VMware bietet zwei verschiedene emulierte Netzwerkkarten an: eine AMD LANCE und eine Intel E1000 (1G). Und eine "pseudovirtualisierte", die natürlich einen Vmware-Treiber braucht (den es für Randgruppen-Betriebssysteme nicht gibt). Die 1G-Karte hat sicher auch keine Treiber für ein Betriebssystem aus der Zeit von 10 Mbit - also AMD. Oder aufgeben.

Erster Versuch: SCO's eigenes "netconfig" befragt. Nein, nichts, was auch nur annäherend nach AMD Lance aussieht.

Bei Intel geguckt, wegen e1000-Treiber - gibt's zwar für SCO, aber nur für SCO 5, was eine andere Netzwerkarchitektur als SCO 3 hat. Damit wird's nichts.

Also wieder Freund Google bemüht. Verschiedene erfolglose Treffer, aber bei einem Hersteller von AMD Lance-basierten Ethernetkarten tatsächlich fündig geworden - ein Treiberbundle, wo das zwar nicht draufstand, aber tatsächlich ein Treiber für SCO 5 und für SCO 3 drin war. Juhuu!

Die Installationsanleitung war auch, äh, interessant - ein Tarball, den man erstmal auspacken soll, und dann mit dem SCO-Tar (der ein wenig anders ist...) via tar cnv6 * auf (virtuelle) Diskette, dann mit custom installieren. Tja, wenn das mal so straightforward gewesen wäre - denn das SCO 3 hatte ja noch kein Netz, und das SCO 5 hat einen "tar", der Informationen über die directories mit speichert. Was den "tar" von SCO 3 zur Verzweiflung gebracht hat - weil er beim Auspacken den Directory-Eintrag von tmp/ gefunden hat, ein File namens tmp angelegt hat, und dann beim Auspacken des nächsten Files (tmp/perms/pnt.pre oder so) über das File namens tmp gestolpert ist...

Das hab' ich aber dann irgendwann hingebracht (unter SCO 3 mit "gtar" ausgepackt und mit dem
System-"tar" wieder eingepackt, dann waren nur noch Einträge für die Files da, nicht mehr für die Directory-Struktur).

SCO 3 wollte aber trotzdem nicht, weil custom auf /dev/install zugreift, was ein "autosense floppy device" ist, welches sich mit der virtuellen Floppy von VMware beisst. Nächster Versuch: custom -m /dev/fd0135ds18 - das ist wenigstens nicht mehr mit "tar: checksum error" gestorben, aber installiert hat es auch nicht - irgendein File hat gefehlt.

Eigentlich aber egal. So ein Installmedium besteht nur aus einem Tarball mit genau der Ziel-Verzeichnis-Struktur und ein paar Files in /tmp (Permissions, Pre-Install-Script, ...) - das kann man auch einfach von Hand draufballern.

Gesagt, getan, netconfig aufgerufen, pnt-Treiber ausgewählt (andere IP-Adresse konfiguriert, natürlich), und siehe da...



... es netzt (das sind die Bootmeldungen mit der erkannten Hardware, die Zeile mit %pnt und Ethernet ist die spannende).

X11?

Was jetzt nicht geht, ist X11. Das pack' ich evtl. noch an, wenn ich mal viel Zeit habe, aber es wird hochgradig knifflig...

... denn:

• VGA spezifiziert als Auflösungen nur 640x480 mit 16 Farben (kann XFree gar nicht) oder 320x200 mit 256 Farben (das funktioniert sogar, ist aber hinreichend sinnlos)
  
• wenn man aus einer "VGA"-Karte mehr rausholen will, muss man wissen, was das für ein Chipsatz ist und wie man da die Auflösungen umstellt
  
• VMware emuliert eine "generische" VGA-Karte, d.h. der XServer findet keinen "bekannten" Chipsatz
  
• XOrg in "aktuell" verwendet in diesem Fall einen VESA-Bios-Aufruf zur Umstellung der Auflösung und danach den generischen VGA-Treiber fürs Pixel-Schubsen - das tut, ist auch (dafür) ausreichend performant, aber...
  
• ... das kann "mein" XFree86 3.3.6 natürlich noch nicht, ich müsste also noch ein aktuelles XOrg portieren, und das setzt im Zweifelsfall Kernel-Infrastruktur voraus (fürs Vesa-Bios), die einfach nicht da ist.
  

Also wenn mal jemand langweilig ist, und er ganz dringend graue Haare braucht, schick' ich ihm meine VM...

(SCO 5 kann es übrigens, das bringt einen Vesa-VGA-Treiber mit - das ist zwar mit der emulierten Busmaus vom VMware nicht wirklich 100% glücklich, aber für die Dinge, wo man wirklich X11 braucht, reicht's)

Resumee

Sinnlos war's schon, aber es hat grossen Spass gemacht. Alte Unixe bringen manchmal eine Befriedigung, die so ein Vollkasko-Linux einfach nicht bringt - da tut's einfach "ab Werk" (im Zweifel), oder es haben schon 100 andere das Problem gehabt und Googlen bringt sofort die Lösung...