path: root/de/boot-installer/arm.xml

<!-- retain these comments for translator revision tracking -->
<!-- original version: 69818 -->

  <sect2 arch="armhf;armel" id="boot-image-formats">
    <title>Boot-Image-Formate</title>
    <para>
      Auf ARM-basierten Systemen wird in den meisten Fällen eines
      dieser beiden Formate für die Boot-Images verwendet: a)
      Standard-Linux-Kernel im zImage-Format (<quote>vmlinuz</quote>)
      zusammen mit einer Standard-Linux-Initial-Ramdisk
      (<quote>initrd.gz</quote>) oder b) Kernel im uImage-Format
      (<quote>uImage</quote>) zusammen mit dazu zugehöriger
      Initial-Ramdisk (<quote>uInitrd</quote>).
    </para>
    <para>
      uImage/uInitrd sind Image-Formate, die für die U-Boot-Firmware
      ausgelegt wurden, welche auf vielen ARM-basierten Systemen
      eingesetzt ist. Ältere U-Boot-Versionen können nur Dateien
      im uImage-/uInitrd-Format booten, daher werden diese Formate oft
      auf älteren armel-Systemen genutzt. Neuere U-Boot-Versionen können -
      neben uImage/uInitrd - auch Standard-Linux-Kernel- und Ramdisk-Images
      booten, aber die Befehlssyntax dafür ist etwas anders als beim
      Booten von uImages.
    </para>
    <para>
      Für Systeme, die einen Multiplattform-Kernel verwenden, ist
      zusätzlich zu Kernel- und Initial-Ramdisk-Image noch eine
      sogenannte Gerätebaum-Datei (auch Gerätebaum-Abbild /
      device-tree blob, <quote>dtb</quote>) erforderlich. Diese ist
      spezifisch für jedes unterstützte System und enthält eine
      Beschreibung der jeweiligen Hardware. Das dtb sollte eigentlich
      auf dem Gerät von der Firmware bereitgestellt werden, aber in der
      Praxis muss oft ein neueres geladen werden.
    </para>
  </sect2>

  <sect2 arch="armhf" id="armhf-console-setup">
    <title>Konfiguration der Konsole</title>
    <para>
      Das netboot-Tarball-Archiv (<xref
      linkend="boot-armhf-netboot.tar.gz"/>) und die SD-Karten-Images
      des Installers (<xref linkend="boot-installer-sd-image"/>) 
      nutzen die (plattform-spezifische) Standardkonsole, die von
      U-Boot in der Variable <quote>console</quote> definiert wird.
      In den meisten Fällen ist das eine serielle Konsole, daher
      benötigen Sie auf diesen Plattformen standardmäßig ein
      serielles Konsolenkabel, um den Installer nutzen zu können.
    </para>
    <para>
      Auf Plattformen, die auch eine Video-Konsole unterstützen,
      können Sie die <quote>console</quote>-Variable von U-Boot
      entsprechend anpassen, wenn Sie möchten, dass der Installer
      auf der Video-Konsole startet.
    </para>
  </sect2>

  <sect2 arch="arm64" id="arm64-console-setup">
    <title>Konfiguration der Konsole</title>
    <para>
      Der grafische Installer ist auf den arm64 &d-i;-Images für
      Jessie nicht aktiviert, daher wird die serielle Konsole verwendet.
      Das Konsolengerät sollte automatisch durch die Firmware
      erkannt werden; falls dies jedoch nicht funktioniert, sehen Sie
      nach dem Booten von Linux über das GRUB-Menü nur die
      Nachricht <quote>Booting Linux</quote> und danach weiter nichts.
    </para>
    <para>
      In diesem Fall müssen Sie eine Konfiguration für eine
      spezielle Konsole auf der Kernel-Befehlszeile setzen. Drücken
      Sie im GRUB-Menü <userinput>e</userinput> für
      <quote>Edit kernel command-line</quote> und ändern Sie
      <informalexample><screen>--- quiet</screen></informalexample> in
      <informalexample><screen>console=&lt;gerät&gt;,&lt;geschwindigkeit&gt;</screen>
