Handbuch:MIPS/Blöcke/Bootloader

This page is a translated version of the page Handbook:MIPS/Blocks/Bootloader and the translation is 100% complete.

arcload für Silicon Graphics Maschinen

arcload wurde für Maschinen geschrieben, die 64-Bit-Kernel benötigen und daher arcboot nicht verwenden können (das nicht ohne weiteres als 64-Bit-Binärdatei kompiliert werden kann). Es umgeht auch die Besonderheiten, die beim Laden von Kernel direkt aus dem Volume-Header auftreten. Um mit der Installation fortzufahren, beginnen Sie mit:

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

Hinweis
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.

DATEI arc.cfBeispiel arc.cf

# ARCLoad Konfiguration
  
# Einige Standardeinstellungen...
append  "root=/dev/sda5";
append  "ro";
append  "console=ttyS0,9600";
  
# Die Hauptdefinition. ip28 kann geändert werden, wenn Sie dies wünschen
ip28 {
        # Definition für einen "funktionierenden" Kernel
        # Wählen Sie dies durch die Einstellung von OSLoadFilename="ip28(working)"
        working {
                description     "SGI Indigo2 Impact R10000\n\r";
                image system    "/working";
        }
  
        # Definition für einen "neuen" Kernel
        # Wählen Sie dies durch die Einstellung von OSLoadFilename="ip28(new)"
        new {
                description     "SGI Indigo2 Impact R10000 - Testing Kernel\n\r";
                image system    "/new";
        }
  
        # Zur Fehlersuche in einem Kernel
        # Wählen Sie dies durch die Einstellung von OSLoadFilename="ip28(working,debug)"
        # oder 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.

Hinweis
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.

Warnung
Wenn Sie möchten, können diese in den Server geflasht werden, um die Original-Firmware vollständig zu ersetzen - allerdings sind Sie bei diesem Unterfangen völlig auf sich allein gestellt. Sollte etwas schief gehen, entfernen Sie das BOOTROM und programmieren Sie es mit der Standard-Firmware neu. Wenn sich das beängstigend anhört - dann flashen Sie die Maschine NICHT. Gentoo übernimmt keine Verantwortung für das, was passiert, wenn dieser Ratschlag ignoriert wird.

Nun zur Installation von CoLo. Beginnen Sie damit, das Paket zu emergen:

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)

Beginnen Sie mit dem Einhängen 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.

Hinweis
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.

DATEI default.coloCoLo Beispielkonfiguration

#:CoLo:#
mount hda1
load /kernel.gz.working
execute root=/dev/sda5 ro console=ttyS0,115200

Hinweis
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.

DATEI default.coloMenü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.

Hinweis
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:

DATEI /etc/inittabinittab 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

Entkommentieren Sie zunächst die c0 Zeile. Standardmäßig ist sie auf eine Terminal-Baudrate von 9600 bps eingestellt. Auf Cobalt-Servern kann dies auf 115200 geändert werden, um der vom BOOTROM festgelegten Baudrate zu entsprechen. Dieser Abschnitt sieht dann folgendermaßen aus. Auf einer Headless-Maschine (z.B. Cobalt-Servern) ist es auch empfehlenswert die lokalen Terminalzeilen (c1 bis c6) auszukommentieren, da diese die Angewohnheit haben, sich falsch zu verhalten, wenn sie /dev/ttyX nicht öffnen können.

DATEI /etc/inittabinittab 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

Als letztes... teilen Sie dem System mit, dass der lokalen seriellen Schnittstelle als sicheres Terminal vertraut werden kann. Die zu ändernde Datei ist /etc/securetty. Sie enthält eine Liste von Terminals, denen das System vertraut. Fügen Sie einfach zwei weitere Zeilen ein, die es erlauben, die serielle Leitung für Root-Anmeldungen zu verwenden.

root #echo 'ttyS0' >> /etc/securetty

Neuerdings nennt Linux dies auch /dev/tts/0 -- fügen Sie also auch dies hinzu:

root #echo 'tts/0' >> /etc/securetty

SGI PROM Anpassung

Allgemeine PROM Einstellungen

Wenn der Bootloader installiert ist, gehen Sie nach dem Neustart (der in Kürze erfolgen wird) zum Systemwartungsmenü und wählen Sie Enter auf Command Monitor (5), ähnlich wie beim ersten Neustart des Systems.

CODE Menü nach dem Booten

1&#41; Start System
2&#41; Install System Software
3&#41; Run Diagnostics
4&#41; Recover System
5&#41; 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

Hinweis
Dies wird hier der Vollständigkeit halber abgedeckt. Wir empfehlen stattdessen, dass sich der Benutzer die Installation von arcload ansieht.

Hinweis
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.

In der obigen Beispieldatei ist ein Systemblock definiert, ip28 mit den Optionen working, new und debug. Als nächstes werden die PROM-Variablen definiert:

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.

Hinweis
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]