<!-- retain these comments for translator revision tracking -->
<!-- $Id$ -->

 <sect1 id="pre-install-bios-setup">
 <title>Pre-Installation Hardware and Operating System Setup</title>
<para>

This section will walk you through pre-installation hardware setup, if
any, that you will need to do prior to installing &debian;.  Generally,
this involves checking and possibly changing BIOS/UEFI/system firmware settings for
your system.  The <quote>BIOS/UEFI</quote> or <quote>system firmware</quote> is the core software used by the
hardware; it is most critically invoked during the bootstrap process
(after power-up).

</para>

&bios-setup-i386.xml;
&bios-setup-powerpc.xml;
&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 exactly 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 lot of 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 are 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 far larger disks.  The other major difference
      between BIOS (or UEFI in CSM mode) and native UEFI is the location where boot
      code is stored and in which format it has to be. This means that different
      bootloaders are needed for each system.
    </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 separate choices for each device, so that
      the user can select whether booting shall happen in CSM or in native
      UEFI mode.
    </para>
  </sect2>

  <sect2 arch="x86" id="secure-boot">
    <title>Secure boot</title>
    <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.  Debian includes a <quote>shim</quote> bootloader
      signed by Microsoft, so should work correctly on systems with
      secure boot enabled.
    </para>
  </sect2>

  <sect2 arch="x86" id="disable-fast-boot">
    <title>Disabling the Windows <quote>fast boot</quote>/<quote>fast startup</quote> feature</title>
    <para>
      Windows offers a feature (called <quote>fast boot</quote> in Windows 8,
      <quote>fast startup</quote> in Windows 10) to cut down system
      startup time.  Technically, when this feature is enabled,
      Windows 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 <quote>boot</quote> time.  As long as Windows
      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 does.  In that case the real state of the filesystem can
      be different from what Windows believes it to be after the <quote>boot</quote>
      and this could cause filesystem corruption upon further write accesses
      to the filesystem.  Therefore in a dual boot setup, to avoid
      filesystem corruption the <quote>fast boot</quote>/<quote>fast startup</quote>
      feature has to be disabled within Windows.
    </para>
    <para>
      Furthermore, the Windows Update mechanism has (sometimes) been known to
      automatically re-enable this feature, after it has been previously
      disabled by the user. It is suggested to re-check this setting periodically.
    </para>
    <para>
      It may also be necessary to disable <quote>fast boot</quote> to
      even allow access to UEFI setup to choose to boot another
      operating system or &d-i;. On some UEFI systems, the firmware
      will reduce <quote>boot</quote> time by not initialising the
      keyboard controller or USB hardware; in these cases, it is
      necessary to boot into Windows and disable this feature to allow
      for a change of boot order.
    </para>

  </sect2>  
  <sect2 arch="x86" id="hardware-issues">
  <title>Hardware Issues to Watch Out For</title>

   <formalpara arch="x86">
   <title>USB BIOS support and keyboards</title>
<para>

If you have no PS/2-style keyboard, but only a USB model, on some
very old PCs you may need to enable legacy keyboard emulation in your BIOS setup
to be able to use your keyboard in the bootloader menu, but this is not an issue
for modern systems. If your keyboard does not work in the bootloader
menu, consult your mainboard manual and look in the BIOS for <quote>Legacy
keyboard emulation</quote> or <quote>USB keyboard support</quote> options.

</para>
   </formalpara>

<!--
   <formalpara arch="powerpc">
   <title>Display-visibility on OldWorld Powermacs</title>

<para>
Some OldWorld Powermacs, most notably those with the <quote>control</quote>
display driver, may not reliably produce a colormap under Linux when the
display is configured for more than 256 colors. If you are experiencing such
issues with your display after rebooting (you can sometimes see data on
the monitor, but on other occasions cannot see anything) or, if the screen
turns black after booting the installer instead of showing you the user
interface, try changing your display settings under MacOS to use 256
colors instead of <quote>thousands</quote> or <quote>millions</quote>.

</para>
   </formalpara>
-->

  </sect2>
 </sect1>
