Refresh pot and po files after changings in en

1 files changed, 63 insertions, 63 deletions

diff --git a/po/pot/preparing.pot b/po/pot/preparing.pot
index b94b51f6e..3be16800d 100644
--- a/po/pot/preparing.pot
+++ b/po/pot/preparing.pot
@@ -6,7 +6,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
 "Report-Msgid-Bugs-To: debian-boot@lists.debian.org\n"
-"POT-Creation-Date: 2015-04-15 20:29+0000\n"
+"POT-Creation-Date: 2015-05-07 17:01+0000\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <LL@li.org>\n"
@@ -981,7 +981,7 @@ msgid "The BIOS provides the basic functions needed to boot your machine and to
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1138 preparing.xml:1479
+#: preparing.xml:1138 preparing.xml:1480
 #, no-c-format
 msgid "Boot Device Selection"
 msgstr ""
@@ -1065,7 +1065,7 @@ msgstr ""
 #. Tag: para
 #: preparing.xml:1254
 #, no-c-format
-msgid "This is an excerpt from <ulink url=\"&url-ibm-powerkvm;\">IBM PowerKVM on IBM POWER8</ulink>"
+msgid "This is an excerpt from <ulink url=\"&url-ibm-powerkvm;\">IBM PowerKVM on IBM POWER8</ulink>."
 msgstr ""
 
 #. Tag: para
@@ -1215,29 +1215,29 @@ msgstr ""
 msgid ""
       "The package qemu-slof is, in fact, a dependency of package qemu-system-ppc (which also provides the virtual package qemu-system-ppc64), and can be installed or updated via <command>apt-get</command> tool on Debian-based distros. Like so: <informalexample><screen>\n"
       "# apt-get install qemu-slof\n"
-      "</screen></informalexample> SLOF can also be installed into rpm-based distribution systems, given the proper repository or rpm package. Additionally, the upstream source code is available at http://github.com/leilihh/SLOF."
+      "</screen></informalexample> SLOF can also be installed into rpm-based distribution systems, given the proper repository or rpm package. Additionally, the upstream source code is available at <ulink url=\"http://github.com/leilihh/SLOF\"></ulink>."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1370
+#: preparing.xml:1371
 #, no-c-format
 msgid "Thus, one can use a different SLOF file rather than the default, when running <command>qemu-system</command>, by adding the command line argument <userinput>-bios &lt;slof_file&gt; </userinput> when starting qemu."
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1380
+#: preparing.xml:1381
 #, no-c-format
 msgid "Updating PowerKVM hypervisor"
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1381
+#: preparing.xml:1382
 #, no-c-format
 msgid "Instructions for Netboot installation"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1382
+#: preparing.xml:1383
 #, no-c-format
 msgid ""
       "You will need a DHCP/TFTP (BOOTP) server, as well as a web server. After downloading ibm-powerkvm-*-ppc64-service-*.iso, mount loop it and unpack it into some directory within your HTTP server www root structure (say wwwroot): <informalexample><screen>\n"
@@ -1263,13 +1263,13 @@ msgid ""
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1406
+#: preparing.xml:1407
 #, no-c-format
 msgid "Boot your PowerLinux machine."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1410
+#: preparing.xml:1411
 #, no-c-format
 msgid ""
       "There should be the following option at petitboot (select it): <informalexample><screen>\n"
@@ -1278,19 +1278,19 @@ msgid ""
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1421
+#: preparing.xml:1422
 #, no-c-format
 msgid "Instructions for DVD"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1422
+#: preparing.xml:1423
 #, no-c-format
 msgid "Boot the ISO ibm-powerkvm-*-ppc64-service-*.iso (either burn a DVD or make it virtual if using QEMU) and simply wait for the boot."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1425
+#: preparing.xml:1426
 #, no-c-format
 msgid ""
       "There should be the following option at petitboot (select it): <informalexample><screen>\n"
@@ -1299,37 +1299,37 @@ msgid ""
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1446
+#: preparing.xml:1447
 #, no-c-format
 msgid "Invoking OpenBoot"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1448