</informalexample>, also z.B.
      <informalexample><screen>console=ttyAMA0,115200n8</screen></informalexample>.
      Drücken Sie danach <keycombo><keycap>Strg</keycap>
      <keycap>x</keycap></keycombo>, um das Booten mit der neuen
      Einstellung fortzusetzen.
    </para>
  </sect2>

  <sect2 arch="arm64" id="juno-installation">
    <title>Installation auf Juno</title>
    <para>
      Juno ist ein UEFI-System, daher ist die Installation ziemlich
      einfach. Die praktischste Methode ist die Installation von einem
      USB-Stick. Sie benötigen eine aktuelle Firmware, um von USB
      booten zu können. Builds von <ulink
      url="&url-juno-firmware;">&url-juno-firmware;</ulink> mit einem
      Datum nach März 2015 wurden diesbezüglich erfolgreich getestet.
      Konsultieren Sie die Juno-Dokumentation, wie Sie ein Update der
      Firmware durchführen.
    </para>
    <para>
      Bereiten Sie ein Standard-arm64-CD-Image auf einem USB-Stick
      vor. Stecken Sie ihn in einen der USB-Ports auf der Rückseite ein.
      Schließen Sie ein serielles Kabel an den oberen 9-poligen seriellen
      Anschluß auf der Rückseite an. Falls Sie eine Netzwerkverbindung
      benötigen (z.B. bei einem netboot-Image), stecken Sie ein
      Ethernet-Kabel in den Anschluß auf der Vorderseite des Juno ein.
    </para>
    <para>
      Starten Sie jetzt eine serielle Konsole mit 115200 + 8Bit ohne
      Parität und booten Sie den Juno.
      Er sollte von dem USB-Stick booten und ein GRUB-Menü anzeigen.
      Die Konfiguration der Konsole wird auf dem Juno nicht korrekt
      detektiert, daher bekommen Sie keine Kernel-Ausgabe, wenn Sie
      einfach nur Enter drücken. Setzen Sie die Konsole auf
      <informalexample><screen>console=ttyAMA0,115200n8</screen></informalexample>,
      wie in (<xref linkend="arm64-console-setup"/>) beschrieben.
      Ein anschließendes Drücken von
      <keycombo><keycap>Strg</keycap><keycap>x</keycap></keycombo>
      sollte den &d-i; zur Anzeige bringen; fahren Sie nun wie
      bei einer normalen Installation fort.
    </para>
  </sect2>

  <sect2 arch="arm64" id="apm-installation">
    <title>Installation auf Applied Micro Mustang</title>
    <para>
      Für dieses Gerät ist UEFI verfügbar, allerdings wird es
      normalerweise mit U-Boot ausgeliefert. Daher können Sie
      entweder zunächst UEFI-Firmware installieren und dann
      Standard-Boot- und Installationsmethoden verwenden, oder
      Sie nutzen Methoden, um mit U-Boot zu booten. Auch wird
      vom Jessie-Kernel kein USB unterstützt, daher ist eine
      Installation von USB-Stick nicht möglich.
      Sie müssen eine serielle Konsole verwenden, um die Installation
      durchzuführen, da der grafische Installer auf der arm64-Architektur
      nicht aktiviert ist.
    </para>
    <para>
      Die empfohlene Methode zur Installation ist, Kernel und
      initrd des &d-i; auf die Festplatte zu kopieren (nutzen
      Sie dazu das openembedded-System, das dem Gerät beiliegt),
      und booten Sie anschließend von der Festplatte, um den
      Installer zu starten. Alternativ können Sie TFTP verwenden,
      um Kernel, dtb und initrd rüber zu kopieren und zu booten
      (<xref linkend="boot-tftp-uboot"/>). Nach der Installation
      sind manuelle Änderungen nötig, um von dem installierten
      Image zu booten.
    </para>
    <para>
      Starten Sie eine serielle Konsole mit 115200 + 8Bit ohne
      Parität und booten Sie das Gerät. Sobald Sie nach dem Neustart
      die Anzeige <quote>Hit any key to stop autoboot:</quote> sehen,
      drücken Sie eine Taste, um einen Mustang#-Prompt zu bekommen.
      Verwenden Sie dann die entsprechenden U-Boot-Befehle, um
      Kernel, dtb und initrd zu laden und zu booten.
     </para>
  </sect2>

  <sect2 arch="arm" id="boot-tftp"><title>Booten per TFTP</title>

