Handbuch:MIPS/Installation/Bootloader

MIPS Handbook
Installation
About the installation
Choosing the media
Configuring the network
Preparing the disks
Installing stage3
Installing base system
Configuring the kernel
Configuring the system
Installing tools
Configuring the bootloader
Finalizing
Working with Gentoo
Portage introduction
USE flags
Portage features
Initscript system
Environment variables
Working with Portage
Files and directories
Variables
Mixing software branches
Additional tools
Custom package repository
Advanced features
Network configuration
Getting started
Advanced configuration
Modular networking
Wireless
Adding functionality
Dynamic management

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

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

Filearc.cfBeispiel arc.cf

'"`UNIQ--pre-00000002-QINU`"'

This is a deprecated template. Help us update this template!

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.

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

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

Filedefault.coloCoLo Beispielkonfiguration

'"`UNIQ--pre-00000005-QINU`"'

This is a deprecated template. Help us update this template!

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

Filedefault.coloMenübasierte Konfiguration

'"`UNIQ--pre-00000008-QINU`"'

This is a deprecated template. Help us update this template!

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.

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

File/etc/inittabinittab Ausschnitt

'"`UNIQ--pre-0000000B-QINU`"'

This is a deprecated template. Help us update this template!

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.

File/etc/inittabinittab Beispielausschnitt

'"`UNIQ--pre-0000000E-QINU`"'

This is a deprecated template. Help us update this template!

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.

CodeMenü nach dem Booten

'"`UNIQ--pre-00000011-QINU`"'

This is a deprecated template. Help us update this template!

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

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

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

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

Neustart des Systems

Exit the chrooted environment and unmount all mounted partitions. Then type in that one magical command that initiates the final, true test: reboot.

root #exit

cdimage ~#cd

cdimage ~#umount -l /mnt/gentoo/dev{/shm,/pts,}

cdimage ~#umount -R /mnt/gentoo

cdimage ~#reboot

Vergessen Sie nicht die bootfähige CD zu entfernen, andernfalls könnte die CD anstelle des neuen Gentoo Systems erneut gebootet werden.

Nach dem Neustart in die neu installierte Gentoo Umgebung stellen sie Ihre Arbeit mit Abschluss der Gentoo Installation fertig.

← Installing tools Anfang Abschluss der Installation →