From fe03715c0adf0c0b1f653037363e721310a564e5 Mon Sep 17 00:00:00 2001 From: Holger Wansing Date: Mon, 4 Aug 2014 08:21:31 +0000 Subject: Update for german d-i manual --- de/boot-installer/arm.xml | 148 +++++++++++++++++++++++++++++++- de/hardware/supported/arm.xml | 2 +- de/preparing/bios-setup/arm.xml | 99 +++++++++++++++++++++ de/preparing/pre-install-bios-setup.xml | 123 +++++++++++++++++++++++++- 4 files changed, 366 insertions(+), 6 deletions(-) create mode 100644 de/preparing/bios-setup/arm.xml (limited to 'de') 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 @@ - + + + + Boot-Image-Formate + + 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 (vmlinuz) + zusammen mit einer Standard-Linux-Initial-Ramdisk + (initrd.gz) oder b) Kernel im uImage-Format + (uImage) zusammen mit dazu zugehöriger + Initial-Ramdisk (uInitrd). + + + 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. + + + 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, dtb) erforderlich. Diese ist + spezifisch für jedes unterstützte System und enthält eine + Beschreibung der jeweiligen Hardware. + + Booten per TFTP &boot-installer-intro-net.xml; - - - + + TFTP-Boot in u-boot + + 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. + + + Als erstes müssen Sie das Netzwerk konfigurieren, entweder + automatisch über DHCP, indem Sie dies ausführen: + +setenv autoload no +dhcp + + oder manuell, indem Sie verschiedene Umgebungsvariablen setzen: + +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> + + Falls Sie möchten, können Sie diese Einstellungen auch + fest einrichten mit: + +saveenv + + + + 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. + + + 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: + +printenv kernel_addr_r ramdisk_addr_r fdt_addr_r + + 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 sun4i oder dem Allwinner A20, + Architekturname sun7i) basieren, können Sie + z.B. folgende Werte nutzen: + +setenv kernel_addr_r 0x46000000 +setenv fdt_addr_r 0x47000000 +setenv ramdisk_addr_r 0x48000000 + + + + Sind die Ladeadressen bereits definiert, können Sie die + Images von dem vorher definierten TFTP-Server in den Speicher + laden mit: + +tftpboot ${kernel_addr_r} <dateiname des kernel-images> +tftpboot ${fdt_addr_r} <dateiname des dtb> +tftpboot ${ramdisk_addr_r} <dateiname des initial-ramdisk-images> + + + + Der dritte Schritt ist das Setzen der Kernel-Befehlszeile + und das eigentliche Ausführen des geladenen Codes. u-boot + übergibt den Inhalt der Umgebungsvariable bootargs + 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 ) oder eventuelle + Voreinstellungsoptionen (Näheres in und ) - + mit einem Befehl wie dem folgenden gesetzt werden: + +setenv bootargs console=ttyS0,115200 rootwait panic=10 + + Der exakte Befehl zur Ausführung des vorher geladenen Codes hängt + vom verwendeten Image-Format ab. Bei uImage/uInitrd lautet der Befehl: + +bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} + + Bei nativen Linux-Image ist es: + +bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r} + + + + 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. + + + + + + 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 @@ - + CPUs, Mainboards und Grafikunterstützung 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 @@ + + + + + ARM firmware + + + 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. + + + 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. + + + + + Setting the ethernet MAC address in u-boot + + 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. + + + 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. + + + To avoid conflicts with existing officially-assigned MAC addresses, + there is an address pool which is reserved for so-called + locally administered 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. + + + On systems using u-boot as system firmware, the ethernet MAC address + is placed in the ethaddr environment variable. + It can be checked at the u-boot command prompt with the command + printenv ethaddr and can be set with the command + setenv ethaddr ca:ff:ee:12:34:56. After setting the value, + the command saveenv makes the assignment permanent. + + + + + Kernel/Initrd/Device-Tree relocation issues in u-boot + + 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. + + + 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. + + + 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. + + 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 @@ - + Hardware- und Betriebssystem-Setup vor der Installation @@ -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; + + + Systeme mit UEFI-Firmware + + UEFI (Unified Extensible Firmware Interface) + ist eine neue Art von System-Firmware, die auf vielen modernen + Systemen genutzt wird und - unter anderem - das klassische + PC-BIOS ersetzen soll. + + + Derzeit haben die meisten PC-Systeme, die UEFI verwenden, + ein sogenanntes Compatibility Support Module + (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. + + + 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 GUID + Partition Table (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. + + + 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. + + + Ein anderes Problem mit Bezug zu UEFI ist der sogenannte + Secure Boot-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. + + + + + Deaktivieren der <quote>Fast Boot</quote>-Funktionalität in Windows 8 + + Windows 8 bietet eine Funktionalität namens Fast Boot, + 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 + Ruhezustand eine ähnliche Funktionalität), um die + Boot-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 Booten + 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 Fast Boot-Funktionalität in Windows + deaktiviert werden. + + Hardware-Probleme, auf die Sie achten sollten -- cgit v1.2.3