diff options
author | Holger Wansing <linux@wansing-online.de> | 2014-08-04 08:21:31 +0000 |
---|---|---|
committer | Holger Wansing <linux@wansing-online.de> | 2014-08-04 08:21:31 +0000 |
commit | fe03715c0adf0c0b1f653037363e721310a564e5 (patch) | |
tree | db5bef8b03748847365ee398fca58050b8cd5fa2 /de | |
parent | 56ab8155de7eb30ad833a02966138d0e8b43b5ec (diff) | |
download | installation-guide-fe03715c0adf0c0b1f653037363e721310a564e5.zip |
Update for german d-i manual
Diffstat (limited to 'de')
-rw-r--r-- | de/boot-installer/arm.xml | 148 | ||||
-rw-r--r-- | de/hardware/supported/arm.xml | 2 | ||||
-rw-r--r-- | de/preparing/bios-setup/arm.xml | 99 | ||||
-rw-r--r-- | de/preparing/pre-install-bios-setup.xml | 123 |
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 <ip-adresse des clients> +setenv netmask <netmask> +setenv serverip <ip-adresse des tftp-servers> +setenv dnsip <ip-adresse des nameservers> +setenv gatewayip <ip-adresse des standard-gateways> +</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} <dateiname des kernel-images> +tftpboot ${fdt_addr_r} <dateiname des dtb> +tftpboot ${ramdisk_addr_r} <dateiname des initial-ramdisk-images> +</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> |