Handbuch:MIPS/Blöcke/Bootloader
arcload für Silicon Graphics Maschinen
arcload
wurde für Maschinen geschrieben die einen 64-Bit Kernel benötigen und deshalb nicht arcboot
verwenden können (welches nicht einfach als 64-Bit Binärdatei kompiliert werden kann). Es kommt auch mit Besonderheiten zurecht die entstehen, wenn man einen Kernel direkt aus dem Volume-Header lädt. Fahren wir mit der Installation fort:
root #
emerge arcload dvhtool
Wenn das abgeschlossen ist, finden Sie die arcload
Binärdatei in /usr/lib/arcload/. Es gibt zwei Dateien:
- sashARCS: Die 32-Bit Binärdatei für Indy, Indigo2 (R4k), Challenge S und O2 Systeme
- sash64: Die 64-Bit Binärdatei für Octane/Octane2, Origin 200/2000 und Indigo2 Impact Systeme
Verwenden Sie dvhtool
um die für das System geeignete Binärdatei in den Volume-Header zu installieren:
Für Indy/Indigo2/Challenge S/O2 Benutzer:
root #
dvhtool --unix-to-vh /usr/lib/arcload/sashARCS sashARCS
Für Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000 Benutzer:
root #
dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64
Der Name sashARCS oder sash64 muss nicht unbedingt verwendet werden, es sei denn Sie installieren auf den Volume-Header einer bootfähigen CD. Zum normalen Booten von der Festplatte, kann es beliebig benannt werden.
Verwenden Sie jetzt einfach dvhtool
um zu prüfen, dass sie sich im Volume-Header befindet:
root #
dvhtool --print-volume-directory
----- directory entries ----- Entry #0, name "sash64", start 4, bytes 55859
Die Datei arc.cf hat eine C-ähnliche Syntax. Für vollständige Details wie man sie konfiguriert, schauen Sie sich bitte die arcload Seite im Linux/MIPS Wiki an. Die Kurzfassung: Definieren Sie mit Hilfe der OSLoadFilename
Variable eine Reihe von Optionen die beim Booten aktiviert und deaktiviert werden.
arc.cf
Beispiel arc.cf# ARCLoad Configuration # Some default settings... append "root=/dev/sda5"; append "ro"; append "console=ttyS0,9600"; # Our main definition. ip28 may be changed if you wish. ip28 { # Definition for a "working" kernel # Select this by setting OSLoadFilename="ip28(working)" working { description "SGI Indigo2 Impact R10000\n\r"; image system "/working"; } # Definition for a "new" kernel # Select this by setting OSLoadFilename="ip28(new)" new { description "SGI Indigo2 Impact R10000 - Testing Kernel\n\r"; image system "/new"; } # For debugging a kernel # Select this by setting OSLoadFilename="ip28(working,debug)" # or OSLoadFilename="ip28(new,debug)" debug { description "Debug console"; append "init=/bin/bash"; } }
Beginnend mit arcload-0.5 können arc.cf und Kernel entweder im Volume-Header oder auf einer Partition gespeichert sein. Um diese neue Eigenschaft zu nutzen, können Sie die Dateien in der /boot/ Partition ablegen (oder / wenn es keine extra Boot Partition gibt). arcload verwendet den Dateisystemtreiber-Code des beliebten grub Bootloader und unterstützt somit den gleichen Umfang an Dateisystemen.
root #
dvhtool --unix-to-vh arc.cf arc.cf
root #
dvhtool --unix-to-vh /usr/src/linux/vmlinux new
CoLo für Cobalt MicroServer
CoLo installieren
Cobalt Server haben eine viel weniger leistungsfähige Firmware auf dem Chip installiert. Das Cobalt BOOTROM ist im Vergleich zum SGI PROM primitiv und weist eine Reihe erheblicher Limitierungen auf.
- Es besteht eine (ungefähr) 675 KB Größenlimitierung des Kernels. Die aktuelle Größe von Linux 2.4 macht es nahezu unmöglich einen Kernel dieser Größe zu erzeugen. Linux 2.6 und 3.x stehen vollkommen außer Frage.
- 64-Bit Kernel werden von der Original-Firmware nicht unterstützt (obwohl diese momentan sehr experimentell auf Cobalt Maschinen sind)
- Die Shell ist im günstigsten Fall rudimentär
Um diese Limitierungen zu überwinden wurde eine alternative Firmware genannt CoLo (Cobalt Loader) entwickelt. Dies ist ein BOOTROM Abbild das entweder auf den Chip im Cobalt Server geflasht, oder von der existierenden Firmware geladen werden kann.
Dieses Handbuch wird durch die Einrichtung von CoLo führen, damit es durch die Original-Firmware geladen wird. Dies ist der einzig wirklich sichere und empfohlene Weg um CoLo einzurichten.
Wenn gewünscht kann dies in den Server geflasht werden um die Original-Firmware vollkommen zu ersetzen -- Sie sind in dieser Bestrebung jedoch völlig auf sich alleine gestellt. Falls etwas schief läuft entfernen sie das BOOTROM physikalisch und flashen Sie es erneut mit der Original-Firmware. Wenn das für Sie abschreckend klingt, flashen Sie die Maschine NICHT. Wir übernehmen keinerlei Verantwortung für das was passieren kann, wenn Sie diesen Ratschlag ignorieren.
Lassen Sie uns mit der Installation von CoLo weitermachen. Zuerst emerge
n Sie das Paket.
root #
emerge --ask sys-boot/colo
Nach der Installation werfen Sie einen Blick in das Verzeichnis /usr/lib/colo/. Hier liegen die folgenden zwei Dateien:
- colo-chain.elf (der "Kernel" der von der Original-Firmware geladen wird)
- colo-rom-image.bin (ein ROM Abbild zum Flashen auf das BOOTROM)
Wir beginnen mit dem Mounten von /boot/ und dem Ablegen einer komprimierten Kopie von colo-chain.elf in /boot/, wo das System es erwartet.
root #
gzip -9vc /usr/lib/colo/colo-chain.elf > /boot/vmlinux.gz
CoLo konfigurieren
Wenn das System bootet wird es CoLo laden, welches ein Menü auf dem LCD ausspuckt. Die erste Option (und die Voreinstellung, die nach ca. 5 Sekunden übernommen wird) ist das Booten von der Festplatte. Das System versucht dann die erste Linux Partition die es findet zu mounten und anschließend das Script default.colo zu starten. Die Syntax ist vollständig in der CoLo Dokumentation beschrieben (werfen Sie einen Blick auf /usr/share/doc/colo-X.YY/README.shell.gz -- wobei X.YY die installierte Versionsnummer ist) und sehr einfach.
Nur ein Tipp: Bei der Installation eines Kernels ist es empfehlenswert zwei Kernel-Abbilder zu erzeugen: kernel.gz.working -- ein bekanntermaßen funktionierender Kernel und kernel.gz.new -- der Kernel der gerade kompiliert wurde. Es ist möglich symbolische Links zu nutzen, um auf die aktuellen "...new" und "...working" Kernel zu verweisen. Oder benennen Sie die Kernel-Abbilder einfach entsprechend um.
default.colo
CoLo Beispielkonfiguration#:CoLo:# mount hda1 load /kernel.gz.working execute root=/dev/sda5 ro console=ttyS0,115200
CoLo verweigert das Laden eines Skriptes, das nicht mit der Zeile
#:CoLo:#
beginnt. Sie können es als Äquivalent von #!/bin/sh
in Shell Skripten ansehen.Es ist ebenfalls möglich eine Farge nach dem zu bootenden Kernel und der Konfiguration mit einem Standard-Timeout zu stellen. Die nachfolgende Konfiguration tut genau dies: Die fragt den Benutzer welchen Kernel er verwenden möchte und führt das ausgewählte Abbild aus. vmlinux.gz.new und vmlinux.gz.working können entweder die eigentlichen Kernel-Abbilder, oder lediglich symbolische Links die auf Kernel-Abbilder auf dieser Festplatte verweisen sein. Das Argument 50
von select
gibt an, dass mit der ersten Option ("Working") nach 50/10 Sekunden fortgefahren werden soll.
default.colo
Menübasierte Konfiguration#:CoLo:# lcd "Mounting hda1" mount hda1 select "Which Kernel?" 50 Working New goto {menu-option} var image-name vmlinux.gz.working goto 3f @var image-name vmlinux.gz.working goto 2f @var image-name vmlinux.gz.new @lcd "Loading Linux" {image-name} load /{image-name} lcd "Booting..." execute root=/dev/sda5 ro console=ttyS0,115200 boot
Für mehr Informationen sehen Sie sich bitte die Dokumentation unter /usr/share/doc/colo-VERSION an.
Serielle Konsole einrichten
Die Linux Installation so wie sie jetzt ist würde booten aber voraussetzen, dass der Benutzer an einem physischen Terminal eingeloggt ist. Auf Cobalt Maschinen ist das besonders schlecht -- es gibt so etwas wie ein physisches Terminal nicht.
Diejenigen die den Luxus eines unterstützten Video-Chipsatz haben, können wenn sie möchten diesen Abschnitt überspringen.
Öffnen Sie als erstes die Datei /etc/inittab mit einem Editor. Etwas weiter unten in der Datei betrachten Sie folgendes:
/etc/inittab
inittab Ausschnitt# SERIAL CONSOLE #c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102 # TERMINALS c1:12345:respawn:/sbin/agetty 38400 tty1 linux c2:12345:respawn:/sbin/agetty 38400 tty2 linux c3:12345:respawn:/sbin/agetty 38400 tty3 linux c4:12345:respawn:/sbin/agetty 38400 tty4 linux c5:12345:respawn:/sbin/agetty 38400 tty5 linux c6:12345:respawn:/sbin/agetty 38400 tty6 linux # What to do at the "Three Finger Salute". ca:12345:ctrlaltdel:/sbin/shutdown -r now
Entfernen Sie das Kommentarzeichen ("#") der Zeile c0
. Als Standard ist sie darauf eingestellt eine Terminal-Baudrate von 9600 bps zu nutzen. Auf Cobalt Servern kann dies auf 115200 bps eingestellt werden, um der Baudrate die vom BOOT ROM festgesetzt ist zu entsprechen. Das folgende Listing zeigt wie der Abschnitt anschließend aussieht. Auf Bildschirmlosen Systemen (z.B. Cobalt Servern) empfehlen wir ebenfalls die Zeilen der lokalen Terminals (c1
bis c6
) auszukommentieren, da diese die Angewohnheit haben sich schlecht zu verhalten, wenn sie /dev/ttyX nicht öffnen können.
/etc/inittab
inittab Beispielausschnitt# SERIAL CONSOLE c0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102 # TERMINALS -- These are useless on a headless qube #c1:12345:respawn:/sbin/agetty 38400 tty1 linux #c2:12345:respawn:/sbin/agetty 38400 tty2 linux #c3:12345:respawn:/sbin/agetty 38400 tty3 linux #c4:12345:respawn:/sbin/agetty 38400 tty4 linux #c5:12345:respawn:/sbin/agetty 38400 tty5 linux #c6:12345:respawn:/sbin/agetty 38400 tty6 linux
Nun müssen wir dem System mitteilen, dass dem lokalen seriellen Anschluss als sicherem Terminal vertraut werden kann. Die Datei die wir dazu ändern müssen ist /etc/securetty. Sie enthält eine Liste von Terminals denen das System vertraut. Wir fügen einfach zwei weitere Zeilen hinzu, die der seriellen Verbindung Root-Logins gestatten.
root #
echo 'ttyS0' >> /etc/securetty
In letzter Zeit benötigt Linux ebenfalls /dev/tts/0 -- deshalb fügen wir dies auch hinzu:
root #
echo 'tts/0' >> /etc/securetty
SGI PROM Anpassung
Allgemeine PROM Einstellungen
Mit installiertem Bootloader, nach dem Neustart (zu dem wir in Kürze kommen), begeben Sie sich in das System Maintenance Menu und wählen Enter Command Monitor (5) so wie anfangs beim Netzboot des Systems.
1) Start System 2) Install System Software 3) Run Diagnostics 4) Recover System 5) Enter Command Monitor
Geben Sie den Speicherort des Volume-Header an:
>>
setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)
Automatisch Gentoo booten:
>>
setenv AutoLoad Yes
Die Zeitzone setzen:
>>
setenv TimeZone EST5EDT
Verwenden Sie die serielle Konsole - Benutzer von Grafikkarten sollten "g" anstelle von "d1" (eins) angeben:
>>
setenv console d1
Stellen Sie die Baudrate der seriellen Konsole ein. Dies ist optional. Die Standardeinstellung ist 9600, wenngleich man Datenraten bis zu 38400 verwenden kann, falls gewünscht:
>>
setenv dbaud 9600
Die nächsten Einstellungen hängen davon ab, wie das System gebootet wird.
Einstellungen für direktes booten vom Volume-Header
Dies wird hier der Vollständigkeit halber abgedeckt. Wir empfehlen stattdessen, dass sich der Benutzer die Installation von arcload ansieht.
Dies funktioniert nur auf Indy, Indigo2 (R4k) und Challenge S.
Ersetzen Sie <root device>
durch die Root Partition von Gentoo, wie beispielsweise /dev/sda3:
>>
setenv OSLoadPartition <root device>
Um die verfügbaren Kernel aufzulisten geben sie "ls" ein.
>>
setenv OSLoader <kernel name>
>>
setenv OSLoadFilename <kernel name>
Legen die zu übergebenden Kernel-Parameter fest:
>>
setenv OSLoadOptions <kernel parameters>
Um einen Kernel zu versuchen ohne mit den Kernel-Parametern herumzuhantieren, verwenden Sie den boot -f
PROM Befehl:
root #
boot -f new root=/dev/sda5 ro
arcload Einstellungen
arcload verwendet die Option OSLoadFilename
um festzulegen welche Optionen von arc.cf eingestellt werden. Die Konfigurationsdatei ist im Grunde ein Skript, das Boot-Abbilder auf der obersten Ebene für verschiedene Systeme definiert und innerhalb von diesen optionale Einstellungen. Somit zieht OSLoadFilename=mysys(serial) die Einstellungen für den mysys block herein und stellt weitere in serial überschriebene Optionen ein.
Im der Beispieldatei oben haben wir einen System-Block ip28
definiert, mit den Optionen working
, new
und debug
. Wir definieren unsere PROM Variablen wie folgt:
Wählen Sie arcload als Bootloader:- sash64
oder sashARCS
:
>>
setenv OSLoader sash64
Verwenden Sie das "working" Kernel-Abbild, das im "ip28" Abschnitt von arc.cf definiert ist:
>>
setenv OSLoadFilename ip28(working)
Beginnend mit arcload-0.5 müssen Dateien nicht länger im Volume-Header plaziert sein -- sie können statt dessen in einer Partition liegen. Um arcload mitzuteilen wo es nach seiner Konfigurationsdatei und Kernels suchen soll, müssen Sie die PROM Variable OSLoadPartition
setzen. Der hier genau anzugebende Wert hängt davon ab, wo die Festplatte auf dem SCSI Bus liegt. Verwenden Sie die PROM Variable SystemPartition
als Vorlage -- nur die Partitionsnummer sollte geändert werden müssen.
Partitionen sind durchnummeriert beginnend mit 0, nicht 1 wie bei Linux.
Um vom Volume-Header zu laden, verwenden Sie Partition 8:
>>
setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(8)
Andernfalls geben Sie die Partition und den Dateisystemtyp an:
>>
setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(0)[ext2]