20

While I know some facts about UEFI and Legacy and basic differences between them, like UEFI allowing for faster booting (I've checked this question already, but it doesn't answer mine), I have a bit of a different question(s):

I'm not sure if BIOS settings can have any influence on how the system works and if legacy settings can be the cause of hardware misbehaving, but I usually install my Linux systems in legacy mode, with boot priority legacy first. Is it ok this way or should I change either the boot priority to UEFI first, or everything adjusted to UEFI (this Lenovo G50-45 laptop came with Windows 8).

Also, on my laptop quite a few things don't work properly, whereas on Windows everything worked and I'm not sure where the fault lies. I only recall, that Windows wouldn't install with legacy settings, I had to change boot priority to UEFI first to be able to install it (Win 7 Ultimate x64).

Currently on *ubuntu (any variant) 15.04 I have issues with microphone not working (distorted, very weak sound) and Xorg crashes my entire session with Libreoffice in k3.19+. Tested with many distributions.

So, to conclude, which one is recommended for a flawlessly working system? Do Linux distributions work better with Legacy, or UEFI? (if there is any difference in terms of functionality of the system)

  • 1
    When you say legacy, it is not grub-legacy but legacy Boot or CSM where CSM - UEFI Compatibility Support Module (CSM), which emulates a BIOS mode. You can boot in CSM mode with gpt partitioned drives. I have used gpt with old BIOS systems since Ubuntu 10.10. Drivers with very new systems have always and always will be an issue unless vendors change and start supporting Linux directly. Linux developers have to reverse engineer all drivers and that takes a while before all that is in a current distribution. UEFI also being relatively new also has had need of lots of development also by vendors. – oldfred Jul 12 '15 at 3:52
  • I think it's like AMD vs Intel, they both works and have the same purpose but are from different vendors, of course one have features and problems that the other don't, it's all on you – deFreitas Nov 2 '18 at 12:07
24

For most hardware, the boot mode (EFI vs. BIOS) is irrelevant. The drivers Linux loads are identical in either case, as should be the performance. The main caveat here is that the hardware may be initialized in different ways depending on your boot mode, and if the Linux drivers make assumptions about how the hardware is initialized, one way or the other may work better. This sometimes made booting one mode or the other (usually BIOS mode) preferable in the past, but this type of problem is becoming rather rare today. This type of issue mostly affected video hardware and drivers, but in principle it could affect anything.

In your specific case, my suspicion is that you've got "bleeding-edge" hardware with poor Linux support, or perhaps hardware that requires special configuration to work correctly in Linux. Your best bet is to post separate questions about each specific device that's not working to your satisfaction. You can also test with both BIOS-mode and EFI-mode installations to determine empirically which one works better for you, since there is no way to accurately generalize which mode is best.

The correct answer to the question of which mode is best is: It depends. For instance:

  • If you're dual-booting with an OS that's already installed in one mode or the other, it's almost always best to boot Ubuntu (or any other Linux) in the same boot mode as the one that's already in use.
  • Using BIOS/CSM/legacy mode almost always complicates the boot process, as described in detail on this Web page of mine. The result is that enabling BIOS-mode booting makes problems more likely to crop up, especially if you've already got an EFI-mode OS installed.
  • Knowledge of BIOS-mode boot processes is more widespread, which can counter the preceding issue on a single-OS system.
  • As I've described, some hardware initialization issues can favor one boot mode or the other (usually BIOS mode is easier to get working). Such problems seem to be fading in frequency, though.
  • EFI-mode booting is usually a bit faster than BIOS-mode booting, although details differ from one OS to another.
  • Your choice of boot loaders is somewhat different. If you venture beyond the default GRUB, you might prefer something that's available in only one boot mode. Currently, this would tend to favor EFI, since there are some EFI-specific boot managers (gummiboot, rEFIt, and rEFInd) with no BIOS counterparts; but AFAIK the only BIOS-specific boot program for Linux without an EFI port or workalike are BURG and LOADLIN, both of which are (AFAIK) abandoned.
  • Secure Boot (a UEFI-specific feature) can help you control your boot process, preventing unauthorized code from running. If you want to, and if you're willing to put in the effort, you can even use Secure Boot to prevent Windows from running on your computer.
  • On some computers, GPT presents problems when booting in BIOS mode; but GPT is the standard for EFI. GPT offers some minor advantages on sub-2TiB disks, but is required on disks larger than that. (Assuming 512-byte logical sectors; but larger logical sectors are iffy for booting in BIOS mode, and are very rare on internal disks.)

