Update for german d-i manual

4 files changed, 366 insertions, 6 deletions

diff --git a/de/boot-installer/arm.xml b/de/boot-installer/arm.xml
index 6b956e15d..a53c0f06c 100644
--- a/de/boot-installer/arm.xml
+++ b/de/boot-installer/arm.xml
@@ -1,19 +1,157 @@
 <!-- retain these comments for translator revision tracking -->
-<!-- original version: 67373 -->
+<!-- original version: 69213 -->
+
+  <sect2 arch="arm" 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.
+    </para>
+  </sect2>
 
   <sect2 arch="arm" id="boot-tftp"><title>Booten per TFTP</title>
 
 &boot-installer-intro-net.xml;
 
-  </sect2>
-
-
+    <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>
+  </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>
 
@@ -151,3 +289,5 @@ Der Installer wird nun wie gewöhnlich starten.
 </para>
    </sect3>
   </sect2>
+
+-->
diff --git a/de/hardware/supported/arm.xml b/de/hardware/supported/arm.xml
index 5fb50f031..c6b76bc35 100644
--- a/de/hardware/supported/arm.xml
+++ b/de/hardware/supported/arm.xml
@@ -1,5 +1,5 @@
 <!-- retain these comments for translator revision tracking -->
-<!-- original version: 69213 -->
+<!-- original version: 69216 -->
 
   <sect2 arch="arm"><title>CPUs, Mainboards und Grafikunterstützung</title>
 
