(add a note about accessing the firmware on 'fast boot' systems) |
|||
(6 intermediate revisions by 3 users not shown) | |||
Line 15: | Line 15: | ||
* If your system came with Windows XP pre-installed, it almost certainly does not have a UEFI firmware. | * If your system came with Windows XP pre-installed, it almost certainly does not have a UEFI firmware. | ||
* If you have an Intel-based Apple system, it has a UEFI firmware, though there are special considerations involved in installing and booting Fedora on Apple systems due to the special Apple boot interface built on top of UEFI. It is best to refer to Apple-specific instructions rather than follow this generic UEFI guide, for Apple installations. | * If you have an Intel-based Apple system, it has a UEFI firmware, though there are special considerations involved in installing and booting Fedora on Apple systems due to the special Apple boot interface built on top of UEFI. It is best to refer to Apple-specific instructions rather than follow this generic UEFI guide, for Apple installations. | ||
In addition, Fedora only supports '''64-bit UEFI'''. Very few devices support 32-bit UEFI only, such as first-generation Bay Trail tablets or early Intel-based Macintosh PCs. | |||
== UEFI-native and BIOS-native installations == | == UEFI-native and BIOS-native installations == | ||
Line 28: | Line 30: | ||
* '''If you boot a Fedora live or install medium in UEFI-native mode and then install Fedora, it will perform a UEFI-native installation.''' | * '''If you boot a Fedora live or install medium in UEFI-native mode and then install Fedora, it will perform a UEFI-native installation.''' | ||
* '''If you boot a Fedora live or install medium in BIOS-native mode and then install Fedora, it will perform a BIOS-native installation.''' | * '''If you boot a Fedora live or install medium in BIOS-native mode and then install Fedora, it will perform a BIOS-native installation.''' | ||
== Will Secure Boot eat my babies? == | |||
No. Your babies are safe. | |||
Here's what you need to know about Secure Boot: | |||
* It is not the same thing as UEFI. It is just one part of UEFI. You can boot in UEFI native mode with Secure Boot disabled. | |||
* You can turn it off in the firmware interface. | |||
* Turning it off is not ''turning off UEFI'', in any sense of that phrase. Disabling Secure Boot does not automatically trigger BIOS compatibility mode. However, using BIOS compatibility mode implicitly disables Secure Boot, as there is no way Secure Boot can possibly work when booting in BIOS compatibility mode. | |||
* Secure Boot per se is fairly unlikely to be the cause of any problems you have installing Fedora on a UEFI system. If you have problems it is far more likely that they are caused by some of the other considerations discussed on this page. | |||
* When Secure Boot is enabled Fedora will prevent you doing certain things like loading un-signed kernel modules. This is to preserve the boot chain integrity that Secure Boot provides: if Fedora allowed loading un-signed modules in Secure Boot mode, for instance, it would be trivial to defeat the Secure Boot protections. You can happily do a UEFI-native install of Fedora and then turn Secure Boot on and off in your firmware, and Fedora should boot either way, enforcing the restrictions if you turn it on, not enforcing them if you turn it off. | |||
In sum: don't worry too much about Secure Boot, and don't confuse "turning off Secure Boot" with "turning off UEFI" (or, to put it correctly, using BIOS compatibility mode). | |||
== Accessing the firmware interface == | == Accessing the firmware interface == | ||
Line 159: | Line 175: | ||
If you encounter an error during bootloader installation, you should report a bug. If your bug is considered a duplicate of an existing bug, this cannot always be trusted: it is a good idea to save the {{filename|anaconda.log}}, {{filename|program.log}} and {{filename|syslog}} files from your installation attempt, and attach them to the bug report. These files can be found in {{filename|/tmp}} during the installation process, and in {{filename|/var/log/anaconda}} on the installed system after installation is complete - even if you cannot boot the installed system due to the bootloader installation error, you may be able to access the filesystem from another operating system or live image. | If you encounter an error during bootloader installation, you should report a bug. If your bug is considered a duplicate of an existing bug, this cannot always be trusted: it is a good idea to save the {{filename|anaconda.log}}, {{filename|program.log}} and {{filename|syslog}} files from your installation attempt, and attach them to the bug report. These files can be found in {{filename|/tmp}} during the installation process, and in {{filename|/var/log/anaconda}} on the installed system after installation is complete - even if you cannot boot the installed system due to the bootloader installation error, you may be able to access the filesystem from another operating system or live image. | ||
=== You have failed to provide all existing bootloader entries when changing the boot order === | |||
{{admon/note|Advanced class|This note covers a rather advanced case where you are manually modifying the UEFI boot manager configuration with the {{command|efibootmgr}} utility. If you're not doing that and don't even know what it means, don't worry about it.}} | |||
Some vendor UEFI firmware has a bug where if you change the boot order without specifying '''all''' currently existing bootloader entries, then the firmware will recreate all the "default" boot entries for the system, even if they already exist. Do this enough times and eventually the number of boot entries can become large enough that they won't fit in the UEFI NVRAM and the system will become unbootable. The workaround to prevent this problem ever occurring is relatively simple: always supply all existing bootloader entries when changing the boot order. |
Latest revision as of 18:19, 7 February 2014
Introduction
This page attempts to explain some of the things to take into consideration when installing Fedora on systems with UEFI firmwares. It is not a comprehensive description of UEFI theory or practice, but an attempt to provide the most basic information you may need to know. You may find references like this blog post by Adam Williamson, Rod Smith's site, or - for the technically inclined - Matthew Garrett's blog posts on UEFI helpful for more detailed background and technical explanation.
UEFI is a firmware standard for computers. Modern PC systems are increasingly equipped with UEFI firmwares, rather than a firmware of the 'BIOS' type. It is most correct to talk generically about "the firmware" and specifically about "UEFI" or "BIOS" - UEFI and BIOS are both types of firmware. But you may see the term "UEFI BIOS" (or even just "BIOS") incorrectly used to refer to a UEFI firmware, or the phrase "go into the BIOS" to mean "go into the configuration UI for your UEFI firmware". Just be aware that these usages are strictly incorrect, and try to remember what they really mean!
Do I have a UEFI firmware?
This is a hard question to answer entirely definitively, but we can give you some useful indicators.
- If your system came with Windows 8 or later pre-installed, you can presume it has a UEFI firmware.
- Some firmwares will mention the word 'UEFI' on screen during early initialization of the system.
- If you know how to access your firmware UI ('the BIOS', as many still refer to it) - usually by pressing Esc or Del or something similar at boot time - there may well be a mention of 'UEFI' somewhere in the interface, if it is a UEFI firmware.
- If you have a PC system dating to 2008 or earlier it's quite unlikely it has a UEFI firmware, though there are some systems this old with a UEFI firmware.
- If your system came with Windows XP pre-installed, it almost certainly does not have a UEFI firmware.
- If you have an Intel-based Apple system, it has a UEFI firmware, though there are special considerations involved in installing and booting Fedora on Apple systems due to the special Apple boot interface built on top of UEFI. It is best to refer to Apple-specific instructions rather than follow this generic UEFI guide, for Apple installations.
In addition, Fedora only supports 64-bit UEFI. Very few devices support 32-bit UEFI only, such as first-generation Bay Trail tablets or early Intel-based Macintosh PCs.
UEFI-native and BIOS-native installations
It is important to realize that most systems with UEFI firmware also implement a BIOS compatibility mode, also sometimes referred to as a CSM. This means they can boot in a way that imitates a BIOS firmware, executing bootloader code from a disk's MBR and looking to the operating system just like a BIOS firmware.
There is no standard for how this choice (and other boot configuration choices, as we'll see later) should be shown to the user in the firmware UI, so we cannot tell you precisely how your firmware shows you this choice, if your firmware has this feature. Some just have a sort of 'toggle switch' for flipping between 'BIOS mode' and 'UEFI mode'. Some will let you explicitly choose to boot a given disk in 'BIOS mode' from the firmware interface. Some will let you configure the boot "disk" order to include both BIOS-native and UEFI-native boots of different disks or installed operating systems.
If you boot a system with UEFI firmware in this BIOS compatibility mode, once the system is booted, it will act to all intents and purposes exactly like a BIOS system.
An installed operating system will usually only be configured to be bootable in either BIOS-native mode or UEFI-native mode. We can refer to these as 'BIOS-native installations' and 'UEFI-native installations'.
- If you boot a Fedora live or install medium in UEFI-native mode and then install Fedora, it will perform a UEFI-native installation.
- If you boot a Fedora live or install medium in BIOS-native mode and then install Fedora, it will perform a BIOS-native installation.
Will Secure Boot eat my babies?
No. Your babies are safe.
Here's what you need to know about Secure Boot:
- It is not the same thing as UEFI. It is just one part of UEFI. You can boot in UEFI native mode with Secure Boot disabled.
- You can turn it off in the firmware interface.
- Turning it off is not turning off UEFI, in any sense of that phrase. Disabling Secure Boot does not automatically trigger BIOS compatibility mode. However, using BIOS compatibility mode implicitly disables Secure Boot, as there is no way Secure Boot can possibly work when booting in BIOS compatibility mode.
- Secure Boot per se is fairly unlikely to be the cause of any problems you have installing Fedora on a UEFI system. If you have problems it is far more likely that they are caused by some of the other considerations discussed on this page.
- When Secure Boot is enabled Fedora will prevent you doing certain things like loading un-signed kernel modules. This is to preserve the boot chain integrity that Secure Boot provides: if Fedora allowed loading un-signed modules in Secure Boot mode, for instance, it would be trivial to defeat the Secure Boot protections. You can happily do a UEFI-native install of Fedora and then turn Secure Boot on and off in your firmware, and Fedora should boot either way, enforcing the restrictions if you turn it on, not enforcing them if you turn it off.
In sum: don't worry too much about Secure Boot, and don't confuse "turning off Secure Boot" with "turning off UEFI" (or, to put it correctly, using BIOS compatibility mode).
Accessing the firmware interface
As with BIOS-based systems, there is no universal standard way to access the firmware interface. It usually involves pressing Esc or Del or a function key, or possibly some kind of key combination, during early boot.
Windows 8 systems with "Fast Boot"
Systems that come pre-installed with Windows 8 are supposed to support something Microsoft refers to as "Fast Boot", which means firmware initialization must complete very quickly. Sometimes this means it is difficult or impossible to access the firmware interface in the usual way (by pressing a special key during boot). If your system had Windows 8 pre-installed, and you are struggling to access the firmware interface, you can hold down the Shift key while clicking Reboot in Windows 8, and this should give you a menu with an option to reboot to the firmware interface. See mjg59's blog post for more details on this.
Should I do a UEFI-native or BIOS-native installation?
If you intend for Fedora to be the only operating system on your computer, and you don't have an existing very specific partition layout you wish to preserve, it really doesn't matter too much. There are not many practical differences between the two for you as the user of a system with a simple configuration like this. You may be more familiar with how BIOS booting works, and wish to use BIOS compatibility booting; or you may wish to learn about how UEFI boot works, and do a UEFI-native installation. You can only gain the security features of the Secure Boot UEFI option if you do a UEFI-native installation.
If you intend for Fedora to co-exist with another, already-installed operating system, you should almost always follow this rule:
Even if you know you have a UEFI firmware, it is not safe to assume any existing operating system is a UEFI-native installation. It is quite common for systems to be released with UEFI firmwares, but BIOS-native operating system installations.
- If your existing operating system is Windows 8 or later and came pre-installed, it is almost certainly a UEFI-native installation, and so you should do a UEFI-native installation of Fedora.
- If your existing operating system is Windows Vista pre-SP1 or earlier (Windows XP) and came pre-installed, it is almost certainly a BIOS-native installation, and so you should do a BIOS-native installation of Fedora.
- If your existing operating system is some form of Linux, look for a directory named
/sys/firmware/efi
. If it exists, you have a UEFI-native installation and should do a UEFI-native installation of Fedora. If it does not, you have a BIOS-native installation and should do a BIOS-native installation of Fedora. - If your existing operating system is Windows and you are not sure whether it is a BIOS-native or UEFI-native installation, there are some indications you can check.
- If you are running Windows 8 or later, you can press Start+R (to open the Run dialog) and type 'msinfo32' and hit Enter (to run the msinfo32 utility). With System Summary selected on the left, there should be a BIOS Mode entry on the right. If it says Legacy, you have a BIOS-native installation, and should do a BIOS-native installation of Fedora. If it says UEFI, you have a UEFI-native installation, and should do a UEFI-native installation of Fedora.
- You can also try opening the file
C:\Windows\Panther\setupact.log
in a text editor, and searching for the text "Detected boot environment". If it says "Detected boot environment: EFI", you have a UEFI-native installation, and should do a UEFI-native installation of Fedora. If it says "Detected boot environment: BIOS", you have a BIOS-native installation, and should do a BIOS-native installation of Fedora. - You can also check the layout of your hard disk using a tool such as Disk Management - press Start+R, type 'diskmgmt.msc', and hit Enter. If your hard disk contains an 'EFI System Partition', you almost certainly have a UEFI-native installation, and should do a UEFI-native installation of Fedora. If it does not, you almost certainly have a BIOS-native installation, and should do a BIOS-native installation of Fedora.
UEFI and BIOS bootability of Fedora media
Here are some general considerations related to which modes a given Fedora medium (CD, DVD, USB stick) will be bootable in.
- Pretty much any Fedora medium of any kind should always be BIOS-bootable.
- Any Fedora image correctly written to a disc (not a USB stick) should be UEFI-bootable.
- A Fedora USB stick written with one of the direct write methods described at How_to_create_and_use_Live_USB#quickstarts should be UEFI-bootable.
- A Fedora USB stick written with
livecd-iso-to-disk --format --reset-mbr --efi
should be UEFI-bootable: for more details, see How_to_create_and_use_Live_USB#litd. - A Fedora USB stick written with How_to_create_and_use_Live_USB#luc ought to be UEFI-bootable in many cases, but this method is not as reliable as direct write or livecd-iso-to-disk, and can depend on the format of the stick prior to running the tool.
- A Fedora USB stick written with any other method, including third-party utilities such as UNetbootin, is quite likely to not be UEFI-bootable. If you wish to do a UEFI-native installation, are using a USB stick as your medium, and cannot persuade it to boot in UEFI-native mode, you may need to check How_to_create_and_use_Live_USB for instructions on writing a reliably UEFI-bootable USB stick.
Booting the Fedora installer or live image in UEFI-native and BIOS-native modes
As we've already seen, the way to choose whether to do a BIOS-native or UEFI-native installation of Fedora is to boot your installation media in the correct way. As we've also already seen, we can't give you precise instructions on doing this, because the interface varies between systems. However, we can give you some pointers.
To do a UEFI-native boot:
- Ensure your Fedora medium is UEFI-bootable - see the previous section.
- Make sure all options in the firmware's 'boot' section relating to BIOS compatibility are disabled.
- If your firmware shows you different choices for booting the same disc or USB stick, choose the one with 'UEFI' in its name, or without 'BIOS' in its name.
- If your firmware offers a boot menu, again, look for the 'UEFI' or non-'BIOS' option.
To do a BIOS-native boot:
- If your firmware just has some kind of switch between 'UEFI mode' and 'BIOS mode', set it to 'BIOS mode'.
- If your firmware has an option to turn BIOS compatibility on or off, make sure it's on.
- If your firmware shows you different choices for booting the same disc or USB stick, choose the one with 'BIOS' in its name, or without 'UEFI' in its name.
- If your firmware offers a boot menu, again, look for the 'BIOS' or non-'UEFI' option.
- If none of the above is working, try intentionally writing a non-UEFI-bootable USB stick, using the livecd-iso-to-disk utility without passing the --efi parameter, or by deleting the EFI system partition from the USB stick, and boot from that.
- If none of the above works and you really need to do a BIOS-native installation with Fedora 19 or earlier, you can boot your medium in UEFI-native mode and pass the parameter
noefi
to the installer from the boot menu. With Fedora 20, you must passnoefi inst.updates=https://www.happyassassin.net/updates/updates-1047904.img
. However, this usage of noefi is incorrect, not supported by the kernel developers, and will not work from Fedora 21 onwards.
Checking which mode you booted the Fedora installer or live image in
If you are not sure which mode you booted in, there are a few ways to check. In current Fedora releases, the initial boot menu you see looks rather different in each case. If you do a BIOS-native boot, it will look something like this:
If you do a UEFI-native boot, it will look something like this:
Note that the BIOS-native boot menu is centered on the screen, has a title, and has multi-colored text. The UEFI-native boot menu has its entries towards the upper-left of the screen, has no title, and all the text is white. The menus may differ slightly in other ways depending on whether you are booting a live or non-live image, but the differences described here are specific to the UEFI / BIOS distinction.
Once the installer image has booted or the live image has booted and you have started the installer, you can run the command grep platform /tmp/anaconda.log
to determine the mode the installer believes you have booted in (and hence whether it will perform a UEFI-native or BIOS-native installation). When using the non-live installer, you can press ctrl+alt+F2 to access a terminal to run the command. If you see:
anaconda: bootloader EFIGRUB on EFI platform
then you have booted in UEFI-native mode and will get a UEFI-native Fedora installation. If you see:
anaconda: bootloader GRUB2 on X86 platform
then you have booted in BIOS-native mode and will get a BIOS-native Fedora installation.
GPT and MBR disks
There's lots of fun technical details about GPT and MBR disks, but here's all you need to know: if you're doing a BIOS-native installation, you want to use an MBR-formatted disk (unless your disk is over 2.2TB in size). If you're doing a UEFI-native installation, you want to use a GPT-formatted disk. If you follow all the instructions above you should not have to worry about this, but it's worth knowing.
If you make your partitioning choices during installation such that all existing partitions on your target disk will be erased (or the disk is blank to start with), the installer will automatically reformat it to the most appropriate format as part of the installation process. But if you are installing to a disk and not completely wiping it, Fedora cannot reformat your disk for you, as this would destroy the data on it.
Again, though, this shouldn't be something you need to worry about if you follow the above instructions. If you wind up in a situation where you think you need to change your disk format, you should probably ask an expert on IRC, Ask Fedora or the Fedora Forums to make sure.
Partitioning for UEFI
If you are doing a BIOS-native installation, even on a system with a UEFI firmware, you don't need to make any special considerations about partitioning. It doesn't matter that you have a UEFI firmware: to all intents and purposes, everything at this point is just as if you were using an old-fashioned BIOS.
If you are doing a UEFI-native installation and use automatic partitioning, the installer will create a correct partition layout for you (except in the case that you have an MBR-formatted disk and do not choose to reformat it: see the "Common errors" section below for more details).
If you are doing a UEFI-native installation and using custom partitioning, though, be aware that you must include an EFI system partition mounted at /boot/efi
as a part of your partition layout.
If you are installing alongside an existing UEFI-native operating system, there should be an existing EFI system partition (it'll be a fairly small partition near the start of the disk, and the installer should identify it as an EFI system partition), and the neatest choice is probably to mount this existing EFI system partition at /boot/efi
: it is perfectly safe and indeed intended for multiple operating systems to share an EFI system partition. You can create a new one instead, though, if you like, and this should work fine.
If you are installing to a fresh, empty disk, or wiping an existing operating system entirely, you should make sure to create a new partition of the EFI System Partition type, and set its mount point to /boot/efi
. It's hard to say precisely what size to make it - there isn't really a convention yet - but unless you're really strapped for space, you may as well make it a few hundred MB just to make sure there's plenty of space. It probably doesn't need to be this large, but on a 50GB disk, a 500MB EFI system partition is only 1% of your space anyway.
If you fail to do this correctly, Fedora will give you the rather cryptic error message "you have not created a bootloader stage1 target device". What it's really telling you is you didn't configure an EFI system partition correctly.
You may also see this error if you attempt to do a UEFI-native install to an MBR disk (even if you correctly create an EFI system partition). As stated above, this is unlikely to be what you really want to do. If you find yourself encountering this error even after you're sure you've configured the EFI system partition correctly, you almost certainly have an existing BIOS-native operating system, and you should be doing a BIOS-native installation of Fedora, not a UEFI-native installation.
You may also want to be aware that, in Fedora 20 and later, the /boot
directory must be on a plain ext2/3/4 or xfs partition - not a btrfs volume, or an LVM volume - and this applies to UEFI-native as well as BIOS-native installs. If your root partition is btrfs or LVM-backed, you must create a plain /boot partition.
Booting the installed system
After a UEFI-native Fedora installation, you should have a UEFI boot manager entry named Fedora, selecting which should boot the installed Fedora system. The installer will configure this to be the default boot menu entry, and so booting the system without any special actions should cause Fedora to start.
If you have other UEFI-native operating systems installed, it is again difficult to tell you precisely how to select them for booting, as it depends on your particular firmware's interface. Fedora's boot menu may include entries for your other operating systems, and these may work, but it's known that in some cases they may not: in this case you must find out how to select a different EFI boot manager entry from your system's firmware interface. The entry for Windows is typically named Windows Boot Manager.
After a BIOS-native Fedora installation, you should simply configure your firmware to boot in BIOS compatibility mode from the disk to which you installed Fedora, just as with an actual BIOS firmware.
Common errors and what to do about them
You have not created a bootloader stage1 target device
As noted above, one of the most commonly-encountered errors in a UEFI-native install is "you have not created a bootloader stage1 target device". If you see this error, it almost certainly means one of two things: you are using custom partitioning and you have not configured an EFI system partition to be mounted at /boot/efi
, or you are attempting to do a UEFI-native installation to an MBR-formatted disk.
In the first case, you should just run through custom partitioning again and make sure you set up the EFI system partition correctly.
In the second case, though, it is almost certainly the case that you do not really want to do a UEFI-native installation: if you have an MBR-formatted disk and you are not deleting all its contents, it's very unlikely that this is really what you want. Fedora will not allow a UEFI-native installation to an MBR-formatted disk, even though it is permitted by the UEFI specification, because it is very likely that permitting this would cause unwitting users to render existing OS installations unbootable, and also we are not confident that all UEFI firmwares will successfully boot UEFI-native operating systems from MBR-formatted disks, though they are supposed to be capable of this.
If you are absolutely sure that you want to perform a UEFI-native installation to an existing MBR disk without reformatting the disk entirely, your only option is to attempt a non-destructive conversion to the GPT format. That is outside the scope of this guide, but instructions are available on various sites, including here at Rod Smith's site, but this is not a safe operation and you should ensure you have a backup of all your data before attempting it.
Bootloader installation errors
The other commonly encountered issue with UEFI native installations is some kind of failure during bootloader installation. There can be various reasons for this: bugs in the system firmware, bugs in the kernel, malformed errors in the UEFI boot manager preventing addition of new entries or removal of old ones from working, or the space in the firmware where EFI boot manager entries are stored being full (or being erroneously reported to be full by the firmware or the kernel).
If you encounter an error during bootloader installation, you should report a bug. If your bug is considered a duplicate of an existing bug, this cannot always be trusted: it is a good idea to save the anaconda.log
, program.log
and syslog
files from your installation attempt, and attach them to the bug report. These files can be found in /tmp
during the installation process, and in /var/log/anaconda
on the installed system after installation is complete - even if you cannot boot the installed system due to the bootloader installation error, you may be able to access the filesystem from another operating system or live image.
You have failed to provide all existing bootloader entries when changing the boot order
Some vendor UEFI firmware has a bug where if you change the boot order without specifying all currently existing bootloader entries, then the firmware will recreate all the "default" boot entries for the system, even if they already exist. Do this enough times and eventually the number of boot entries can become large enough that they won't fit in the UEFI NVRAM and the system will become unbootable. The workaround to prevent this problem ever occurring is relatively simple: always supply all existing bootloader entries when changing the boot order.