+#: preparing.xml:1449
 #, no-c-format
 msgid "OpenBoot provides the basic functions needed to boot the &arch-title; architecture. This is rather similar in function to the BIOS in the x86 architecture, although much nicer. The Sun boot PROMs have a built-in forth interpreter which lets you do quite a number of things with your machine, such as diagnostics and simple scripts."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1456
+#: preparing.xml:1457
 #, no-c-format
 msgid "To get to the boot prompt you need to hold down the <keycap>Stop</keycap> key (on older type 4 keyboards, use the <keycap>L1</keycap> key, if you have a PC keyboard adapter, use the <keycap>Break</keycap> key) and press the <keycap>A</keycap> key. The boot PROM will give you a prompt, either <userinput>ok</userinput> or <userinput>&gt;</userinput>. It is preferred to have the <userinput>ok</userinput> prompt. So if you get the old style prompt, hit the <keycap>n</keycap> key to get the new style prompt."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1468
+#: preparing.xml:1469
 #, no-c-format
 msgid "If you are using a serial console, send a break to the machine. With Minicom, use <keycap>Ctrl-A F</keycap>, with cu, hit <keycap>Enter</keycap>, then type <userinput>%~break</userinput>. Consult the documentation of your terminal emulator if you are using a different program."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1481
+#: preparing.xml:1482
 #, no-c-format
 msgid "You can use OpenBoot to boot from specific devices, and also to change your default boot device. However, you need to know some details about how OpenBoot names devices; it's considerably different from Linux device naming, described in <xref linkend=\"device-names\"/>. Also, the command will vary a bit, depending on what version of OpenBoot you have. More information about OpenBoot can be found in the <ulink url=\"&url-openboot;\">Sun OpenBoot Reference</ulink>."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1491
+#: preparing.xml:1492
 #, no-c-format
 msgid ""
       "Typically, with newer revisions, you can use OpenBoot devices such as <quote>floppy</quote>, <quote>cdrom</quote>, <quote>net</quote>, <quote>disk</quote>, or <quote>disk2</quote>. These have the obvious meanings; the <quote>net</quote> device is for booting from the network. Additionally, the device name can specify a particular partition of a disk, such as <quote>disk2:a</quote> to boot disk2, first partition. Full OpenBoot device names have the form: <informalexample> <screen>\n"
@@ -1340,7 +1340,7 @@ msgid ""
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1514
+#: preparing.xml:1515
 #, no-c-format
 msgid ""
       "To boot from a specific device, use the command <userinput>boot <replaceable>device</replaceable></userinput>. You can set this behavior as the default using the <userinput>setenv</userinput> command. However, the name of the variable to set changed between OpenBoot revisions. In OpenBoot 1.x, use the command <userinput>setenv boot-from <replaceable>device</replaceable></userinput>. In later revisions of OpenBoot, use the command <userinput>setenv boot-device <replaceable>device</replaceable></userinput>. Note, this is also configurable using the <command>eeprom</command> command on Solaris, or modifying the appropriate files in <filename>/proc/openprom/options/</filename>, for example under Linux: <informalexample><screen>\n"
@@ -1349,259 +1349,259 @@ msgid ""
 msgstr ""
 
 #. Tag: screen
-#: preparing.xml:1533
+#: preparing.xml:1534
 #, no-c-format
 msgid "eeprom boot-device=disk1:1"
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1543
+#: preparing.xml:1544
 #, no-c-format
 msgid "BIOS Setup"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1544
+#: preparing.xml:1545
 #, no-c-format
 msgid "In order to install &debian-gnu; on a &arch-title; or zSeries machine you have first boot a kernel into the system. The boot mechanism of this platform is inherently different to other ones, especially from PC-like systems: there are no floppy devices available at all. You will notice another big difference while you work with this platform: most (if not all) of the time you will work remote, with the help of some client session software like telnet, or a browser. This is due to that special system architecture where the 3215/3270 console is line-based instead of character-based."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1556
