summaryrefslogtreecommitdiff
path: root/en/preparing
diff options
context:
space:
mode:
Diffstat (limited to 'en/preparing')
-rw-r--r--en/preparing/pre-install-bios-setup.xml94
1 files changed, 94 insertions, 0 deletions
diff --git a/en/preparing/pre-install-bios-setup.xml b/en/preparing/pre-install-bios-setup.xml
index 32e3611e4..02bb6a583 100644
--- a/en/preparing/pre-install-bios-setup.xml
+++ b/en/preparing/pre-install-bios-setup.xml
@@ -20,6 +20,100 @@ hardware; it is most critically invoked during the bootstrap process
&bios-setup-s390.xml;
&bios-setup-arm.xml;
+ <sect2 arch="x86" id="UEFI">
+ <title>Systems with UEFI firmware</title>
+ <para>
+ UEFI (<quote>Unified Extensible Firmware Interface</quote>) is
+ a new kind of system firmware that is used on many modern
+ systems and is - among other uses - intended to replace the
+ classic PC BIOS.
+ </para>
+ <para>
+ Currently most PC systems that use UEFI also have a so-called
+ <quote>Compatibility Support Module</quote> (CSM) in the firmware,
+ which provides excatly the same interfaces to an operating system as a
+ classic PC BIOS, so that software written for the classic PC BIOS
+ can be used unchanged. Nonetheless UEFI is intended to one day
+ completely replace the old PC BIOS without being fully
+ backwards-compatible and there are already a few systems with UEFI but
+ without CSM.
+ </para>
+ <para>
+ On systems with UEFI there are a few things to take into consideration
+ when installing an operating system. The way the firmware loads an
+ operating system is fundamentally different between the classic BIOS
+ (or UEFI in CSM mode) and native UEFI. One major difference is the
+ way the harddisk partitions get recorded on the harddisk. While the
+ classic BIOS and UEFI in CSM mode use a DOS partition table,
+ native UEFI uses a different partitioning scheme called <quote>GUID
+ Partition Table</quote> (GPT). On a single disk, for all practical
+ purposes only one of the two can be used and in case of a multi-boot
+ setup with different operating systems on one disk, all of them must
+ therefore use the same type of partition table. Booting from a disk
+ with GPT is only possible in native UEFI mode, but using GPT becomes
+ more and more common as hard disk sizes grow, because the classic DOS
+ partition table cannot address disks larger than about 2 Terabytes
+ while GPT allows for by far larger disks. The other major difference
+ between BIOS (or UEFI in CSM mode) and native UEFI is from where boot
+ code is loaded and in which format it has to be, so that different
+ bootloaders are needed for both systems.
+ </para>
+ <para>
+ The latter becomes important when booting &d-i; on a UEFI system with
+ CSM because &d-i; checks whether it was started on a BIOS- or on a
+ native UEFI system and installs the corresponding bootloader.
+ Normally this simply works but there can be a problem in multi-boot
+ environments. On some UEFI systems with CSM the default boot mode for
+ removable devices can be different from what is actually used when
+ booting from hard disk, so when booting the installer from a USB stick
+ in a different mode from what is used when booting another already
+ installed operating system from the hard disk, the wrong bootloader
+ might be installed and the system might be unbootable after finishing
+ the installation. When choosing the boot device from a firmware boot
+ menu, some systems offer two seperate choices for each device, so that
+ the user can select whether booting shall happen in CSM or in native
+ UEFI mode.
+ </para>
+ <para>
+ Another UEFI-related topic is the so-called <quote>secure boot</quote>
+ mechanism. Secure boot means a function of UEFI implementations that
+ allows the firmware to only load and execute code that is
+ cryptographically signed with certain keys and thereby blocking any
+ (potentially malicious) boot code that is unsigned or signed with
+ unknown keys. In practice the only key accepted by default on most
+ UEFI systems with secure boot is a key from Microsoft used for signing
+ the Windows bootloader. As the boot code used by &d-i; is not signed
+ by Microsoft, booting the installer requires prior deactivation of
+ secure boot in case it is enabled. Secure boot is often enabled by
+ default on systems that come preinstalled with a 64Bit version of
+ Windows 8 and there is unfortunately no standard where in the UEFI
+ setup it can be disabled. On some systems, the option to disable
+ secure boot is only made visible when a BIOS password has been set by
+ the user, so if you have a system with secure boot enabled, but cannot
+ find an option to disable it, try setting a BIOS password, powercycle
+ the machine and look again for an appropriate option.
+ </para>
+ </sect2>
+
+ <sect2 arch="x86" id="disable-fast-boot">
+ <title>Disabling the Windows 8 <quote>fast boot</quote> feature</title>
+ <para>
+ Windows 8 offers a feature called "fast boot" to cut down the time
+ needed to boot itself. Technically, when this feature is enabled,
+ Windows 8 does not do a real shutdown and a real cold boot afterwards
+ when ordered to shut down, but instead does something resembling a
+ partial suspend to disk to reduce the "boot" time. As long as Windows
+ 8 is the only operating system on the machine, this is unproblematic,
+ but it can result in problems and data loss when you have a dual boot
+ setup in which another operating system accesses the same filesystems
+ as Windows 8 does. In that case the real state of the filesystem can
+ be different from what Windows 8 believes it to be after the "boot"
+ and this could cause filesystem corruption upon further write accesses
+ to the filesystem. Therefore in a dual boot setup, to avoid
+ filesystem corruption the "fast boot" feature has to be disabled
+ within Windows.
+ </para>
+ </sect2>
<sect2 arch="x86;powerpc" id="hardware-issues">
<title>Hardware Issues to Watch Out For</title>