&boot-installer-intro-net.xml;

    <sect3 arch="arm" id="boot-tftp-uboot">
      <title>TFTP-Boot in U-Boot</title>
      <para>
       Das Booten von Systemen über das Netzwerk mittels der U-Boot-Firmware
       erfordert drei Schritte: a) Konfigurieren des Netzwerks, b) Laden
       der Images (Kernel/Initial-Ramdisk/dtb) in den Speicher und c)
       das eigentliche Ausführen des vorher geladenen Codes.
      </para>
      <para>
       Als erstes müssen Sie das Netzwerk konfigurieren, entweder
       automatisch über DHCP, indem Sie dies ausführen:
<informalexample><screen>
setenv autoload no
dhcp
</screen></informalexample>
       oder manuell, indem Sie verschiedene Umgebungsvariablen setzen:
<informalexample><screen>
setenv ipaddr &lt;ip-adresse des clients&gt;
setenv netmask &lt;netmask&gt;
setenv serverip &lt;ip-adresse des tftp-servers&gt;
setenv dnsip &lt;ip-adresse des nameservers&gt;
setenv gatewayip &lt;ip-adresse des standard-gateways&gt;
</screen></informalexample>
       Falls Sie möchten, können Sie diese Einstellungen auch
       fest einrichten mit:
<informalexample><screen>
saveenv
</screen></informalexample>
      </para>
      <para>
       Danach müssen Sie die Images (Kernel/Initial-Ramdisk/dtb)
       in den Speicher laden. Dies wird mit dem tftpboot-Befehl
       erledigt, der zusammen mit der Adresse, an der das Image
       im Speicher abgelegt werden soll, angegeben werden muss.
       Unglücklicherweise kann die Lücke im Speicher von
       System zu System variieren, daher gibt es keine grundsätzliche
       Regel, welche Adresse hierfür verwendet werden muss.                     
      </para>
      <para>
       Auf einigen Systemen legt U-Boot einige Umgebungsvariablen mit
       passenden Ladeadressen an: kernel_addr_r, ramdisk_addr_r und
       fdt_addr_r. Sie können überprüfen, ob diese definiert sind,
       indem Sie dies ausführen:
<informalexample><screen>
printenv kernel_addr_r ramdisk_addr_r fdt_addr_r
</screen></informalexample>
       Falls sie nicht definiert sind, müssen Sie die Dokumentation
       des Systems konsultieren bezüglich näherer Angaben zu passenden
       Werten und diese händisch setzen. Für Systeme, die auf
       Allwinner SunXi-SoCs (z.B. dem Allwinner A10,
       Architekturname <quote>sun4i</quote> oder dem Allwinner A20,
       Architekturname <quote>sun7i</quote>) basieren, können Sie
       z.B. folgende Werte nutzen:
<informalexample><screen>
setenv kernel_addr_r 0x46000000
setenv fdt_addr_r 0x47000000
setenv ramdisk_addr_r 0x48000000
</screen></informalexample>
      </para>
      <para>
       Sind die Ladeadressen bereits definiert, können Sie die
       Images von dem vorher definierten TFTP-Server in den Speicher
       laden mit:
<informalexample><screen>
tftpboot ${kernel_addr_r} &lt;dateiname des kernel-images&gt;
tftpboot ${fdt_addr_r} &lt;dateiname des dtb&gt;
tftpboot ${ramdisk_addr_r} &lt;dateiname des initial-ramdisk-images&gt;
</screen></informalexample>
      </para>
      <para>
       Der dritte Schritt ist das Setzen der Kernel-Befehlszeile
       und das eigentliche Ausführen des geladenen Codes. U-Boot
       übergibt den Inhalt der Umgebungsvariable <quote>bootargs</quote>
       als Befehlszeile an den Kernel; also können alle Parameter für
       den Kernel und den Installer - wie z.B. die Konsolen-Gerätedatei
       (lesen Sie dazu <xref linkend="boot-console"/>) oder eventuelle
       Voreinstellungsoptionen (Näheres in <xref 
       linkend="installer-args"/> und <xref linkend="appendix-preseed"/>) -
       mit einem Befehl wie dem folgenden gesetzt werden:
<informalexample><screen>
setenv bootargs console=ttyS0,115200 rootwait panic=10
</screen></informalexample>
       Der exakte Befehl zur Ausführung des vorher geladenen Codes hängt
       vom verwendeten Image-Format ab. Bei uImage/uInitrd lautet der Befehl:
<informalexample><screen>
bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}
</screen></informalexample>
       Bei nativen Linux-Image ist es:
<informalexample><screen>
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
</screen></informalexample>
      </para>
      <para>
       Beachten Sie: wenn Sie Standard-Linux-Images booten, ist es
       wichtig, dass das Initial-Ramdisk-Image nach dem Kernel und der
       DTB geladen wird, da U-Boot die filesize-Variable (Dateigröße)
       auf die Größe der letzten geladenen Datei setzt und der
       bootz-Befehl benötigt die Größe des Ramdisk-Images, um korrekt
       zu arbeiten. Beim Booten eines plattformspezifischen Kernels, also
       eines Kernels ohne Gerätebaum-Abbild (DTB), lassen Sie den
       ${fdt_addr_r}-Parameter einfach weg.
      </para>
    </sect3>

    <sect3 arch="armhf" id="boot-armhf-netboot.tar.gz">
      <title>Vorkonfiguriertes netboot-Tarball-Archiv</title>
      <para>
        &debian; stellt ein vorkonfiguriertes Tarball-Archiv
        (&armmp-netboot-tarball;) bereit, das Sie einfach auf Ihren
        TFTP-Server entpacken können; es enthält alle für das
        Netbooting benötigten Dateien. Außerdem ist ein Boot-Skript
        enthalten, das alle zum Laden des Installers erforderlichen
        Schritte automatisiert. Moderne U-Boot-Versionen haben eine
        TFTP-Autoboot-Funktion, die aktiv wird, wenn kein lokales
        boot-fähiges Speichermedium (MMC/SD-Karte, USB, IDE/SATA/SCSI)
        verfügbar ist; es lädt dann dieses Boot-Skript vom TFTP-Server.
        Voraussetzung für die Verwendung dieser Funktionalität ist,
        dass Sie einen DHCP-Server in Ihrem Netzwerk haben, der den
        Client mit der Adresse des TFTP-Servers versorgt.
      </para>
      <para>
        Möchten Sie die TFTP-Autoboot-Funktion von der U-Boot-Befehlszeile
        aus anstoßen, können Sie folgenden Befehl nutzen:
        <informalexample><screen>run bootcmd_dhcp</screen></informalexample>
      </para>
      <para>
        Um alternativ das Boot-Skript aus dem Tarball-Archiv händisch
        zu laden, können Sie auch diese Befehle am U-Boot-Prompt
        ausführen:

<informalexample><screen>
setenv autoload no
dhcp
tftpboot ${scriptaddr} /debian-installer/armhf/tftpboot.scr
source ${scriptaddr}
</screen></informalexample>

      </para>
    </sect3>
  </sect2> 


  <sect2 arch="arm64" condition="bootable-usb" id="usb-boot">
  <title>Booten von USB-Stick mit UEFI</title>