If you need a more specific "BIOS" or "EFI" answer as to which you should use, you'll have to provide much more specific information about your setup.

  • Thank you, this clarifies it more than the previous post, although both are very helpful. This is a single OS system atm. – Inoki Jul 12 '15 at 18:02
  • I already posted bug reports about issues that concern me. One is located here bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1473435 and the other one discussed here ubuntuforums.org/showthread.php?t=2285503. – Inoki Jul 12 '15 at 18:07
  • great info(and alot of it) I also read good bit of your page. If I understand right, it boils down to: "It is recommended that you stick with UEFI unless there is a pressing need not to, this causes less problems and they are easier to fit if they come up." one of the problem you mentioned that may require a switch is video cards. I will be installing Ubuntu only on a new computer, with a Nvidia graphics card(gtx 970 if it matters) does the exception only come with older cards or, since I will not have Windows installed to install the firmware, will I need to use Legacy? – TrailRider Aug 8 '15 at 15:55
  • related follow up to my last comment(maybe it should be it's own question) if UEFI is recommended, as this is likely to be a Linux only computer(if for some reason I need to dual boot Windows would be on it's own HDD), should I leave secure boot enabled or disable it? What I gathered from your page I think you recommend leaving it enabled, but the page is so extensive that it's hard to digest on the first pass..... – TrailRider Aug 8 '15 at 16:01
  • I don't know of a database of reliable vs. unreliable video cards in either BIOS or EFI mode, so I can't comment on your video card choice. You'll just have to try it and work through any problems as you think best. As to EFI vs. BIOS on a Linux-only system, I personally would use EFI unless I knew of some specific problem with the computer; but for Linux-only use, it's really not likely to make a big difference. Secure Boot should work with Ubuntu, and may offer some small security benefits, so I'd leave it enabled unless it causes problems. – Rod Smith Aug 8 '15 at 21:46
12
            Do you need to boot from a
----------- partition more than 2 TiB in size?
|                       |
no                      yes
|                       |
|                       |
|               Do you REALLY need to boot from a
|               partition more than 2 TiB in size?
|   ------------        |
|   |                   yes
|   no                  |
|   |                   |
|----           Find a different solution!
|                       |
|------------------------
|   
Don't use UEFI.

Have I made my point clear?

There is no reason to use UEFI except if you want to boot Windows or if you want to boot from a partition more than 2 TiB is size. And you can always find a solution for the latter.

UEFI brings a heck of a lot of disadvantages with it and no advantages. Don't use it.

You're basically giving away control of your own computer to corporations. Don't do that, that's a bad idea.

You also will have problems with using certain tools which cannot deal with GPT (the only improvement from bios to uefi is support of GPT, everything else is disadvantages and there's many of them). It's not that much of a problem if you use GPT on an external or secondary HDD, but don't boot from it.

If you don't have an HDD bigger than 2 TiB to boot from, there's no problem in the first place. If you do have an HDD with more than 2 TiB to boot from but don't need to have a partition bigger than 2 TiB and don't need to have the beginning of a partition after the first 2 TiB, you also don't need GPT and therefore no UEFI. (So having a 4 TiB HDD with some partitions in the beginning and the last 2 TiB filled with 1 2 TiB is fine and works without GPT.)

As already stated above: This only is about the HDD you boot from. If you have an SSD for booting (which of course can't be that big because such big SSDs don't exist) and only want to use GPT for data storage, that's all fine and you don't need UEFI to access them.

The problem that support for hardware often is needed in form of a firmware for the hardware and a driver for the OS isn't solved by UEFI. It could've been but it isn't. UEFI simply sucks.

  • 8
    It's "GPT," not "GTP." At this point, GPT is well supported. Yes, some tools don't support it, but in general, that's a minor issue; and GPT offers some (admittedly minor) advantages over MBR beyond over-2TiB support, as detailed here. Your statement about giving control of your computer to corporations is unsupported and incorrect. The workaround for using an over-2TiB disk with MBR is a dangerous hack. This answer hasn't detailed any problems with EFI, beyond unsupported assertions of its badness. – Rod Smith Jul 12 '15 at 18:08
  • 4
    The hack to which you refer was basically re-writing a modified version of the firmware. That can be done with BIOS, too. Also, as a practical matter, booting a modern computer (which uses EFI) in BIOS mode will do nothing to prevent such an attack. – Rod Smith Jul 15 '15 at 12:46
  • 2
    The more storage space is taken up by bios or uefi, the bigger the storage chip has to be, the more opportunities to store malware there are. And uefi is big. Like really, really big. Like that's a bootloader which is bigger than the Linux kernel. There could in principal be malware for bios and someone even claimed to have it, but it never was shown. We now had several occurrences of uefi being used to get malware into a system or closer to hardware and we even had malware in uefi. Plus, uefi does all kinds of stuff which make no sense and could cause problems. Like the time has to be in – UTF-8 Jul 15 '15 at 17:43
  • 2
    In fact, BIOS replacement malware already exists. See blog.trendmicro.com/badbios-sometimes-bad-really-bad, for instance. The EFI spec does say that time should be in local time, but in practice, it doesn't matter. Rant on some more if you like; I won't respond further. – Rod Smith Jul 16 '15 at 12:45
  • 5
    UEFI is much better than BIOS even if you don't have disks bigger than 2TB. The boot process is 64-bit instead of 16-bit which makes UEFI much faster. Also secure boot prevents bootkit malware. Also hardware diagnostics can be very useful instead of beep codes.And more new features in the GPT partition table to prevent data corruption. I would not switch to BIOS if my computer has UEFI (I am writing this on a UEFI PC) – Suici Doga Mar 24 '16 at 4:08
0

There is at least one good reason to install Linux on UEFI. If you want to upgrade the firmware of your Linux computer, UEFI is required in many cases.

For example, the "automatic" firmware upgrade, that is integrated in the Gnome software manager requires UEFI. No UEFI means firmware upgrades via LVFS/ fwupd / fwupdmgr will not work. Which, in most cases, means no firmware upgrades on Linux, at all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.