diff options
Diffstat (limited to 'de/preparing')
| -rw-r--r-- | de/preparing/bios-setup/arm.xml | 99 | ||||
| -rw-r--r-- | de/preparing/pre-install-bios-setup.xml | 123 |
2 files changed, 221 insertions, 1 deletions
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> |