Understanding UEFI and GPT: Installing Windows and Kubuntu on a single disk

Remember those times when the BIOS was 16-bit with an address space of 1 MB, and all the information about the boot loaders was written to the MBR? More flexible technologies have long been in place: UEFI (BIOS replacement), and GPT (MBR replacement).

Background: It took me recently on my home desktop to put 2 systems to distinguish between environments. Kubuntu for development on Ruby on Rails (because I work remotely), and Windows for all sorts of toys in my spare time. I want to note that a few years ago it was quite simple: one section for Windows and one section for Linux, the bootloader was recorded in the MBR. However, the technologies are not standing still, and it turned out that the dual boot setting has now changed somewhat.

So, let's begin.

Terminology

UEFI (Unified Extensible Firmware Interface) was developed by Intel as a replacement for BIOS (Basic Input Output System). Unlike the 16-bit BIOS, UEFI works in 32-bit or 64-bit mode, which allows you to use much more memory for complex processes. In addition, UEFI looks nice and there is mouse support.

')
GPT (GUID Partition Table, GUID Partition Table) is part of the UEFI specification. UEFI uses GPT just like the BIOS uses the MBR .
The main difference between GPT and MBR, in my opinion, are:

• Number of sections : MBR supports only 4 sections. It is possible and more, but only through the extended partition, which is just a hack of restrictions. GPT supports up to 128 partitions.
• Disk size : MBR supports disks up to 2TB, while GPT supports up to 9.4 Zettabyte (= 9.4 × 10 ^ 21 bytes, or conventionally 1000 TB)
• Boot order : the BIOS previously loaded the MBR, and it contained boot addresses for each disk partition. Now UEFI reads GPT, finds all efi partitions in the table (they contain loaders), and loads them into memory. Let us examine this with an example a little later.

What we do:

Install the following OS on an empty HDD with a size of 1 TB.

• Windows 8.1 x64 . Windows supports booting from GPT starting with Windows 8 for a 32 bit architecture and with Windows Server 2003 and Windows Vista for 64 bits ( Source ).
• Kubuntu 15.04 . In theory, any distribution kit that supports Grub2 is suitable, I personally prefer Kubuntu.

NB: Motherboard supports UEFI

Disk breakdown

First, install Windows 8, because it will automatically use GPT.
The breakdown will look like (sorry for the curve snapshot):



Windows by default creates 4 sections:

1. Recovery (300MB). Obviously, it is used to restore the system. Leave as is.
2. EFI partition (100MB). Marked as system type (they don’t like to call things by their technical names in Microsoft). The loaders are written here.
3. MSR (128MB, Microsoft Reserved Partition ). For me, it remains a mystery why it is needed. There is no data there, just an empty space, reserved for some obscure purposes in the future.
4. The main section. We will divide it into 3: 200 gigs for Windows, 500 gigs for the partition for the data and the rest of the space for the time being we will leave unallocated (format it later when installing Kubuntu).

Let's skip the Windows installation itself, because everything is standard and understandable in it.

Now boot from USB to Kubuntu Live.

Check EFI section:

kubuntu@kubuntu:~$ efibootmgr BootCurrent: 0003 Timeout: 0 seconds BootOrder: 0000,0003,0001 Boot0000* Windows Boot Manager Boot0001* Hard Drive Boot0003* UEFI: JetFlashTranscend 16GB 

Boot0000 - Windows bootloader
Boot0001 - default bootloader
Boot0003 - flash drive with Kubuntu Live
Please note that the list of boot loaders is not tied to one physical disk as in the MBR. It is stored in NVRAM.

We can also immediately see what is in this section by mounting it:

 kubuntu@kubuntu:~$ sudo mkdir /media/efi kubuntu@kubuntu:~$ sudo mount /dev/sda2 /media/efi 

There will be the following files:

 EFI |--Boot | |--bootx64.efi #   |--Microsoft |--Boot |--bootmgfw.efi #    |--#    

Make sure all is well. Now we continue partitioning the disk (through KDE Partition Manager).



The first five sections remain the same. Notice how Kubuntu defined the sections:

• sda2 was defined as FAT32. This is almost true, because EFI-type file system is based on FAT, only with strict specifications.
• sda3 (MSR) is not defined, because there is no file system there.

It remains for us to only format the partition for Kubuntu in ext4, and select the partition under the swap.

A few words about the swap. It is recommended to select from swap from SQRT (RAM) to 2xRAM. Since I have 16 GB of RAM, then at a minimum I need 4 GB of swap. Although I can hardly imagine situations in which it will be used: I do not translate a desktop into hibernate, and I do not use heavily heavy programs that eat more than 16 gigs.

PS When formatting a partition in the swap Partition Manager may produce errors that are related to the fact that Kubuntu automatically mounts any swap partition, but these errors do not affect the result.

So, the final breakdown:



Now the most important thing is for the correct dual boot. When installing Kubuntu, it is important to choose where to install the bootloader:



We indicate, of course, the EFI section.

After the Kubuntu installation is completed, go to the system and check which files appeared on the efi partition (no longer need to be mounted):

 user@kubuntu:~$ sudo ls /boot/efi/EFI Boot Microsoft ubuntu user@kubuntu:~$ sudo ls /boot/efi/EFI/ubuntu grub.cfg grubx64.efi MokManager.efi shimx64.efi 

We look how the list of loaders looks now:

 user@kubuntu:~$ efibootmgr -v BootCurrent: 0002 Timeout: 0 seconds BootOrder: 0002,0000,0003,0001 Boot0000* Windows Boot Manager HD(2,96800,32000,c4f37e07-0441-4967-a1ac-75fb5a36e4f3)File(\EFI\Microsoft\Boot\bootmgfw.efi) Boot0001* Hard Drive BIOS(2,0,00) Boot0002* ubuntu HD(2,96800,32000,c4f37e07-0441-4967-a1ac-75fb5a36e4f3)File(\EFI\ubuntu\shimx64.efi) Boot0003* ubuntu HD(2,96800,32000,c4f37e07-0441-4967-a1ac-75fb5a36e4f3)File(EFI\Ubuntu\grubx64.efi) 

Here’s what it looks like when booting:



Also, these boot loaders are immediately accessible from UEFI (in the old BIOS, this would have been impossible - there was only a choice of disk, he just did not know what boot loaders were):



And finally: in order for the dual boot to work properly, it is necessary to turn off the fast boot in Windows. This is such a bad feature that can lead to data loss.