Bruce Ediger M@ail an den Autor Inhalt Einleitung Frühere Erfahrungen Das Projekt Die Kosten Zeitaufwand Literaturverweise

Linux auf einem Rechner mit Alpha CPU

Zusammenfassung:
Der Autor beschreibt den Aufbau eines Linuxsystemes auf einer Alpha PC Plattform, angefangen bei den Hardware Komponenten, bis hin zur Softwareinstallation.

Einleitung

Schon immer besaß ich Rechner, in denen kein Intel Prozessor werkelte und auch kein Betriebssystem von Microsoft installiert war. Angefangen bei einem Radio Shack Color Computer 3 im Jahre 1986, auf dem OS-9 lief, über einen AT&T 3b1 1988 und NeXT M68040 "black" Hardware 1991, bis hin zu einer Sun SPARCStation IPC im Jahre 1995. Während dieser ganzen Zeit hörte ich immer wieder von Leuten (sowohl im richtigen Leben, als auch im Newsnet), daß Wintel Hardware und Software vollkommen ausreichend und vorallem billger (wenn auch nicht ganz gleichwertig), als die "propritäre" Hardware auf meinem Küchentisch, wäre.

Im Zeitraum von Januar bis März 1997 baute ich mir einen Rechner mit einer Digital Equipment Corporation Alpha CPU zusammen und bekam ihn unter Linux zum Laufen. Auch wenn der DEC Computer, eine "Universal Desktop Box" (UDB), keinen Intel x86 basierten Prozessor bsaß, so kommt doch "einfach zu bekommende und dem Industriestandards folgende" PC Peripherie zum Einsatz. Ich konnte nun die Versprechungen über die Wintel "Industriestandard" Hardware in der Praxis überprüfen. Hier meine Erfahrung:

Es ist immernoch recht schwierig, wenn auch nicht mehr unmöglich, Rechner oder Rechnerkomponenten zu bekommen, die nicht von den Geschäften direkt geführt werden. Sowohl die großen Ladenketten, als auch die kleinen "Kistenschieber" wollen vorallem ihre Komplettsysteme verkaufen. Die Verkäufer und Berater in allen Geschäften sind für alles taub, was nicht ihre Komplettsysteme betrifft. Desweiteren sind die Preise der "PC kompatiblen" Peripherie gar nicht so niederig, wie Handel und Usenetter mir glauben machen wollten.

Frühere Freeware- und Hardware-Erfahrungen

Bevor der Leser sich meinen Bericht durchliest, sollte er sich im Klaren sein, daß ich nicht ganz unerfahren bezüglich der Materie bin. Ich habe die letzten 6 Jahre als Programmierer gearbeitet, vorallem unter verschiedenen Unix Umgebungen. Einer meiner Rechner (eine SPARCStation IPC) läuft mit einem anderen frei verfügbaren Unix Clon, NetBSD, so daß ich schon mit einigen möglichen Problemen dieser Betriebssysteme vertraut bin. Da die Rechner, die ich besitze, nicht gerade als "Standard" oder Mainstream Hardware bezeichnet werden können, übernehme ich selbst die Wartung und Erweiterung der Rechner.

Das Projekt

Ich erwarb eine der übriggebliebenen Digital Equipment Corporation VX40A-F2 Universal Desktop Box (UDB) von Starship/Computer Guys. Dies geschah über eine Online Auktion unter www.onsale.com. Obwohl ich die Objekte erhielt, für die ich bezahlt hatte, bin ich mir nicht so sicher, ob ich onsale.com empfehlen kann. Ich bekam bereits wiederholt Spam Mail, weil entweder Starship oder Onsale.com ihre Adressenliste an diese verdammten E-Mail Werbetypen weitergegeben haben.

Die UDB kam absolut nackt daher. Kein Speicher, keine Festplatten, weder Monitor noch Tastatur waren dabei. Was wohl mitkam, war eine Maus, RedHat Linux/Alpha 4.0 CD-Roms und eine Kurzanleitung.

Nachdem die UDB da war, kaufte ich die notwendigen Teile, welche sie zu einem funktionsfähigen Rechner machen sollte. Los ging es mit dem Speicher.

Ich kontaktierete einige Gebrauchthändler und "Kistenschieber" (Nur kaufen, keine Beratung) im Bereich von Denver, um 36-Pin, 70ns (oder schneller), Parity (richtige!) SIMMs zu bekommen. Alle nannten mir einen Preis. An einem Samstag fuhr ich dann los, um sie zu kaufen. In drei Läden passierte genau dies: Ich fragte nach dem Speicher, man schaute nach dem Preis und bat mich meinen Rechner in den Laden zu bringen, damit der Speicher installiert werden könnte. Daraufhin winkte ich mit dem DEC Handbuch und sagte, daß ich einfach nur den Speicher kaufen wollte und bereit wäre, auf meine Recht, defekten Speicher zurückzubringen, verzichten würde. Widerwillig verschwand daraufhin der Verkäufer in den hinteren Räumen, nur, um festzustellen, daß sie gerade keine SIMMs auf Lager hatten, die in die UDB paßten.

