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 BIOS/UEFI or system firmware is the core software used by the hardware; it is most critically invoked during the bootstrap process (after power-up). &bios-setup-i386.xml; &bios-setup-powerpc.xml; &bios-setup-s390.xml; &bios-setup-arm.xml; UEFI (Unified Extensible Firmware Interface) 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. Currently most PC systems that use UEFI also have a so-called Compatibility Support Module (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. 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 GUID Partition Table (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. 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. Another UEFI-related topic is the so-called secure boot 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 shim bootloader signed by Microsoft, so should work correctly on systems with secure boot enabled. Windows offers a feature (called fast boot in Windows 8, fast startup 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 boot 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 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/fast startup feature has to be disabled within Windows. 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. It may also be necessary to disable fast boot 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 boot 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. 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 Legacy keyboard emulation or USB keyboard support options.