Update german d-i manual translation

4 files changed, 246 insertions, 8 deletions

diff --git a/de/preparing/bios-setup/i386.xml b/de/preparing/bios-setup/i386.xml
index 29e414cfb..da0b01c6c 100644
--- a/de/preparing/bios-setup/i386.xml
+++ b/de/preparing/bios-setup/i386.xml
@@ -1,5 +1,5 @@
 <!-- retain these comments for translator revision tracking -->
-<!-- original version: 68479 -->
+<!-- original version: 69748 -->
 
   <sect2 arch="any-x86" id="bios-setup"><title>Das BIOS-Setup-Menü aufrufen</title>
 
diff --git a/de/preparing/bios-setup/powerpc.xml b/de/preparing/bios-setup/powerpc.xml
index 4e9b6854c..c34f47fb1 100644
--- a/de/preparing/bios-setup/powerpc.xml
+++ b/de/preparing/bios-setup/powerpc.xml
@@ -1,5 +1,5 @@
 <!-- retain these comments for translator revision tracking -->
-<!-- original version: 54285 -->
+<!-- original version: 69732 -->
 
 
   <sect2 arch="powerpc" id="invoking-openfirmware">
@@ -56,3 +56,228 @@ NVRAM installiert werden.
 
 </para>
   </sect2>
