Handbuch:MIPS/Blöcke/Bootloader

From Gentoo Wiki
Jump to:navigation Jump to:search
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 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
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 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.

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

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

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.

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

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.

CODE Menü nach dem Booten
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

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.

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.

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]


Retrieved from "https://wiki.gentoo.org/index.php?title=Handbook:MIPS/Blocks/Bootloader/de&oldid=760591"