Schließlich kaufte ich die SIMMs, die ich brauchte, per Mail Order, von Memory Shippers in San Francisco, Kalifornien. Ich baute sie ein, ohne sie zu zerstören, allen Befürchtungen der Gebrauchthändler in Denver zum Trotz.

Bei Computer City, einem PC Großmarkt wollte ich dann eine "PS/2 kompatible" Tastatur kaufen. Bei den Gebrauchthändlern, die mir schon keine SIMMs verkaufen konnten (wollten??), war ich in Sachen Tastatur ebensowenig erfolgreich. Bei Computer City stieß ich auf einen beeindruckenden Bereich für Tastaturen, jede mit tollen Schlagworten versehen. Ich konnte zwei Schilder mit den Worten "PS/2 kompatibel" ausmachen, jedoch trugen alle Verpackungen dort nur die Aufschrift "nicht PS/2 kompatibel". Schließlich fand ich eine "PS/2 kompatible" Tastatur, trotz der fehlenden Hilfe der Computer City Verkäufer. Offensichtlich führt das Tragen eines pastellgelben Computer City Polohemd zu einem Absacken des IQs um 20 Punkten. Die Tastatur, die ich erwarb, lag im mittleren Preissegment. Die billigsten waren natürlich nur die "AT kompatiblen".

Ich fand heraus, daß die UDB einen "multi-sync" SVGA Monitor aufgrund ihrer eingebauten Grafikkarte benötigte. Natürlich war keiner meiner Monitore ein Multi-Sync Gerät. Während meiner Suche nach Speicher und einer Tastatur hatte ich mir deshalb schon Preise und Verfügbarkeit von Monitoren notiert.

Ich hatte mir 1996 eine 19 Zoll original Sun Microsystems Monitor über eine Newsgroup für 350 Dollar gekauft. Deswegen war ich recht schockiert, daß gebrauchte 17 Zoll Multi-Sync Monitore ab 450 Dollar und aufwärts zu haben waren. Neue Geräte bei den PC Großmärkten dagegen waren recht günstig.

Schließlich entschied ich mich, ein 14 oder 15 Zoll Gerät zu kaufen. Und wieder zog ich meine Runden, wie zuvor schon beim Speicherkauf. Nach einem Blick in das Lager wollte mir ein Gebrauchthändler den Monitor des Reparaturmenschen verticken. Ein andere Laden handelte nur mit Monitoren ab 17 Zoll. Das dritte Geschäft hatte nur einen Monitor einzeln zu verkaufen (neben den Komplettsystemen), einen Compaq "Presario 1410". Dieses Gerät war soetwas wie ein weißer Elefant, da die Lautsprecher nur mit einem Compaq Computer liefen (so oder ähnlich war die Ausrede). Da ich als langjähriger NeXT Besitzer und Benutzer das Fehlen von Sound gewohnt war, spielte dies jedoch keine rechte Rolle bei meiner Entscheidung.

Digital Equipment Corporation stellte die Produktion der UDB (auch bekannt als "Multia") Produktlinie irgendwann im Jahr 1996 ein, bietet aber die Hardware Service Manual via FTP zum Download an. Diese ist nicht so brauchbar, wie der Namen vermuten ließe, fehlen doch die Abbildungen, welche die Lage der Jumper darstellen, die das Verhalten der UDB beeinflußen. Glücklicherweise bietet RedHat öffentlichen Zugriff auf das Archiv der Mailing Liste und bietet auch eine Suchfunktion dafür an.

Mit der einfach getippten Dokumentation von "Starship Computer" (Die Firma, von der ich die UDB kaufte) und einer Reihe von Auszügen des DEC Service Manuals, der RedHat Mailing List und anderen WWW Seiten, konnte ich die UDB dazu bringen, über den MILO mini-loader zu booten. Das "SRM" Boot PROM wartet nicht auf den Monitor, deswegen läuft der Startvorgang teilweise blind ab. Danach konnte ich RedHat Linux 4.0 für Alpha auf einer Fujitsu M1606SAU SCSI Festplatte installieren. Ein Toshiba XM-3301TA CD-ROM Laufwerk, welches ich vorher dazu brachte, mit dem Sun SPARC Boot PROM zusammenzuarbeiten (dieses verlangt 512 Byte große Disksektoren), benutzte ich für die Installation von den RedHat CDs. Ich finde es recht interessant, daß Hardware und Software mit einem modifizierten, 5 Jahre alten CD Rom Laufwerk zusammenarbeiteten.

Ein Problem tauchte auf, als ich fdisk benutzen sollte, um eine MS-DOS Partitionstabelle zu erzeugen. Es fällt einem wirklich schwer zu glauben, daß Digitals Boot PROMs ein "FAT" Dateisystem benötigen, von dem sie aus booten, es ist aber in der Tat so. Ich fand auch heraus, daß die Partitionen an einer Zylindernummer beginnen müssen, die durch 4 teilbar ist.