+
+<!-- Leaving the following paragraphs untranslated due to time constraints -->
+  <sect2 arch="ppc64el;powerpc" id="update-firmware">
+  <title>How to update bare metal ppc64el firmware</title>
+<para>
+
+This is an excerpt from
+<ulink url="&url-ibm-powerkvm;">IBM PowerKVM on IBM POWER8</ulink>
+
+</para><para>
+
+Open Power Abstraction Layer (OPAL) is the system firmware in the stack
+of POWER processor-based server.
+
+</para><para>
+
+There may be instances when the user might have to upgrade the Power
+Systems firmware to a more recent level to acquire new features or
+additional support for devices.
+
+</para><para>
+
+Make sure that the following requirements are met:
+
+<itemizedlist>
+<listitem><para>
+    an OS to be running on the system;
+</para></listitem><listitem><para>
+    the .img file of the OPAL level that the user needs to update to;
+</para></listitem><listitem><para>
+    the machine isn't under HMC control.
+</para></listitem>
+</itemizedlist>
+</para><para>
+
+Power Systems has two sides of flash to boot firmware from, namely
+permanent and temporary. This provides a way to test firmware updates on
+the temporary side of the flash before committing the tested changes to
+the permanent side, thereby committing the new updates.
+
+</para><para>
+
+Perform the following steps for the update:
+
+<orderedlist>
+<listitem><para>
+    Save the level of the existing firmware before really updating. In
+    ASM, in the system menu, click <command>Service Aids ??? Service Processor
+    Command Line</command>, and run the following command:
+<informalexample><screen>
+     cupdcmd -f
+</screen></informalexample>
+</para></listitem><listitem><para>
+    Download the .img file of the level of firmware to be updated to a
+    location in the host filesystem. Refer to IBM Fix Central for downloading
+    the image file.
+</para><para>
+    Verify the image downloaded by running the following command and
+    save the output.
+<informalexample><screen>
+    $update_flash -v -f &lt;file_name.img&gt;
+</screen></informalexample>
+</para></listitem>
+<listitem><para>
+    Update the firmware by running the following command.
+<informalexample><screen>
+    $update_flash -f &lt;file_name.img&gt;
+</screen></informalexample>
+</para>
+
+<note><para>
+
+ <itemizedlist>
+ <listitem><para>
+    The command reboots the system and therefore, sessions if any,
+    would be lost.
+ </para></listitem><listitem><para>
+    Do not reboot or switch off the system until it is back.
+ </para></listitem>
+ </itemizedlist>
+
+</para></note>
+
+</listitem><listitem><para>
+    Verify the updated firmware level of the temporary side of the flash
+    as in step 1. 
+</para></listitem><listitem><para>
+    In case the update has to be reverted, the user can do so by running
+    this command:
+<informalexample><screen>
+    $update_flash -r
+</screen></informalexample>
+    Rejection would reject only the temporary side of the flash. 
+    Therefore, the new level should be committed to the permanent side only
+    after thorough testing of the new firmware.
+</para><para>
+    The new updated level can be committed to the permanent side of the
+    flash by running the following command.
+<informalexample><screen>
+    $update_flash -c
+</screen></informalexample>
+</para></listitem>
+</orderedlist>
+
+</para>
+  </sect2>
+
+  <sect2 arch="ppc64el;powerpc"> 
+  <title>Updating KVM guest firmware (SLOF)</title>
+<para>
+
+Slimline Open Firmware (SLOF) is an implementation of the IEEE 1275 
+standard. 
+It can be used as partition firmware for pSeries machines running on
+QEMU or KVM.
+
+</para><para>
+
+The package qemu-slof is, in fact, a dependency of package 
+qemu-system-ppc (which also provides the virtual package 
+qemu-system-ppc64), and can be installed or updated via 
+<command>apt-get</command> tool on Debian-based distros.
+Like so:
+
+<informalexample><screen>
+# apt-get install qemu-slof
+</screen></informalexample>
+
+SLOF can also be installed into rpm-based distribution systems, given 
+the proper repository or rpm package. Additionally, the upstream source 
+code is available at http://github.com/leilihh/SLOF.
+
+</para><para>
+
+Thus, one can use a different SLOF file rather than the default, when
+running <command>qemu-system</command>, by adding the command line
+argument <userinput>-bios &lt;slof_file&gt; </userinput> when starting
+qemu.
+
+</para>
+  </sect2>
+
+  <sect2 arch="ppc64el"> <title>Updating PowerKVM hypervisor</title>
+    <sect3 arch="ppc64el"> <title>Instructions for Netboot installation</title>
+<para>
+
+You will need a DHCP/TFTP (BOOTP) server, as well as a web server.
+After downloading ibm-powerkvm-*-ppc64-service-*.iso, mount loop it and
+unpack it into some directory within your HTTP server www root 
+structure (say wwwroot):
+
+<informalexample><screen>
+# cd &lt;directory-where-the-iso-is&gt;
+# mkdir ./iso
+# sudo mount -o loop ibm-powerkvm-*-ppc64-service-*.iso ./iso
+# cp -a ./iso/* &lt;path-to-wwwroot&gt;
+</screen></informalexample>
+
+Create the petitboot.conf file in a directory under your tftproot, say
+/tftproot/powerkvm, with the following contents:
+
+<informalexample><screen>
+label PowerKVM Automated Install
+kernel http://YOUR-SERVER-IP/SOME-PATH-TO-wwwroot/ppc/ppc64/vmlinuz
+initrd http://YOUR-SERVER-IP/SOME-PATH-TO-wwwroot/ppc/ppc64/initrd.img
+append root=live:http://YOUR-SERVER-IP/SOME-PATH-TO-wwwroot/LiveOS/squashfs.img repo=http://YOUR-SERVER-IP/SOME-PATH-TO-wwwroot/packages rd.dm=0 rd.md=0 console=hvc0 console=tty0
+</screen></informalexample>
+
+Editing your dhcpd.conf, set this directive at the beginning:
+
+<informalexample><screen>
+option conf-file code 209 = text;
+</screen></informalexample>
+
+Add the system directive:
+
+<informalexample><screen>
+host &lt;your-system&gt; {
+    hardware ethernet &lt;system macaddr&gt;
+    fixed-address &lt;system ip&gt;;
+    option host-name "&lt;system hostname&gt;";
+    option conf-file "&lt;powerkvm/petitboot.conf&gt;";
+ }
+</screen></informalexample>
+
+Reboot the dhcp server.
+
+</para><para>
+
+Boot your PowerLinux machine.
+
+</para><para>
+
+There should be the following option at petitboot (select it):
+
+<informalexample><screen>
+"Power KVM Automated Install" 
+</screen></informalexample>
+
+The installer menu should appear automatically.
+
+</para>
+    </sect3>
+
+    <sect3 arch="ppc64el"> <title>Instructions for DVD</title>
+<para>
+Boot the ISO ibm-powerkvm-*-ppc64-service-*.iso (either burn a DVD or
+make it virtual if using QEMU) and simply wait for the boot.
+</para><para>
+There should be the following option at petitboot (select it):
+<informalexample><screen>
+"POWERKVM_LIVECD" 
+</screen></informalexample>
+The installer menu should appear automatically.
+</para>
+    </sect3>
+  </sect2>
+
+<!-- commented out for now, since there is no content
+  <sect2 arch="ppc64el"> <title>Updating PowerVM hypervisor</title>
+<para>
+FIXME: add some useful content here
+</para>
+  </sect2>
+-->
diff --git a/de/preparing/nondeb-part/x86.xml b/de/preparing/nondeb-part/x86.xml
index 14d0830dc..6de5e6f7c 100644
--- a/de/preparing/nondeb-part/x86.xml
+++ b/de/preparing/nondeb-part/x86.xml
@@ -1,5 +1,5 @@
 <!-- retain these comments for translator revision tracking -->
