25 04 | 2012

Debian: switch to UEFI boot

Written by Tanguy

Classified in : Homepage, Debian

UEFI logo: a cube with u, e and fi written on each visible face

For those interested, here is a way to install Debian and boot it with UEFI if you have an UEFI motherboard. Using UEFI with Debian requires expert knowledge so if you do not feel up to it, keep your BIOS system.

1  Background

UEFI is a specification for motherboard's firmwares which is replacing the old BIOS. For now, UEFI motherboards still include a BIOS compatibility layer.

The UEFI boot process is quite different from the BIOS one. It involves one specific piece of the motherboard's firmware, the UEFI Boot Manager, which is able to load boot loaders from FAT file systems on specially-typed partitions. It can offer a boot menu (boot: Debian from HDD, Windows from HDD, USB stick, DVD?), which can be configured from a running operating system.

So, basically, to boot a system with UEFI, you need two things:

  • to install an UEFI boot loader on a FAT-formated EFI System Partition;
  • to tell the UEFI Boot Manager to create an entry for that boot loader.

2  Installation or preparation

If you are installing a new Debian system, read the first part. If you already have a BIOS-bootable Debian system installed, read the second one.

In both cases you will have to use Debian testing, because stable's GRUB has problems with UEFI. You can also use Debian stable while taking only GRUB from testing though.

2.1  Installation of a new Debian system

There is no installer image for UEFI, so you can either:

  • make your own, by installing an UEFI boot loader to an USB stick, which will load a regular installer kernel and initrd;
  • use a regular BIOS installer image, using the compatibility mode of your motherboard.

The installer does not provide a convenient way to install an UEFI boot loader, so you are going to install a regular BIOS boot loader at first, and switch to UEFI later.

Use the expert mode and format your hard drive with a GUID Partition Table (GPT). Create a small partition (1 MiB would be far enough), type it as a BIOS Boot Partition (this is the untitled flag above the “bootable” one in Partman), do not format it and do not mount it: this will be needed for BIOS booting. Create another small partition (same kind of size), type it as an EFI System Partition (this is the“bootable” flag), format it as FAT and mount it on /boot/efi: this will be needed for UEFI booting.

Finish the installation as usual, installing GRUB for BIOS, and boot your new system.

2.2  Preparation of an existing Debian system for UEFI

You need to use a GUID Partition Table on your hard drive. If you used an MBR, you lost; you may try to convert it to GPT using a tool such as gdisk, but that means operating without a net, loosing your current boot loader in the process.

If there is no space left on your hard drive, use Debian Live to make some. Create a small partition (1 MiB would be far enough), type it as an EFI System Partition, format it as FAT and mount it (permanently, using the fstab) on /boot/efi (that directory will not exist, so create it first).

3  Switch to GRUB UEFI

Install the package grub-efi-amd64. Prepare it by running the command (assuming your hard drive is /dev/sda):

# grub-install /dev/sda