diff --git a/de/preparing/bios-setup/arm.xml b/de/preparing/bios-setup/arm.xml
new file mode 100644
index 000000000..4ce39ea28
--- /dev/null
+++ b/de/preparing/bios-setup/arm.xml
@@ -0,0 +1,99 @@
+<!-- retain these comments for translator revision tracking -->
+<!-- original version: 43641 untranslated -->
+
+
+  <sect2 arch="arm" id="arm-firmware-overview"><title>ARM firmware</title>
+
+    <para>
+      As already mentioned before, there is unfortunately no standard for
+      system firmware on ARM systems.  Even the behaviour of different
+      systems which use nominally the same firmware can be quite different. 
+      This results from the fact that a large part of the devices using the
+      ARM architecture are embedded systems, for which the manufacturers
+      usually build heavily customized firmware versions and include
+      device-specific patches.  Unfortunately the manufacturers often do not
+      submit their changes and extensions back to the mainline firmware
+      developers, so their changes are not integrated into newer versions of
+      the original firmware.
+    </para>
+    <para>
+      As a result even newly sold systems often use a firmware that is based
+      on a years-old manufacturer-modified version of a firmware whose
+      mainline codebase has evolved a lot further in the meantime and offers
+      additional features or shows different behaviour in certain aspects. 
+      In addition to that, the naming of onboard devices is not consistent
+      between different manufacturer-modified versions of the same firmware,
+      therefore it is nearly impossible to provide usable
+      product-independend instructions for ARM-based systems.
+    </para>
+  </sect2>
+
+  <sect2 arch="arm" id="uboot-macsetting">
+    <title>Setting the ethernet MAC address in u-boot</title>
+    <para>
+      The MAC address of every ethernet interface should normally be
+      globally unique, and it technically has to be unique within its
+      ethernet broadcast domain.  To achieve this, the manufacturer usually
+      allocates a block of MAC addresses from a centrally-administered
+      pool (for which a fee has to be paid) and preconfigures one of these
+      addresses on each item sold.
+    </para>
+    <para>
+      In the case of development boards, sometimes the manufacturer wants to
+      avoid paying these fees and therefore provides no globally unique
+      addresses.  In these cases the users themselves have to define MAC
+      addresses for their systems.  When no MAC address is defined for an
+      ethernet interface, some network drivers generate a random MAC address
+      that can change on every boot, and if this happens, network access
+      would be possible even when the user has not manually set an address,
+      but e.g. assigning semi-static IP addresses by DHCP based on the MAC
+      address of the requesting client would obviously not work reliably.
+    </para>
+    <para>
+      To avoid conflicts with existing officially-assigned MAC addresses,
+      there is an address pool which is reserved for so-called
+      <quote>locally administered</quote> addresses. It is defined by
+      the value of two specific bits in the first byte of the address (the
+      article "MAC address" in the English language Wikipedia gives a 
+      good explanation). In practice this means that e.g. any address starting
+      with hexadecimal ca (such as ca:ff:ee:12:34:56) can be used as a locally
+      administered address. 
+    </para>
+    <para>
+      On systems using u-boot as system firmware, the ethernet MAC address
+      is placed in the <quote>ethaddr</quote> environment variable.
+      It can be checked at the u-boot command prompt with the command
+      <quote>printenv ethaddr</quote> and can be set with the command
+      <quote>setenv ethaddr ca:ff:ee:12:34:56</quote>.  After setting the value,
+      the command <quote>saveenv</quote> makes the assignment permanent.
+    </para>
+  </sect2>
+
+  <sect2 arch="arm" id="uboot-relocation-issues">
+    <title>Kernel/Initrd/Device-Tree relocation issues in u-boot</title>
+    <para>
+      On some systems with older u-boot versions there can be problems with
+      properly relocating the Linux kernel, the initial ramdisk and the
+      device-tree blob in memory during the boot process.  In this case,
+      u-boot shows the message "Starting kernel ...", but the system freezes
+      afterwards without further output.  These issues have been solved with
+      newer u-boot versions from v2014.07 onwards.
+    </para>
+    <para>
+      If the system has originally used a u-boot version older than
+      v2014.07 and has been upgraded to a newer version later, the problem
+      might still occur even after upgrading u-boot.  Upgrading u-boot
+      usually does not modify the existing u-boot environment variables and
+      the fix requires an additional environment variable (bootm_size) to be
+      set, which u-boot does automatically only on fresh installations
+      without existing environment data.  It is possible to manually set
+      bootm_size to the new u-boot's default value by running the command
+      "env default bootm_size; saveenv" at the u-boot prompt.
+    </para>
+    <para>
+      Another possibility to circumvent relocation-related problems is to
+      run the command "setenv fdt_high ffffffff; setenv initrd_high
+      0xffffffff; saveenv" at the u-boot prompt to completely disable
+      the relocation of the initial ramdisk and the device-tree blob.          
+    </para>
+  </sect2>
diff --git a/de/preparing/pre-install-bios-setup.xml b/de/preparing/pre-install-bios-setup.xml
index 14c133e8c..6d3783e69 100644
--- a/de/preparing/pre-install-bios-setup.xml
+++ b/de/preparing/pre-install-bios-setup.xml
@@ -1,5 +1,5 @@
 <!-- retain these comments for translator revision tracking -->
-<!-- original version: 67993 -->
+<!-- original version: 69217 -->
 
  <sect1 id="pre-install-bios-setup">
  <title>Hardware- und Betriebssystem-Setup vor der Installation</title>
@@ -19,6 +19,127 @@ interne Software; sie ist meistens höchst kritisch in den Boot-Prozess involvie
 &bios-setup-powerpc.xml; 
 &bios-setup-sparc.xml; 
 &bios-setup-s390.xml; 