-<!-- original version: 65195 -->
+<!-- original version: 69772 -->
 
 
   <sect2 arch="any-x86"><title>Partitionieren unter MS-DOS oder Windows</title>
diff --git a/de/preparing/pre-install-bios-setup.xml b/de/preparing/pre-install-bios-setup.xml
index 6d3783e69..8a74606e1 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: 69217 -->
+<!-- original version: 69747 -->
 
  <sect1 id="pre-install-bios-setup">
  <title>Hardware- und Betriebssystem-Setup vor der Installation</title>
@@ -38,8 +38,8 @@ interne Software; sie ist meistens höchst kritisch in den Boot-Prozess involvie
        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.
+       rückwärtskompatibel zu sein; es gibt sogar bereits jetzt 
+       eine Reihe von Systemen mit UEFI, die kein CSM haben.
     </para>
     <para>
        Auf Systemen mit UEFI gibt es ein paar Dinge, die in Betracht
@@ -62,8 +62,8 @@ interne Software; sie ist meistens höchst kritisch in den Boot-Prozess involvie
        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
+       UEFI ist der Ort, wo der Boot-Code abgelegt ist und welches Format
+       er haben muss. Das bedeutet, dass für beide Systeme unterschiedliche
        Bootloader erforderlich sind.
     </para>
     <para>
@@ -139,6 +139,19 @@ interne Software; sie ist meistens höchst kritisch in den Boot-Prozess involvie
        muss daher die <quote>Fast Boot</quote>-Funktionalität in Windows
        deaktiviert werden.
     </para>
+    <para>
+       Es könnte auch nötig sein, <quote>fast boot</quote> zu
+       deaktivieren, um Zugriff auf das UEFI-Setup erhalten
+       und so ein anderes Betriebssystem oder den &d-i; zum Starten
+       auswählen zu können.
+       Auf einigen UEFI-Systemen könnte die Firmware die zum Booten
+       benötigte Zeit reduzieren, indem Tastatur-Controller oder
+       USB-Hardware nicht initialisiert werden. In diesen Fällen
+       ist es erforderlich, Windows zu booten und dort die
+       <quote>fast boot</quote>-Funktionalität zu deaktivieren,
+       damit Sie die Möglichkeit erhalten, die Boot-Reihenfolge zu
+       ändern.
+    </para>
   </sect2>
 
   <sect2 arch="x86;powerpc" id="hardware-issues">