That will do three things:

  1. generate a GRUB image;
  2. install it to the EFI partition at efi/debian/grubx64.efi (relatively to this filesystem's root, which means /boot/efi/efi/debian/grubx64.efi in absolute);
  3. try to configure the UEFI Boot Manager (the motherboard's boot menu) to load it on start-up

That last step will fail. This is expected, because the UEFI Boot Manager can only be configured from an operating system that was started from UEFI. So if you stop here, you get an unbootable system.

Now, copy (a symlink would be relevant here, but that cannot be done on a FAT file system!) the GRUB image to that other path on the EFI System Partition: efi/boot/bootx64.efi (again, relatively to the ESP filesystem's root, which means /boot/efi/efi/boot/bootx64.efi in absolute). This is where the UEFI firmware looks for a boot loader when it has not been configured for a specific path, typically on removable media. Reboot to check that…

If that trick worked, you are now on UEFI-booted system. Run grub-install again, which should now succeed to configure the UEFI Boot Manager. Reboot to check that you get a “debian” entry on the motherboard's boot menu, and remove efi/boot/bootx64.efi which is no longer needed.


wednesday 25 april 2012 à 20:54 Simon said : #1

That would be nice to explain to readers why you think UEFI is interesting,

wednesday 25 april 2012 à 21:54 Tanguy said : #2

@Simon : The UEFI specification itself is complicated, inspired by systems such as DOS which should have been forgotten rather than taken as models, it allows for evil stuff such as vendor locking, implementations are often quite buggy, but it is already replacing BIOS in new motherboards and there may be a time when we no longer have BIOS compatibility. This time has not come yet, but when it does, if Debian (the Universal Operating System) is not prepared, it will not be installable on PCs (the most common computer platform) anymore, so it is best to start testing it now.

And for the boot process, I think it is far more clean and flexible than BIOS: instead of simply executing a hard-coded sector of the disk (which only allows to boot a single loader), it has a configured boot manager which can offer a choice between several operating systems and load regular files from a file system.

wednesday 25 april 2012 à 22:21 pingouin said : #3

Hello operator...
I thought that the kernel have a new hack to boot on uefi.
Hope the next Debian will have everything to install/boot easily with uefi motherboard.
I'm afraid to upgrade my hardware because there is no more new motherboards with classic bios.

wednesday 25 april 2012 à 22:38 Tanguy said : #4

@pingouin : I did not know that, I guess that would be something to turn the kernel itself into an EFI boot loader, although it would be strange move since such a possibility once existed for BIOS and was dropped in favor of using a dedicated boot loader (LILO, at that time, then GRUB).

For Debian, pieces are already here: Partman has a kind of support for EFI System Partitions, which is still perfectible, and GRUB does quite well with UEFI. What is missing is an integration with the Debian installer, I would say.

About hardware upgrades, I do not think you should worry for now, because new motherboards still include BIOS compatibility as far as I know.

thursday 26 april 2012 à 13:44 anonymouse said : #5

I've never seen a recommendation for an EFI System Partition to be soo small and I think it is a bit foolish to consider making it 1M. The general consensus of advice is to make it something of the order of 200M. If you will only ever use one Linux with one (nice) bootloader then you may get away with 1M for a long time to come, but if you dual boot or your bootloader changes you might well curse this decision.

Also reading the comments it seems you forgot to mention the most important reason for moving to UEFI, the ability to boot from disks >=2TiB (2TB disks are < 2TiB so they are ok).

thursday 26 april 2012 à 14:08 Tanguy said : #6

@anonymouse : 1 MiB is far enough for GRUB's core image, thanks to its modular design. Now, if you need to install other EFI stuff, such as monolithic boot loaders for other OSes, making it a bit larger would be a good idea indeed.

Now, for disks > 2 TiB, I think the only problem is that MBR cannot partition them beyont 2 TiB. But even with a BIOS, you can still use them normally as long as you partition them with GPT rather thant with MBR, can you not?

thursday 26 april 2012 à 16:01 Ben Hutchings said : #7

I've applied the EFI stub patches to Linux and they should be included in the next upload to sid (3.2.16-1).

You'll need to add a kernel postinst hook script to make this useful (copy the kernel and initrd to the EFI partition; update the boot variables). The linux-version command can help with this.

thursday 26 april 2012 à 16:15 Tanguy said : #8

@Ben Hutchings : Interesting, I am eager to see the documentation of that (for questions such as: where will it expect to find its initrd?) even if I think a flexible boot loader is preferable. So this is to load Linux directly from the UEFI without an intermediate boot loader, just as it used to be with BIOS and floppy disks in the old times, is it not? I wonder why this idea is reappearing years after it was dropped for BIOS, I guess UEFI makes it easier…

thursday 26 april 2012 à 17:50 Roderick Smith said : #9

I agree with anonymouse that 1 MiB is *WAY* too small for the ESP. Even if it's big enough now, there's too much chance that you'll need a bigger one in the future -- say, because you want to use another boot loader that requires storing the kernels on the ESP, or because you want to load EFI drivers, or because you want to dual-boot and the new OS requires more space than this. Also, the EFI specification requires that the ESP be FAT32, and IIRC, 1 MiB is too small for FAT32. (In practice, any FAT variety usually works, but the Windows 7 installer misbehaves badly if it finds anything but a FAT32 ESP. Other utilities might conceivably do the same.)

FWIW, I've done test installs of Debian in EFI mode by using an EFI boot loader to launch the installer's kernel and initial RAM disk. The process works, but it's got bugs similar to those in Ubuntu's EFI installer. The worst of these is (or was when I tested, several months ago) that it *always* erases the ESP. This means that it wipes out any existing boot loaders you might have for other OSes. The Ubuntu people claim this will be fixed with Ubuntu 12.04, but I don't know the status of this on Debian. Since Debian doesn't officially support EFI boots of its installer on x86-64 hardware, it's not really fair to call this a bug, IMHO.

One more point: In my experience, GRUB 2 is the *LEAST* reliable of the available EFI boot loaders. It's tricky to get working, on some systems it boots only some of the time, it can break at a moment's notice, and it often fails to detect other OSes. If it works in a default installation, then great; you might as well stick with it. If you have problems, though, my first advice (before even attempting to fix GRUB 2) is to switch to something else. The best is the kernel's EFI stub loader, but that's so new that it's not yet a practical choice for most people. (To be practical, it also requires either a good boot manager in the firmware, which most lack, or an ancillary boot manager like rEFInd.) ELILO was my favorite before the kernel's stub loader became available, but on some systems Fedora's patched GRUB Legacy works as well or better. You can get elilo in the Debian repositories, but not Fedora's patched GRUB Legacy. I've got a Web page with further details on all of these: http://www.rodsbooks.com/efi-bootloaders/.

friday 27 april 2012 à 07:26 Coudy said : #10

and when I use SW raid10 created with mdadm ? Can I boot with EFI ?

friday 27 april 2012 à 08:45 Tanguy said : #11

@Roderick Smith : Nice website about UEFI, good work!

@Coudy : Sure you can, just like you can with BIOS. In that perspective, BIOS uses a fixed sector to boot, while UEFI uses a specially-typed partition, but these approaches have no fundamental differences when it comes to using software RAID.

wednesday 22 august 2012 à 16:44 Steve McIntyre said : #12

I'm working on creating Debian EFI CDs now. Test builds at


Testing and feedback welcome!

tuesday 04 september 2012 à 19:48 alexey said : #13

it seems to me you forgot "update-grub" somewhere along the way, without it I don't have .efi files - only .mod ones
not tested yet, though

saturday 13 october 2012 à 16:54 scottnyc said : #14

hey steve mcintyre thx for this, installing it now

thursday 22 november 2012 à 16:34 r.ductor said : #15


Hi, thanks for this enlightening post.
I'm confused about one point:
in section 2 you write
" ... FAT and mount it on /boot/efi",
while in section 3 you mention the relative paths:

Please, could you check, and maybe give absolute paths for efi/...


thursday 22 november 2012 à 17:01 Tanguy said : #16

@r.ductor : There is an ambiguity here, indeed. These paths are relative to the root of the EFI System Partition filesystem, which means /boot/efi/efi/{boot,debian}/… in absolute. I indicated it in my article too.

thursday 22 november 2012 à 17:11 r.ductor said : #17

Thanks! Another point: some docs mention the path where efi autodetects a boot loader efi/boot/... in capital letters, take e.g. wikipedia
"The default location for the OS loader is \EFI\BOOT\boot[architecture name].efi, where the architecture name can be e.g. IA32, X64 or IA64."
according to your post this is not mandatory, can you comment on this?

thursday 22 november 2012 à 17:32 Tanguy said : #18

@r.ductor : Well, I cannot really. I think FAT is supposed to be case insensitive, so since I hate uppercase paths, I simply use lowercase ones…

tuesday 27 november 2012 à 03:33 ebeck said : #19

I installed Grub 2 to my MBR, my bad. I don't want the pain and anguish. I will just switch the boot order in the BIOS, put the Windows Boot Manager at #1, and Win 7 boots without Grub loading at all. Screw it!!!

wednesday 06 february 2013 à 12:13 Florent said : #20


Thx for this howto, but I have a problem at the end :

I have copy grubx64.efi on /boot/efi/EFI/boot/bootx64.efi

The motherboard's system have the entry and start grub. but when I select the kernel to load I have this error :

error couldn't terminate EFI services.
Chargement de Linux 3.2.0-4'amd64

And I need to hardreboot...

Any Idea ?

wednesday 06 february 2013 à 12:50 Florent said : #21

I have installed grub via SID and it's OK now. (Testing = NOK for me)

thursday 28 march 2013 à 19:19 Endy said : #22

Thanx Tanguy :) I was precisely trying to do that.

saturday 20 april 2013 à 08:24 Giovanni said : #23

I have a problem that seems related to this discussion but my knowledge of linux is not so deep. I would like advice.
I've installed Debian Wheezy in a SSD on a new PC with Asus P9X79 mb. I followed the automated path for partition, and I ended up with 3 partitions, swap root and probably boot. So far so good.

I removed the SSD with Debian and I inserted a HD where I installed Windows 7 from scratch. When I tried to switch back the Windows 7 HD with the Debian SSD the mb sees it but does not recognize it as bootable. Somebody tells this could happen because the MB removes from its memory the references to boots that are not found at boot time, so swapping disks can be bad.
Do you confirm ? is there a workaround (apart reinstalling all and crossing my fingers)?
Thanks, g.

monday 22 april 2013 à 09:49 Tanguy said : #24

@Giovanni : Your lead to this problem is probably correct. With UEFI, the boot entries are defined in the motherboard's flash memory during the OS installation. So, when you installed Debian, it was the only operating system available so it defined only a boot entry for itself. Then when you installed Windows to another hard disk the same thing occurred, and the (now invalid) Debian boot entry was removed. You may want to install everything to a single drive, or have both drives connected at the same time.

tuesday 14 january 2014 à 10:17 Olivier Mehani said : #25

1 MiB for /boot/efi is too small for a FAT32 system and, seemingly for a FAT16 one too. It appears that the minimum for a FAT32 system is 32MiB, but that didn't quite work for me (probably rounding to cylinder boundaries or something like that).

I ended up with a 30 MiB BIOS boot partition, and a 34.5 MiB FAT32 partition. This satisfies, at least, the partition manager.

thursday 19 june 2014 à 11:49 Milton said : #26

This helped me so much! I have bookmarked and come back to this article several times. Thank you! Thank you! Thank you!

wednesday 10 september 2014 à 22:10 Chavoux said : #27

Just one question: I already have a Debian system booting fine in legacy mode. If I change it to boot from the UEFI partition, will my legacy boot (MBR) stop working? I know I cannot boot Windows 8 when booting in legacy mode. Will this also be true for Debian afterwards? (I still have some other OS's that I will probably boot in legacy mode, so will like not to have to switch to UEFI mode everytime I want to boot Debian).

wednesday 10 september 2014 à 22:33 Tanguy said : #28

@Chavoux : There is no theoretical incompatibilities between an UEFI system partition and a functional MBR boot code on the same device, actually I am already using that combination on live USB sticks. Using them requires a motherboard firmware able to let you choose between them, and able to boot both. Now about Windows, I really have no idea, but for Debian, I know that it can be booted either in BIOS or UEFI mode, and that GRUB 2 is currently designed so it is possible to install it for BIOS and for UEFI on the same operating system and storage device, although the corresponding Debian packages are still declared to be in conflict.

thursday 11 september 2014 à 12:21 Chavoux said : #29

@Tanguy : Thanks a lot! I have one more (theoretical) question: I see in GParted that my first partition (NTFS recovery)starts on sector 2048. So I assume that the MBR is still on the first part of the hard-drive like normal (old style) disks (and will be used in legacy mode)? The second partition is then my ESP partition (fat32) marked as bootable and what UEFI boot normally use? So the two should not interfere with each other at all? Can I chainload +1 from the MBR to the ESP drive? Or do I have to switch between the two modes every time in the firmware?

I installed the MBR with the default GRUB2 that came with Kali Linux (Debian based) and then changed GRUB2 to the UEFI version as described in your article. I just wanted to be sure that if I stuff up anything during the installation of the UEFI bootloader, I could fall back to legacy mode (and I might still need legacy mode for some of my older non-UEFI-enabled distros). But since Debian is my main OS and Windows my gaming OS, it would be nice to have them both booting in UEFI mode without needing to enter the firmware settings every time.

thursday 11 september 2014 à 14:45 Tanguy said : #30

@Chavoux : With a GPT, you get a protective or a compatibility MBR. But remember that GRUB cannot fit in the 512 byte-long space that is dedicated to boot code in MBR, where it only places a small code that jumps to another place where it has stored its core image. In pure MBR, that would be the space left between the end of the MBR and the first cylinder, but in GPT there may not be such a space, so you should create a (very small, as will onl hold GRUB's core image, so 1MB would be sufficient) unformatted partition dedicated for that, that you will tag as “bios_grub” (this is in fact a specific partition GUID) so GRUB knows it can put its core image on it.

You cannot chainload an EFI system partition, what you can chainload is some code the current firmware (BIOS or UEFI) can run. In the UEFI case, that would be an EFI program, which would be some file.efi located on the EFI system partition.

“Normal” UEFI implementations should offer a boot-time menu, called the boot manager, to let the user choose the operating system he wants to run; in your case it would offer you a choice between Windows and Debian, but it may not since many UEFI implementations are just crap.

sunday 14 september 2014 à 20:36 Chavoux said : #31

Thanks for all the info. At the end of the day I got it working with all my distros installed in a round-about way. First off, to install some of the distro's I had to boot in legacy mode since booting in UEFI mode did not even pick up the DVD/CD (even though the boot order was set to start from DVD drive before the hard-drive). So I installed all my distros (including Debian) in legacy mode. I did install the grub-efi-amd64 package. Then I installed Ubuntu (the only DVD that I could start from UEFI mode) and set it to install GRUB to the /dev/sda drive. Somehow it automatically installed to the ESP partition and added all the distros installed in legacy mode as well. All of them except for one, now boots in UEFI mode and all of them (except Windows8.1) can boot in legacy mode as well. So I never had to do the last step from the article... :-) In my case the UEFI firmware allowed me to choose either UEFI mode or legacy mode, the harddrive already had an ESP FAT32 partition (with the Windows boot loader) as well as a small (1 MB) unformatted space in the beginning (where I assume the legacy MBR is stored). Maybe this could be useful for somebody else.

monday 15 september 2014 à 09:14 Tanguy said : #32

@Chavoux : In UEFI mode, you should be able to boot from optical discs that have an ElTorito boot code for UEFI and not for BIOS.

Now for Ubuntu, as for Debian, the fact that it installs GRUB to the EFI System Partition (mind that “ESP Partition” is a case of RAS Syndrom, the redundant acronym syndrome syndrome) is the expected behaviour if you start the installer in UEFI. Also, the fact that GRUB detects and offers you to boot the other operating systems if finds is the expected behaviour, only it cannot cross the BIOS/UEFI barrier (i.e. GRUB for UEFI cannot offer you to boot a BIOS-based OS).

monday 16 march 2015 à 12:27 3ronco said : #33

Unfortunately it didn't work for me. First i installed rEFInd BootManager onto a SD Card and disabled CSM Boot in the BIOS. rEFInd boots and i can select my Debian Jessie Installation from a MBR Disk. '/sys/firmware/efi' returns useful values so i'm definitely booted in EFI mode.
On a (new) GPT-based Disk (protective MBR) i've created the EFI-System partition (FAT-32 formated) and mounted on '/boot/efi'.
I've checked the Boot Flag via Gparted. I removed 'grub-pc-*' and installed 'grub-efi-*' packages.
I used grub-install on my boot disk (same new disk that contains EFI-SP) and efibootmgr to create the NVRAM boot entry.
I've tried it with and without an extra BIOS boot partition. It just doesn't work although rEFInd on my SD card boots fine but no grub boot at all. Without the rEFInd-SD card I just get a message from the BIOS to reboot and to select a proper boot device ... like there is no start partition at all although i can see my NVRAM boot entry in the BIOS.
My Gigabyte UEFI BIOS doesn't offer disabling secure boot but i can't tell anyway if it's used. The only difference i see is the rEFInd efi executable is signed while debian's grubx64.efi isn't?
Switched back to MBR for now ... Any other hints?

(PS@UEFI: "Now ... let's use a boot procedure so error prone that a single cough breaks it and so complicated like explaining a three-year-old the theory of relativity is easy.")

monday 30 may 2016 à 03:53 phoenix6142 said : #34

The best way to get Kali Linux 2.0 Sana working on EFI Systems is explained in this very easy to follow YouTube Video: http://y2u.be/XC7yyov8ZmI

Write a comment

What is the second letter of the word mgzej? :