+&bios-setup-arm.xml; 
+
+  <sect2 arch="x86" id="UEFI">
+    <title>Systeme mit UEFI-Firmware</title>
+    <para>
+       UEFI (<quote>Unified Extensible Firmware Interface</quote>)
+       ist eine neue Art von System-Firmware, die auf vielen modernen
+       Systemen genutzt wird und - unter anderem - das klassische
+       PC-BIOS ersetzen soll.
+    </para>
+    <para>
+       Derzeit haben die meisten PC-Systeme, die UEFI verwenden,
+       ein sogenanntes <quote>Compatibility Support Module</quote>
+       (CSM, Kompatibilitätsmodul) in der Firmware, das exakt die
+       gleichen Schnittstellen an ein Betriebssystem zur Verfügung
+       stellt wie ein klassiches PC-BIOS, so dass Software, die für
+       das klassische BIOS geschrieben wurde, unverändert weiter
+       genutzt werden kann. Nichtsdestotrotz soll UEFI eines Tages
+       das alte PC-BIOS ganz ersetzen, ohne dabei vollständig
+       rückwärtskompatibel zu sein; es gibt sogar bereits jetzt Systeme
+       mit UEFI, die kein CSM haben.
+    </para>
+    <para>
+       Auf Systemen mit UEFI gibt es ein paar Dinge, die in Betracht
+       gezogen werden sollten, wenn ein Betriebssystem installiert
+       werden soll. Der Weg, wie die Firmware ein Betriebssystem lädt,
+       ist fundamental unterschiedlich zwischen dem klassischen BIOS
+       (oder UEFI im CSM-Modus) und nativem UEFI. Ein wesentlicher
+       Unterschied ist die Art, wie Festplattenpartitionen auf der
+       Platte gespeichert werden. Während das klassische BIOS und
+       UEFI im CSM-Modus eine DOS-Partitionstabelle verwenden, nutzt
+       UEFI ein anderes Partitionierungsschema namens <quote>GUID
+       Partition Table</quote> (GPT). Auf jeweils einer Festplatte
+       kann aus praktischen Gründen immer nur eine der beiden eingesetzt
+       werden, daher müssen bei einem Multi-Boot-Setup (System mit
+       mehreren verschiedenen installierten Betriebssystemen) alle
+       Systeme den gleichen Partitionstabellentyp nutzen. Das Booten
+       von einer Festplatte mit GPT ist nur im nativen UEFI-Modus
+       möglich, aber GPT ist mehr und mehr im Kommen, da die Festplatten
+       immer größer werden und die klassische DOS-Partitionstabelle
+       keine Platten größer als 2 Terabyte adressieren kann; GPT jedoch
+       erlaubt erheblich größere Festplatten. Der andere große
+       Unterschied zwischen BIOS (oder UEFI im CSM-Modus) und nativem
+       UEFI ist, von wo der Boot-Code geladen wird und welches Format
+       er haben muss, so dass für beide Systeme unterschiedliche
+       Bootloader erforderlich sind.
+    </para>
+    <para>
+       Letzteres ist wichtig, wenn der &d-i; auf einem UEFI-System
+       mit CSM gebootet wird, weil der &d-i; überprüft, ob er auf
+       einem BIOS- oder einem nativen UEFI-System gestartet wurde
+       und danach den entsprechenden Bootloader installiert.
+       Normalerweise funktioniert dies, aber in Multi-Boot-Umgebungen
+       kann es ein Problem geben. Bei einigen UEFI-Systemen mit CSM
+       kann der Standard-Boot-Modus für das Booten von Wechseldatenträgern
+       ein anderer sein als beim Booten von fest eingebauter Festplatte;
+       wenn also der Installer von einem USB-Stick in einem anderen
+       Modus gebootet wird, als wenn ein anderes, bereits installiertes
+       Betriebssystem von Festplatte startet, könnte der falsche
+       Bootloader installiert werden und das System nach Abschluß der
+       Installation nicht mehr boot-fähig sein.
+       Bei der Auswahl eines Boot-Gerätes in einem Menü in der
+       Firmware bieten einige Systeme zwei separate Auswahlen für
+       jedes Gerät an, so dass der Benutzer auswählen kann, ob im
+       CSM- oder im nativen UEFI-Modus gebootet werden soll.
+    </para>
+    <para>
+       Ein anderes Problem mit Bezug zu UEFI ist der sogenannte
+       <quote>Secure Boot</quote>-Mechanismus. Secure Boot ist eine
+       Funktion in UEFI-Implementationen, die es der Firmware nur
+       erlaubt, Code zu laden und auszuführen, wenn dieser kryptografisch
+       mit bestimmten Schlüsseln signiert ist; so wird jeglicher
+       (möglicherweise bösartiger) Boot-Code, der nicht oder mit
+       unbekannten Schlüsseln signiert ist, blockiert.
+       In der Praxis ist der einzige Schlüssel, der auf den meisten
+       UEFI-Systemen mit Secure Boot standardmäßig akzeptiert wird,
+       ein Schlüssel von Microsoft, der genutzt wird, um den
+       Windows-Bootloader zu signieren. Da der vom &d-i; genutzte
+       Boot-Code nicht von Microsoft signiert ist, erfordert der
+       Installer die vorherige Deaktivierung von Secure Boot, sollte
+       dies aktiv sein. Secure Boot ist auf Systemen, auf denen
+       eine 64-Bit-Version von Windows 8 vorinstalliert ist, oftmals
+       standardmäßig aktiviert und es gibt unglücklicherweise keinen
+       Standard, wo in der UEFI-Setup-Maske Secure Boot
+       deaktiviert werden kann. Auf einigen Systemen wird die Option
+       zur Deaktivierung von Secure Boot nur angezeigt, wenn der
+       Benutzer ein BIOS-Passwort gesetzt hat; wenn Sie also ein
+       System mit aktiviertem Secure Boot haben und keine Option finden
+       können, um es zu deaktivieren, versuchen Sie, ein BIOS-Passwort
+       zu setzen, machen Sie den Rechner stromlos und suchen Sie dann
+       erneut nach einer entsprechenden Option.
+    </para>
+  </sect2>
+
+  <sect2 arch="x86" id="disable-fast-boot">
+    <title>Deaktivieren der <quote>Fast Boot</quote>-Funktionalität in Windows 8</title>
+    <para>
+       Windows 8 bietet eine Funktionalität namens <quote>Fast Boot</quote>,
+       um die für das Booten des Systems benötigte Zeit zu verkürzen.
+       Windows 8 fährt dabei das System nicht wirklich vollständig
+       herunter, wenn Sie ein Herunterfahren anweisen, und aufgrunddessen
+       findet beim nächsten Start natürlich auch kein echter
+       System-Kaltstart statt. Stattdessen wird etwas ähnliches wie
+       ein partielles Suspend-to-disk durchgeführt (der Systemzustand wird
+       eingefroren und in einem speziellen Bereich der Festplatte
+       gespeichert; in früheren Windows-Versionen bot
+       <quote>Ruhezustand</quote> eine ähnliche Funktionalität), um die
+       <quote>Boot</quote>-Zeit zu reduzieren.
+       Solange Windows 8 das einzige Betriebssystem auf der Maschine ist,
+       ist dies unproblematisch, aber es kann zu Problemen und Datenverlust
+       führen, wenn Sie ein Dual-Boot-System haben, bei dem ein anderes
+       Betriebssystem auf die gleichen Dateisysteme zugreift wie Windows 8.
+       In diesem Fall kann sich der echte Status des Dateisystems von dem
+       unterscheiden, den Windows 8 nach seinem nächsten <quote>Booten</quote>
+       vermutet; dies kann bei weiteren Schreibzugriffen zu einer
+       Beschädigung des Dateisystems führen. Um in einem
+       Dual-Boot-System eine Beschädigung der Dateisysteme zu vermeiden,
+       muss daher die <quote>Fast Boot</quote>-Funktionalität in Windows
+       deaktiviert werden.
+    </para>
+  </sect2>
 
   <sect2 arch="x86;powerpc" id="hardware-issues">
   <title>Hardware-Probleme, auf die Sie achten sollten</title>