&boot-installer-intro-usb.xml;

  </sect2>

  <sect2 arch="armel;armhf" id="boot-hd-media">
    <title>Booten von USB-Stick in U-Boot</title>
    <para>
       Viele moderne Versionen von U-Boot haben USB-Unterstützung und
       erlauben das Booten von USB-Massenspeicher-Geräten wie z.B.
       USB-Sticks. Unglücklicherweise können sich die genauen Schritte, die
       dazu nötig sind, von Gerät zu Gerät ein wenig unterscheiden.
    </para>
    <para>
       In U-Boot v2014.10 wurde das grundlegende Handling für eine
       Kommandozeile sowie ein Rahmenwerk für automatisches Booten
       (autoboot) eingeführt. Dies erlaubt die Erzeugung generischer
       Boot-Images, die auf jedem System funktionieren, das dieses Rahmenwerk
       implementiert hat. Der &d-i; unterstützt die Installation von
       USB-Stick auf solchen Systemen, aber leider haben noch nicht alle
       Plattformen dieses Rahmenwerk übernommen.
    </para>
    <para>
       Um einen boot-fähigen USB-Stick zur Installation von &debian;
       zu erstellen, entpacken Sie das hd-media-Tarball-Archiv (Näheres
       in <xref linkend="where-files"/>) auf einen USB-Stick,
       der mit einem Dateisystem formatiert ist, welches von der
       U-Boot-Version auf Ihrem Gerät unterstützt wird.
       Bei neueren U-Boot-Versionen sollten FAT16, FAT32, ext2, ext3
       und ext4 normalerweise funktionieren. Kopieren Sie dann auch die
       ISO-Image-Datei der ersten &debian;-Installations-CD oder -DVD
       auf den Stick.
    </para>
    <para>
      Das autoboot-Rahmenwerk in modernen U-Boot-Versionen funktioniert
      ähnlich wie die Optionen für die Bootreihenfolge in einem PC-Bios,
      d.h. auf verschiedenen möglichen Boot-Geräten wird der Reihe nach
      nach einem gültigen Boot-Image gesucht und das erste gefundene wird
      gestartet. Wenn kein Betriebssystem installiert ist, sollte das
      Starten des Systems mit eingestecktem USB-Stick den Installer booten.
      Sie können den USB-Boot-Prozess auch zu jeder Zeit vom
      U-Boot-Prompt aus anstoßen, indem Sie den
      <quote>run bootcmd_usb0</quote>-Befehl ausführen.
    </para>

    <para>
       Ein Problem, das beim Booten von einem USB-Stick bei Nutzung der
       seriellen Konsole auftreten könnte, ist eine nicht passende
       Konsolenbaudrate. Wenn die console-Variable in U-Boot definiert
       ist, wird das Boot-Skript des &d-i; diese automatisch an den
       Kernel weiterleiten, um das primäre Konsolengerät und - falls
       anwendbar - die Baudrate einzustellen. Unglücklicherweise
       variiert die Handhabung der console-Variable von Plattform zu
       Plattform - auf einigen Plattformen enthält die console-Variable
       die Baurate (wie in <quote>console=ttyS0,115200</quote>), auf
       anderen hingegen lediglich den Gerätenamen (z.B.
       <quote>console=ttyS0</quote>). 
       In letzterem Fall kann es zu einer verstümmelten Konsolenausgabe
       kommen, wenn die Standard-Baudrate bei U-Boot und dem Kernel
       nicht übereinstimmt. Moderne U-Boot-Versionen verwenden oft
       eine Geschwindigkeit von 115200 Baud, während beim Kernel noch
       der alte traditionelle Wert von 9600 Baud voreingestellt ist.
       Falls dies passiert, sollten Sie die console-Variable händisch
       setzen, so dass Sie die korrekte Baudrate für Ihr System
       enthält, und dann den Installer mit <quote>run bootcmd_usb0</quote>
       starten.
    </para>
  </sect2>

  <sect2 arch="armhf" id="boot-installer-sd-image">
    <title>Verwenden von vorbereiteten (pre-built) SD-Karten-Images mit dem Installer</title>
    <para>
       Für eine Reihe von Systemen bietet Debian SD-Karten-Images an,
       die sowohl U-Boot wie auch den &d-i; enthalten. Diese Images gibt es
       in zwei Varianten - eine für das Herunterladen der Software-Pakete
       über das Netzwerk (verfügbar unter &armmp-netboot-sd-img;) und die
       andere für Offline-Installationen ohne Internet-Verbindung, die
       stattdessen eine Debian-CD/DVD verwenden (unter &armmp-hd-media-sd-img;
       verfügbar).
       Um Speicherplatz und Bandbreite zu sparen, bestehen die Images aus
       zwei Teilen - einem System-abhängigen Teil namens
       <quote>firmware.&lt;system-typ&gt;.img.gz</quote> und einem
       System-unabhängigen Teil namens <quote>partition.img.gz</quote>.
    </para>
    <para>
       Um auf einem Linux-System aus diesen beiden Teilen ein vollständiges
       Image zu erzeugen, können Sie zcat wie folgt verwenden:

       <informalexample><screen>zcat firmware.&lt;system-typ&gt;.img.gz partition.img.gz > complete_image.img</screen></informalexample>

       Auf Windows-Systemen müssen Sie die beiden Teile zunächst separat
       dekomprimieren, was zum Beispiel mit 7-Zip erledigt werden kann,
       und dann durch Eingabe des folgenden Befehls in einem cmd.exe-Fenster
       wieder zusammenfügen:

       <informalexample><screen>copy /b firmware.&lt;system-typ&gt;.img + partition.img complete_image.img</screen></informalexample>

    </para>
    <para>
       Schreiben Sie das erzeugte Image auf eine SD-Karte, indem Sie
       z.B. auf einem Linux-System folgenden Befehl nutzen:

       <informalexample><screen>cat complete_image.img > /dev/SD_KARTEN_GERÄT</screen></informalexample>

       Nachdem Sie die SD-Karte in das Zielsystem eingesteckt
       und dieses eingeschaltet haben, wird der Installer von der
       SD-Karte geladen. Falls Sie die hd-media-Variante für eine
       Installation ohne Internet-Verbindung verwenden, müssen Sie dem
       Installer über ein separates Medium Zugriff auf die erste
       &debian;-CD/DVD ermöglichen; dies kann z.B. über ein CD/DVD-ISO-Image
       auf einem USB-Stick geschehen.
    </para>
    <para>
       Wenn Sie im Installer den Schritt für die Partionierung erreichen
       (lesen Sie dazu <xref linkend="di-partition"/>), können Sie jegliche
       Partitionen auf der SD-Karte löschen oder ersetzen. Sobald der Installer
       einmal gestartet ist, läuft er komplett im Arbeitsspeicher des
       Systems und benötigt keinen Zugriff auf die SD-Karte mehr.
       Daher können Sie die vollständige SD-Karte zur Installation von
       &debian; benutzen.
       Der einfachste Weg, ein passendes Partitions-Layout auf der
       SD-Karte zu erstellen, ist die Nutzung der Geführten Partitionierung
       (Näheres hierzu in <xref linkend="partman-auto"/>).
    </para>
  </sect2>












