From: Christian Weisgerber (naddy_at_mips.rhein-neckar.de)
Date: 19. Apr 2000
Eigentlich wollten wir nur rasch gnocchi neu installieren.
gnocchi ist eine Alpha, die bei der Unix-AG etwas vernachlässigt
im Eck steht. Trotz des Stichworts »Alpha« ist Ehrfurcht hier nicht
angebracht. Die Büchse ist betagt, eine AXPpci33, mit die langsamste
Alpha überhaupt, auch wenn wir die 233MHz-Version mit 1MB Second-Level-
Cache haben. Liegt etwa im Bereich eines i486 (int) bis i586 (float).
Zuletzt lief Red Hat 6.0 darauf, was nun auch nicht mehr ganz frisch
ist. Wir wollten Mandrake 7.0 ausprobieren. In der Praxis dient
der Rechner hauptsächlich als X11-Display (Matrox Millennium und
19-Zoll-Monitor).
Irgendwann einmal hatte jemand die Konsolenfirmware durch eine
mittlerweile entsetzlich antike Version von MILO ersetzt. Erster
Schritt daher: Es muss wieder eine vernünftige SRM-Konsole ins
Flash. Die kann man bei ftp.digital.com saugen. Nur, wie bekommt
man sie jetzt in die Maschine? Eine SRM- oder ARC-Konsole um das
Flashprogramm auszuführen ist ja nicht vorhanden. Also fwupdate.exe
auf eine Diskette mit MS-DOS-Filesystem kopiert. Kann MILO das mit
»run fd0:fwupdate.exe« ausführen? Natürlich nicht. Jemand meinte
auch, dass dieser MILO eh nicht richtig auf die Floppy zugreifen
könne. Danke.
Apropos Floppy: Das Formatieren von Disketten, das anschließende
Beschreiben, und letztlich das Lesen, alles ohne Fehler, erwies
sich wieder als ein Trauerspiel. Selbst mit einer Handvoll Disketten
war das nicht zuverlässig möglich. Ganz so extrem ist das sonst
nicht, vielleicht hat das Diskettenlaufwerk in der Maschine einen
Schlag weg.
Da ich irgendwann einmal das Handbuch der AXPpci33 gelesen hatte,
ist mir wieder eingefallen, dass es einen Jumper gibt, um einen
Notbootstrap zu aktivieren, mit dem man von Diskette booten kann.
Das hat sich auch im Handbuch wiedergefunden, das glücklicherweise
den Wegwerfaktionen bestimmter Leute entgangen war. (Müsste aber
auch online verfügbar sein.) Was genau gebootet werden kann, steht
da nicht. Vielleicht eine Diskette, wie sie SRM booten könnte?
Um sowas zu erstellen braucht man ein Programm namens mkbootfirm.
Das gibt es, als Digital-UNIX-Executable, dort, wo es die Firmware
gibt. Also gezogen und gehofft, dass es mit der Digital-UNIX-
Binärkompatibilität von Linux/alpha läuft. Auch noch dynamisch
gelinkt. Zum Glück haben wir die DU-Libs schon wegen Netscape.
mkbootfirm läuft, Diskette nach x Anläufen erstellt.
Kiste aufgemacht, Jumper umgesteckt. Bei der Gelegenheit mal
überhaupt wieder reingeschaut. Eine 3Com Etherlink XL (10M, Combo)?
Darüber kann SRM bestimmt nicht booten. Zufällig war aus einem
anderen Rechner, den wir parallel auf 100Base-TX hochgerüstet haben,
gerade eine DEC-21040-»Tulip«-Karte (10M, Combo) rausgefallen.
Original Digital DE435. War wohl die ursprüngliche Netzkarte der
Alpha, die dann durch diverse AG-Rechner gewandert ist. Komm heim
zu Mama.
Erfolg! Mit der Notfirmware wird die Diskette tatsächlich gebootet
und ins SRM geflasht. Zurückgejumpert, Neustart, und etwas zögerlich
aber dann bestimmt kommt uns der charakteristische SRM-Prompt »>>>«
entgegen. Erste Erkenntnis: Diese SRM-Version, anno 1996, kennt
noch kein »help«. Aber ftp.digital.com hat eine Anleitung.
Durchaus schön, SRM. Die DE435 wird auch prompt als ewa0 erkannt.
Faszinierende Devicenamen. dva0 ist die Floppy, dka0 die SCSI-
Platte. »boot ewa0«... Er probierts mit MOP. Das stellen wir doch
rasch auf BOOTP um, und vorsichtshalber den os_type von VMS auf
UNIX.
Habe ich schon erwähnt, dass gnocchi kein CD-ROM-Laufwerk hat?
Einen BOOTP-Server gibts in der AG nicht, und zu versuchen sowas
einzurichten und darüber zu booten, das wollten wir uns zu diesem
Zeitpunkt nicht antun. Also von der Mandrake-CD das Image für eine
Netzinstallation auf Diskette gezogen. »boot dva0 -fl 0«... bootbar...
bootet... Lesefehler. Neuer Versuch, neues Glück. Jetzt kommt schon
der Kernel hoch, aber dann erwischt ihn ein Lesefehler im Ramdisk-Image.
So wird das nix.
In der AG schimmeln doch noch ein paar alte CD-Laufwerke rum. Mal
umschauen. Bingo. Ein Toshiba 3401B, SCSI, für diese verdammten
Caddies wie eigentlich alle Laufwerke in der AG, ×2 oder so. Auf
was für eine ID stellen wir es denn? Oh, alle Jumper abgezogen.
Danke. Jumper sind Mangelware in der AG. Aber zum Glück stehen auf
dem Flur ja gerade ein paar defekte Terminals für den Schrott.
Eines geknackt, und tatsächlich zwei passende Jumper auf der Platine
gefunden, um das Laufwerk auf ID 4 und Parity zu stellen. Oh Wunder,
es ist noch ein freier Stecker an SCSI- und Stromkabel da. Jetzt
nur noch rasch eingebaut. Warum ich wohl einen Leatherman habe? In
der Schraubensammlung werden die M3 knapp.
SRM erkennt das Laufwerk völlig intuitiv als Device dka400. Mandrake
rein, gebootet, klappt. Na wunderbar. Ja, ja, OK. Was kommt jetzt?
Dinge, die die Welt nicht braucht. Ein grafisches Installationswerkzeug.
Schön. Knall! Tja, da terminiert es abnormal mit einem Signal 4
(SIGILL). Wirklich, ein *funktionierendes* Installationsprogramm
wäre uns lieber gewesen, auch ganz ohne Grafik.
Allgemeine Ratlosigkeit. Am Installationsprogramm kommt man nicht
vorbei. Dann also doch Red Hat 6.2, obwohl uns 6.0 nicht gerade
gefallen hat. Saugen wir rasch (~40min) ein ISO-Image aus Bayreuth.
Inzwischen schreiben wir Chmouel eine Bugmeldung. Image ist da,
gebrannt.
Äh, wie bootet man das jetzt? Im README steht man soll auf der
Website schauen. Dort was finden? Suchen, stochern, iterative
Näherung durch Probieren. »boot dka400 -fi kernels/generic.gz -fl
"root=/dev/scd0"« funktioniert dann endlich. Ein vertrauter Red-Hat-
Installations-Bildschirm. OK, OK. Was ist das? Schon wieder eine
grafische Installation? Dinge, die die Welt nicht braucht. Knall!
Diesmal kommen uns sogar anhaltende Registerdumps aus den Tiefen
von SRM entgegen. Es wäre lustig, wenn es nicht so traurig wäre.
Zum Glück ist jemand da, der schon öfters Red Hat auf anderen
Plattformen installiert hat. »Nehmt doch die Textinstallation.«
Wie? »boot: text« finden wir irgendwo. Äh? Versuchen wir »... -fl
"root=/dev/scd0 text"«. Ja, da ist die bekannte Red-Hat-Text-
installation.
Partitionierung. Mit SRM brauchen wir jetzt ein BSD-Disklabel, die
alte PC-Partitionierung kann nicht übernommen werden. Nix Diskdruid,
wir wollen fdisk, dort »b«. Geht doch. Wie lasse ich jetzt ein
Stück am Anfang der Platte für den Bootstrap frei? Im Gegensatz zu
»disklabel -e« auf einer BSD-Maschine kann man die Offsets nicht
direkt editieren sondern nur Zylinder von/bis angeben. Hmpf. Einen
ganzen Zylinder, 4MB, nur für den Bootstrap? Oder an der Zylinder/
Kopf/Sektoren-Übersetzung drehen. Besser nicht, wissen die Götter,
was das für Konsequenzen hat. 4MB können wir entbehren.
Der Kollege macht sich über die Paketauswahl her. Die Red-Hat-Leute
sind gestört. Berge von Gnome-Kram ab-, essentielle Netzwerkzeuge
anwählen. Make it so. 40 Minuten lang werden Pakete von CD geladen.
Gleich sind wir fertig... ja!... nein. Den Fehlermeldungen beim
Abschmieren nach ist das Installationsprogramm in Python geschrieben.
Oh Mann. Okay, wieder CD booten, Installation durchgehen, nehmen
wir irgendeine voreingestellte Paketauswahl. Wenn er das packt,
müssen wir halt manuell nachinstallieren. Wenn nicht, tja. Debian?
FreeBSD? Lassen wir es einfach über Nacht laufen und schauen am
nächsten Morgen was Sache ist. Sechs Stunden sind genug.
Und dann sind wir erst einmal nach Hause gegangen.
-- Christian "naddy" Weisgerber naddy_at_mips.rhein-neckar.de
Dieses Archiv wurde generiert von hypermail 2.1.2 : 11. Mar 2002 CET