+#: preparing.xml:1557
 #, no-c-format
 msgid "Linux on this platform runs either natively on the bare machine, in a so-called LPAR (Logical Partition) or in a virtual machine supplied by the VM system. Boot media differs depending on the runtime mode. For example, you can use the virtual card reader of a virtual machine, or boot from the HMC (Hardware Management Console) of an LPAR if the HMC and this option is available for you."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1565
+#: preparing.xml:1566
 #, no-c-format
 msgid "Before you actually perform an installation, you have to go over some design and preparation steps. IBM has made documentation available about the whole process, e.g. how to prepare an installation medium and how actually to boot from that medium. Duplicating that information here is neither possible nor necessary. However, we will describe here which kind of &debian;-specific data is needed and where to find it. Using both sources of information, you have to prepare your machine and the installation medium before you can perform a boot from it. When you see the welcome message in your client session, return to this document to go through the &debian;-specific installation steps."
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1582
+#: preparing.xml:1583
 #, no-c-format
 msgid "Native and LPAR installations"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1583
+#: preparing.xml:1584
 #, no-c-format
 msgid "Please refer to chapter 5 of the <ulink url=\"http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg244987.pdf\"> Linux for &arch-title;</ulink> Redbook and chapter 3.2 of the <ulink url=\"http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246264.pdf\"> Linux for IBM eServer zSeries and &arch-title;: Distributions</ulink> Redbook on how to set up an LPAR for Linux."
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1597
+#: preparing.xml:1598
 #, no-c-format
 msgid "Installation as a VM guest"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1599
+#: preparing.xml:1600
 #, no-c-format
 msgid "Please refer to chapter 6 of the <ulink url=\"http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg244987.pdf\"> Linux for &arch-title;</ulink> Redbook and chapter 3.1 of the <ulink url=\"http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246264.pdf\"> Linux for IBM eServer zSeries and &arch-title;: Distributions</ulink> Redbook on how to set up a VM guest for running Linux."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1609
+#: preparing.xml:1610
 #, no-c-format
 msgid "You need to copy all the files from the <filename>generic</filename> sub-directory to your CMS disk. Be sure to transfer <filename>kernel.debian</filename> and <filename>initrd.debian</filename> in binary mode with a fixed record length of 80 characters (by specifying <userinput>BINARY</userinput> and <userinput>LOCSITE FIX 80</userinput> in your FTP client). <filename>parmfile.debian</filename> can be in either ASCII or EBCDIC format. A sample <filename>debian.exec</filename> script, which will punch the files in the proper order, is included with the images."
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1626
+#: preparing.xml:1627
 #, no-c-format
 msgid "Setting up an installation server"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1628
+#: preparing.xml:1629
 #, no-c-format
 msgid "If you don't have a connection to the Internet (either directly or via a web proxy) you need to create a local installation server that can be accessed from your S/390. This server keeps all the packages you want to install and must make them available using NFS, HTTP or FTP."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1636
+#: preparing.xml:1637
 #, no-c-format
 msgid "The installation server needs to copy the exact directory structure from any &debian-gnu; mirror, but only the s390 and architecture-independent files are required. You can also copy the contents of all installation CDs into such a directory tree."
 msgstr ""
 
 #. Tag: emphasis
-#: preparing.xml:1645
+#: preparing.xml:1646
 #, no-c-format
 msgid "FIXME: more information needed &mdash; from a Redbook?"
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1655
+#: preparing.xml:1656
 #, no-c-format
 msgid "ARM firmware"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1657
+#: preparing.xml:1658
 #, no-c-format
 msgid "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."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1669
+#: preparing.xml:1670
 #, no-c-format
 msgid "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."
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1682
+#: preparing.xml:1683
 #, no-c-format
 msgid "Debian-provided U-Boot (system firmware) images"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1683