<!-- # None of the arm systems supported in Jessie is able to boot from
     # CD/DVD -> commenting out the "Booting from CD-ROM section" for arm
     
  <sect2 arch="arm"><title>Booten von CD-ROM</title>

&boot-installer-intro-cd.xml;

  </sect2>
-->

<!--

  <sect2 arch="arm" id="boot-firmware"><title>Booten von Firmware</title>

&boot-installer-intro-firmware.xml;

   <sect3 arch="arm" id="boot-firmware-ss4000e">
   <title>Booten des SS4000-E</title>
<para>

Aufgrund von Einschränkungen in der SS4000-E-Firmware ist es derzeit
unglücklicherweise nicht möglich, den Installer ohne Verwendung eines
seriellen Ports zu booten. Um den Installer zu booten, benötigen Sie
ein serielles Nullmodem-Kabel, einen Rechner mit einem seriellen
Port<footnote id="arm-s4ke-port">

<para>
Ein USB-Seriell-Converter funktioniert auch.
</para>

</footnote> und ein Flachbandkabel mit einem männlichen DB9-Anschluß
auf der einen und einem 10-poligen .1" IDC-Stecker auf der anderen
Seite<footnote id="arm-s4k-rib">

<para>
Solch ein Kabel findet sich oft in älteren Desktop-Rechnern mit
eingebauten 9-poligen Anschlüssen für die seriellen Ports.
</para>

</footnote>.

</para><para>