Ein weiteres Problem war, daß die narrensichere Dokumentation von Starship Computers implizit davon ausging, daß sich die Festplatte unter SCSI Target 0 befindet. Meine langjährigen Erfahrungen mit dem Boot PROM von Sun ermöglichten es mir, die Stelle zu finden, an der der UDB PROM Code Target 0 erwartete.

Es brauchte zwei komplette Installationsvorgänge, bevor ich ein ausreichend funktionsfähiges Linux System hatte. Beim ersten Mal wählte ich nicht die richtigen Pakete aus. Ich dachte, es wäre erstmal das Wichtigste, das System zum Laufen zu kriegen. Dieses Installation netzwerkfähig zu machen sollte einfach sein. Es ist jedoch recht schwierig, das IP Netzwerk zu starten, wenn das ganze System nicht für den Start konfiguriert ist. Schlußendlich installierte ich ich das System neu, als "vernetzte Workstation".

Irgendwas scheint mit dem Linux Netzwerkcode nicht in Ordnung zu sein. Die Standardinstallation hängt während des Bootvorganges. Aber es gibt da noch eine weitere Sache: alle 3.5 Sekunden sendet der Linux/Alpha Kernel ein 46 Byte großes Paket an sich selbst. Der Ethernetrahmen hat als Ursprungs- und Zieladresse die MAC Adresse des Rechners. Möglicherweise ist das eine Art Herzschlag oder ein Test der Netzwerkverkabelung. Wie auch immer, es ist recht verwirrend.

Nachdem das System dazu gebracht worden war, von Festplatte zu booten, war der Rest der Konfiguration nicht allzu schwierig. Ich muß die RedHat Mailing Liste nach Hinweisen durchforsten, wie man den Startprozeß davon abhielt, stehenzubleiben. Desweiteren mußte ich mit der Konfigurationsdatei für XFree86 ein bischen herumtricksen. Einen 14 Zoll Monitor zu kaufen, war ein böser Fehler: alles ist so schrecklich klein!

Recht bald fand ich einen Fehler, der mit dem 64 Bit Alpha Prozessor zusammenhängt. Ich wollte die Uhren aller meiner Rechner synchron laufen haben und rdate schien ein recht billiger und einfacher Weg dazu zu sein. Ich benutzte es schon auf zwei anderen Rechnern und es schien einfacher zu sein, es zu kompilieren und laufen zu lassen, als Alternativen, wie NTP (Ich habe in der Vergangenheit schon NTP eingerichtet und administriert...).

rdate von den NetBSD 1.1 Quelltexten zu kompilieren war recht einfach. Es bestand jedoch darauf, mir mitzuteilen, daß das Datum auf den anderen Rechnern (SPARC IPC und M68040 NeXT) irgendwo um 1861 lag. Es stellte sich heraus, daß es sich hier um ein spezielles "Feature" der Vorzeichenerweiterung der Alpha CPU handelte: das rdate Protokoll verwendet einen 32 Bit Wert, in Network Byte Order und 2er Komplement Darstellung, welcher die Anzahl der Sekunden angibt, die seit dem 1. Januar, 1900 12:00 mittags vergangen sind. Der rdate Code benutzt die Bibliotheksroutine ntohl(), um diesen Wert in die rechnereigene Darstellung (ausgehend von der Network Byte Order) zu bringen. Wenn dieser 32 Bit Wert in eines der 64 Bit breiten Register der Alpha CPU geladen wird, werden die restlichen Bitpositionen mit dem 32. Bit (dem Vorzeichenbit, wenn es sich um einen vorzeichebehafteten Wert handelt) gefüllt, wodurch im Falle einer 1 der Registerwert negativ wurde.

Die Kosten

Zeitaufwand

Ich schätze, daß das ganze Projekt ungefähr 35 bis 40 Arbeitsstunden benötigte, über einen Zeitraum von 3 Monaten verteilt. In einer ("von 9 bis 5") Betriebsumgebung dürfte die ganze Aktion ungefähr die doppelte Stundenzahl konsumieren. Zum Hause kann man ja zum Beispiel den Installationsprozeß starten und dann etwas anderes tun, wie etwa Abendessen kochen, wohingegen in einer betrieblichen Umgebung man an die jeweilige Aufgabe gebunden ist.

Literaturverweise

• Das Archiv der Red Hat Alpha Mailing List
• Die Alpha Mailing Liste durchsuchen
• Linux/Alpha FAQ
• UDB Hardware Informationen
• weitere UDB Hardware Informationen
• ein persönliches Urteil
• Das Kochbuch für Alpha Compiler
• Digital Technical Journal Band 4, Nummer 4: Spezielle Aspekte der Alpha Architektur

Weitere Verweise:

• Weswegen man Microsoft boykottieren sollte
• E-Mail mit Kommentaren an mich