+#: preparing.xml:1684
 #, no-c-format
 msgid "Debian provides U-Boot images for various armhf systems that can load their U-Boot from an SD card at &armmp-uboot-img;. The U-Boot builds are offered in two formats: raw U-Boot components and a ready-made card image that can easily be written onto an SD card. The raw U-Boot components are provided for advanced users; the generally recommended way is to use one of the ready-made SD card images. They are named &lt;system-type&gt;.sdcard.img.gz and can be written to a card e.g. with <informalexample><screen>zcat &lt;system-type&gt;.sdcard.img.gz > /dev/SD_CARD_DEVICE</screen></informalexample> As with all images, please be aware that writing the image to an SD card wipes all previous contents of the card!"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1698
+#: preparing.xml:1699
 #, no-c-format
 msgid "If Debian provides a U-Boot image for your system, it is recommended that you use this image instead of the vendor-provided U-Boot, as the version in Debian is usually newer and has more features."
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1706
+#: preparing.xml:1707
 #, no-c-format
 msgid "Setting the ethernet MAC address in U-Boot"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1707
+#: preparing.xml:1708
 #, no-c-format
 msgid "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."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1715
+#: preparing.xml:1716
 #, no-c-format
 msgid "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."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1726
+#: preparing.xml:1727
 #, no-c-format
 msgid "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 <quote>MAC address</quote> 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."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1736
+#: preparing.xml:1737
 #, no-c-format
 msgid "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."
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1747
+#: preparing.xml:1748
 #, no-c-format
 msgid "Kernel/Initrd/Device-Tree relocation issues in U-Boot"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1748
+#: preparing.xml:1749
 #, no-c-format
 msgid "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 <quote>Starting kernel ...</quote>, but the system freezes afterwards without further output. These issues have been solved with newer U-Boot versions from v2014.07 onwards."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1757
+#: preparing.xml:1758
 #, no-c-format
 msgid "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 <quote>env default bootm_size; saveenv</quote> at the U-Boot prompt."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1768
+#: preparing.xml:1769
 #, no-c-format
 msgid "Another possibility to circumvent relocation-related problems is to run the command <quote>setenv fdt_high ffffffff; setenv initrd_high 0xffffffff; saveenv</quote> at the U-Boot prompt to completely disable the relocation of the initial ramdisk and the device-tree blob."
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1778
+#: preparing.xml:1779
 #, no-c-format
 msgid "Systems with UEFI firmware"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1779
+#: preparing.xml:1780
 #, no-c-format
 msgid "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."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1785
+#: preparing.xml:1786
 #, no-c-format
 msgid "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 lot of systems with UEFI but without CSM."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1795
+#: preparing.xml:1796
 #, no-c-format
 msgid "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."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1815
+#: preparing.xml:1816
 #, no-c-format
 msgid "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."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1831
+#: preparing.xml:1832
 #, no-c-format
 msgid "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 64-bit version of Windows 8 and there is unfortunately no standard way to disable it in the UEFI setup. 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."
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1853
+#: preparing.xml:1854
 #, no-c-format
 msgid "Disabling the Windows 8 <quote>fast boot</quote> feature"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1854
+#: preparing.xml:1855
 #, no-c-format
 msgid "Windows 8 offers a feature called <quote>fast boot</quote> to cut down system startup time. 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 <quote>boot</quote> 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 <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> feature has to be disabled within Windows."
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1870
+#: preparing.xml:1871
 #, no-c-format
 msgid "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."
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1882
+#: preparing.xml:1883
 #, no-c-format
 msgid "Hardware Issues to Watch Out For"
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1885
+#: preparing.xml:1886
 #, no-c-format
 msgid "USB BIOS support and keyboards"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1886
+#: preparing.xml:1887
 #, no-c-format
 msgid "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."
 msgstr ""
 
 #. Tag: title
-#: preparing.xml:1899
+#: preparing.xml:1900
 #, no-c-format
 msgid "Display-visibility on OldWorld Powermacs"
 msgstr ""
 
 #. Tag: para
-#: preparing.xml:1901
+#: preparing.xml:1902
 #, no-c-format
 msgid "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>."
 msgstr ""