Um den SS4000-E zu booten, verwenden Sie Ihr
Nullmodem-Kabel und das Flachbandkabel, um sich mit dem seriellen Anschluß
des SS4000-E zu verbinden und starten Sie die Maschine neu. Sie müssen
ein serielles Terminal-Programm benutzen, um mit dem Rechner zu kommunizieren;
auf &debian; GNU/Linux-Systemen ist es eine gute Wahl, das Programm
<command>cu</command> aus dem gleichnamigen Paket zu verwenden.
Angenommen, der serielle Port auf Ihrem Rechner ist
<filename>/dev/ttyS0</filename>, benutzen Sie folgende Befehlszeile:

</para>

<informalexample><screen>
cu -lttyS0 -s115200
</screen></informalexample>

<para>

Wenn Sie Windows verwenden, sollten Sie vielleicht das Programm
<classname>hyperterminal</classname> nutzen. Wählen Sie eine
Baudrate von 115200, 8 Bit Wortlänge, kein Stopbit und ein Parity-Bit.

</para><para>

Beim Starten der Maschine werden Sie folgende Ausgabe sehen:

</para>

<informalexample><screen>
No network interfaces found

EM-7210 ver.T04 2005-12-12 (For ver.AA)
== Executing boot script in 1.000 seconds - enter ^C to abort
</screen></informalexample>

<para>

Drücken Sie an diesem Punkt Strg-C, um den Bootloader zu 
unterbrechen<footnote id="arm-s4ke-sec">

<para>
Beachten Sie, dass Sie dazu nur eine Sekunde Zeit haben; falls Sie dies
Zeitfenster verpasst haben, trennen Sie kurz die Stromzufuhr des Rechners und
versuchen Sie es nach dem Start erneut.
</para>

</footnote>. Sie kommen jetzt zum RedBoot-Prompt. Geben Sie folgende Befehle
ein:

<informalexample><screen>
+load -v -r -b 0x01800000 -m ymodem ramdisk.gz
+load -v -r -b 0x01008000 -m ymodem zImage
+exec -c "console=ttyS0,115200 rw root=/dev/ram mem=256M@0xa0000000" -r 0x01800000
</screen></informalexample>

</para><para>
 
Nach jedem <command>load</command>-Befehl erwartet das System die Übermittlung
einer Datei mittels des YMODEM-Protokolls. Wenn Sie cu verwenden, stellen
Sie sicher, dass Sie das Paket <classname>lrzsz</classname> installiert haben,
drücken Sie dann Enter, gefolgt von der <quote>~&lt;</quote>-Escape-Sequenz,
um ein externes Programm zu starten, und führen Sie dann
<command>sb initrd.gz</command> bzw. <command>sb vmlinuz</command> aus.

</para><para>

Alternativ dazu ist es möglich, den Kernel und die Ramdisk mittels HTTP
statt YMODEM zu laden. Dies ist schneller, erfordert jedoch einen funktionierenden
HTTP-Server im Netzwerk. Um diesen Weg zu gehen, schalten Sie zunächst den
Bootloader in den RAM-Modus:

<informalexample><screen>
fis load rammode
g
</screen></informalexample>

</para><para>

Dies führt scheinbar dazu, dass die Maschine neu startet; tatsächlich wird
jedoch reboot in den RAM geladen und die Maschine von dort neu gestartet.
Ohne diesen Schritt würde das System sich im nächsten, zwingend notwendigen
IP-Adressen-Schritt aufhängen.

</para><para>

Sie müssen nochmals Strg-C drücken, um den Bootvorgang zu unterbrechen.
Führen Sie dann folgendes aus:
 
<informalexample><screen>
ip_address -l <replaceable>192.168.2.249</replaceable> -h <replaceable>192.168.2.4</replaceable>
load -v -r -b 0x01800000 -m http /initrd.gz
load -v -r -b 0x01008000 -m http /zImage
exec -c "console=ttyS0,115200 rw root=/dev/ram mem=256M@0xa0000000" -r 0x01800000
</screen></informalexample>

Dabei entspricht <replaceable>192.168.2.249</replaceable> der IP-Adresse
des installierten Systems und <replaceable>192.168.2.4</replaceable> der
IP-Adresse des HTTP-Servers, der die Kernel- und Ramdisk-Dateien enthält.

</para><para>

Der Installer wird nun wie gewöhnlich starten.

</para>
   </sect3>
  </sect2>

-->