1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
<!-- 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-sparc.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;powerpc" 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>
|
