Announcement

**Snowhog** · Oct 24, 2012, 08:08 PM

Nearly any HP printer.

**Qqmike** · Jan 22, 2014, 11:47 AM

Edits to the GRUB 2 Guide, January 2014 & some rambling

Edits to the GRUB 2 Guide, January 2014 & some rambling

Went through it, Posts #1 and #2, editing for typos, wording, content. Pretty sure I fixed most of the old or broken links. I added some new tips here and there. I also re-tested a few things, at the grub> prompt, trying the new Super Grub2 Disk, built a quick GRUB 2 flash drive, etc.

There's a lot of somewhat decent material there, but sometimes difficult to navigate through without links within between text items.

Big one I caught was this: It should be /etc/default/grub; but in a few places I had written it as /etc/grub/default.

update-grub vs grub-mkconfig: it should be the latter, but people are still successfully using the former as well, and that's OK; but I did make a comment about it. The Manual does not mention update-grub. update-grub is nice, faster, for example after removing old kernels and such.

sudo grub-install --root-directory=DIR, VERSUS sudo grub-install --boot-directory=DIR
The Manual has switched to mentioning only the newer second way; some say that the first way --root= won't work in 12.04; both ways work for me; many writers still use the root= way. You decide, or try whatever does work for you. I tried to insert them both at several places to show alternatives.

Added topics:

-- How to search the Kubuntu forums using google (site:kubuntuforums.net).
-- How to remove old kernels (quoting many of you on it).
-- Included a list of GUI GRUB 2 help-repair-editing packages (but I have not yet tried them myself, but it appears others have done so successfully).
-- Edited installing GRUB 2 from a live CD.
-- Although I have not yet experimented with UEFI or Secure Boot, I made more mention of it, linking specifically to the new sub-forum:
"UEFI issues, links: note the subforum started by Steve Riley:
UEFI Assistance:
https://www.kubuntuforums.net/forumd...EFI-assistance
You'll find excellent tutorial material on UEFI, GPT, Secure Boot, other boot managers (UEFI will boot your Kubuntu OS; you don't need GRUB to do the booting; GRUB is also a boot manager, though; however, there are also other boot managers you can use instead of GRUB; etc.), legacy issues, and just about everything else you might want to know as you get started with UEFI."

chroot? --> Question I would have for experts ... To check out some of the chrooting methods for installing GRUB 2 via live CD. I gave two links, but there are several on the Internet. Making sense of them? Why does one need to chroot? Is it so you can also run sudo grub mkconfig to generate a boot menu? I'm not clear on the whole thing with chrooting. And the how-to's don't seem to provide much tutorial-level guidance.

Ramblings ...

I suppose the present how-to is fairly Ok-good, better than some, got a lot of special topics; but each how-to I found includes material you won't find in other how-to's. None of them is particularly tutorial; mine may be somewhat more than others; dedo's is known to be for the basics (but the advanced topics are limited); drs305's work is definitely tutorial but he has mostly stopped his and instead his material has been placed in the official Ubuntu documentation/Wiki, and again, deferring to the offical Manual. Herman has some neat special topics, he also has deferred to the Manual, his last update being one or two years ago. The official GRUB 2 Manual is expanding in content, but it is certainly not very tutorial unless you already know what you are doing; but, thankfully, they are developing the Manual over time. I also noticed that the how-to's are not as well developed for GRUB 2 as they were for GRUB Legacy, and the how-to's are sometimes years out of date, not kept up, having limited topics, the authors deferring to the official Manual.

I don't sense the enthusiasm I had enjoyed among the GRUB legacy writers. I'm not as enthused. Not about GRUB 2 as I was about Legacy. It's just not as fun ... unless you might be a programmer/dev/scripting expert. Let's face is: about all an average user can do is run grub-install and grub-mkconfig, or edit the etc/default/grub file, hope, cross your fingers, and see what happens. Or copy a script someone else has written. With GRUB legacy, almost anyone could get in deep, experimenting, trying this and that, almost randomly trying out config edits, and you'd have a fair amount of successful boots.

Well, I'm not an expert at any of this; I'm only an experienced Legacy user. The only reason I wrote the present GRUB 2 Guide was because I felt like I should! that you guys needed a how-to here at Kubuntu, Grub 2 being new at the time, a bit buggy, and me being the GRUB 1.97 guy. Thankfully, I've noticed that many of you stepped in, taking over the Grub work, starting back in 1.97 with dibl, MoonRise, toad and others, and recently in Grub 2 with SteveRiley, Vinny, oshunluvr, Detonate, Snowhog, GreyGeek, and--thankfully--way too many others to list here. I've also simplified my play. Down to maintaining simpler personal systems, one or two OSs, 8.04 and now replacing with 12.04--both work perfectly and without effort on my part, one or two disks, nothing elaborate (like chainloading off a thumb drive to a hard drive to configfile a 2nd hard drive to ..., but gosh it used to be fun!).

Not real sure how much more work I want to put into this how-to. I'll try to at least incorporate any new commands or changes to commands. Of course ... thankfully, Post #1 is at it's word-count limit! (OS: Let's keep that at 100,000 characters! ;-) )

**Qqmike** · Jan 23, 2014, 05:36 AM

... Forgot to mention something else. Not a big deal, but I'd be curious. For GRUB tinker-ers messing around ...
While checking the how-to, I quickly repeated some of the experiments, and frankly, experienced some bugginess (or something) at the GRUB prompt grub>. In fact, three times it froze up and would not accept any input from the keyboard (a standard, $20 Logitech, wired), not even Esc. Sometimes a command would argue with me, sometime Tab completion seemed moody. I did, finally, get some things to go. I suspect there is some bugginess in GRUB 2, but since I have not been following the dev communications, I can't tell. I have read things that suggest GRUB 2 may have some rough edges. For example, cautions to match up the same GRUB versions (e.g., GRUB on a Live CD with the same GRUB 2 version on the GRUB HDD installation you are trying to repair); or, some people--apparently--finding that grub-install root= may not work after a certain Kubuntu version (10.xx); in one of the black-and-white diagnostics scrolling by as I'd get hung up, some mention was made about my keyboard input being slow or some such thing, but, as I say, I was not trying to be scientific, I was simply ripping through some standard command-checking on standard PC hardware).

If any of you play with this, I'd be curious how things go for you. Sorry I didn't systematically perform and record the experiments, I was assuming what I was doing was routine stuff and would fly unquestionably. I will play with this as I have more time.

For example--if you want to play--build a quick bootable flash drive (FAT 32. then follow the how-to instructions to install GRUB 2 to it) that will give you a GRUB 2 prompt upon booting your machine, grub>. No need to have any grub.cfg on the thumb drive. Or, just boot your machine normally, get your GRUB 2 boot menu, click the "c" key, to get your GRUB 2 prompt grub>. Then, at the grub prompt grub>, experiment with the "4 ways to boot an OS": direct booting, symlinks, configfile, and chainloader. See what happens, see if you are able to freely get around.

(Afterthought ... I actually did build my GRUB 2 thumb drive with the same GRUB 2 I was attempting to play on as I rebooted the machine to a grub>, so that wasn't the problem I was having: same GRUB 2 on the thumb drive that was on the HDD I was trying to boot to ...)

**Qqmike** · Mar 02, 2014, 05:18 PM

GPT, UEFI -- Study Guide

GPT, UEFI -- Study Guide (actually, a suggested Study Guide ...)

With all the chatter about GPT, UEFI, and Secure Boot, and most new computers shipped with some or all, it's probably not a bad time to look into it.

So, to get started, I'm suggesting a study guide of sorts, consisting of some links and some comments. I've noticed a few comments around here about feeling lost or behind on the UEFI-GPT business. Actually, this is what I am using, and I feel it looks like a good way to jump in. Unfortunately, I do not have a new machine to run tests on. Fortunately, I am planning to buy a laptop very soon--and THAT is why I'm trying to get oriented on the issues. I don't think I'm done with this "study guide," but I wanted to get this posted as a starting point to help some of you get up on this stuff. I have read all but a few of the links, and feel I need to go back and read it again (and some of it a third time, maybe).

FWIW, as of March 2014, my summary impressions are the following.
In theory, UEFI+GPT looks like a good thing, especially for setting up multi-booting--thanks to the convenience of the UEFI boot manager and/or rEFInd, having all bootloaders (or kernels for EFI's Stub Loader) all in one directory /EFI on the ESP.
At the present, it does seem that bugs must be worked out in the hardware/firmware and the various manufacturers' implementations of UEFI.
To keep it simple, with highest probability of success, perhaps it makes good sense to keep things matched up: UEFI+GPT or BIOS+MBR, but not too much mixing. Windows, as I understand it, requires this match-up.
If you have a BIOS-MBR system, can you include a GPT disk? It seems so, and it shouldn't be too difficult. The GPT disk can be for data, or could be bootable (but then remember to include your BIOS Boot Partition).
If you have a BIOS PC, you could run it using a GPT layout; again, remember to include your BIOS Boot Partition.
If you have a UEFI PC, you could use CSM to run in legacy mode; but, again, you'd need your BIOS Boot Partition.
Seems best, if possible, to keep things matched up: UEFI+GPT or BIOS+MBR.
To use UEFI, you must have a 64-bit OS.
And the OS, the bootloader(s), and the disk utilities you use must be GPT-aware.

CONTENTS

> First, I'll place all the links up front, for your convenience.

> Then I list, sequentially, suggested topics and the links (again), along with some comments or tips I've managed to extract or glean from the material.

> Then, in a final section, I've included some quotes and useful text I snipped from the subforum "UEFI Assistance," including some good posts by S-R.

The Links -- A summary list

Kubuntu subforum:

General > Misc. Linux Info > UEFI assistance
https://www.kubuntuforums.net/forumd...EFI-assistance

Started by SteveRiley, this is your source for specific comments and specific tips, here at Kubuntu. And it is where you should post specific questions about specific systems or UEFI implementation and use.

To search the Kubuntu forum using google:
site:kubuntuforums.net "additional drivers" + sound -Windows
site: gives you results from only the site you type; "quotes" gives you exactly what you put in quotes; + will make sure that word is there; - (minus sign) will omit the word.

Links in the order they appear in the text-discussion below

MBR: http://en.wikipedia.org/wiki/Master_Boot_Record
BIOS: http://en.wikipedia.org/wiki/BIOS
UUID: http://en.wikipedia.org/wiki/Univers...que_identifier
GUID: http://en.wikipedia.org/wiki/Globally_unique_identifier

GPT: http://en.wikipedia.org/wiki/GUID_Partition_Table
GPT: Make the Most of Large Drives with GPT and Linux, by Rod Smith
http://www.ibm.com/developerworks/linux/library/l-gpt/
(You only need the 03 July 2012 PDF cited at the end of the first paragraph as it supersedes the rest of the web page article.)

Linux on 4KB-sector disks: Practical advice, by Rod Smith
http://www.ibm.com/developerworks/li...-sector-disks/

The 1 MiB gap, or alignment:
https://en.wikipedia.org/wiki/1_MB_p...1_MB_alignment

MiB vs MB reminders:
http://en.wikipedia.org/wiki/MiB
http://en.wikipedia.org/wiki/Binary_...ndard_prefixes

UEFI, Unified Extensible Firmware Interface:
http://en.wikipedia.org/wiki/Unified...#DISKDEVCOMPAT

ESP, EFI System partition: http://en.wikipedia.org/wiki/EFI_System_partition#Linux

UEFI, ESP: Managing EFI Boot Loaders for Linux: Basic Principles
http://www.rodsbooks.com/efi-bootloa...rinciples.html

Managing EFI Boot Loaders for Linux: EFI Boot Loader Installation
http://www.rodsbooks.com/efi-bootloa...tallation.html

Using rEFInd: http://www.rodsbooks.com/efi-bootloaders/refind.html

Using the Kernel's EFI Stub Loader: http://www.rodsbooks.com/efi-bootloaders/efistub.html

Linux on UEFI: A Quick Installation Guide: http://www.rodsbooks.com/linux-uefi/

Unified Extensible Firmware Interface
https://wiki.archlinux.org/index.php...ware_Interface

EFISTUB (including booting in different ways: rEFInd and UEFI shell)
https://wiki.archlinux.org/index.php/EFISTUB

Converting to or from GPT
http://www.rodsbooks.com/gdisk/mbr2gpt.html

Converting a BIOS/MPR installation to UEFI/GPT
https://www.kubuntuforums.net/showth...on-to-UEFI-GPT

UEFI
https://help.ubuntu.com/community/UEFI

More -- Definitely recommended reading:

AdamW:
UEFI boot: how does that actually work, then?
https://www.happyassassin.net/2014/0...lly-work-then/

Peter Jones:
The EFI System Partition and the Default Boot Behavior
http://blog.uncooperative.org/blog/2...tem-partition/

------------------------------------------------------------------------------------
------------------------------------------------------------------------------------
The main 'text, topics, comments' starts here ----->
------------------------------------------------------------------------------------

BIOS-MBR

This is how you've been doing things with your PCs (and, actually, it is how many of you will continue doing it for some time to come). BIOS, Basic Input Output System, is a software interface between an operating system and platform firmware. It has been around a long time through the evolution of the original IBM PC and IBM compatible PCs, dating back to 1981, and starting with x86 CPU PC architecture in 1978. The BIOS is a software program, called firmware. It comes on a chipset (in a special Read Only Memory) located on the motherboard of your computer.

The Master Boot Record (MBR) is an area of the beginning of a disk (a hard drive, a flash drive) that contains key data used by the BIOS of the PC to start--to "boot up"--the PC. The MBR consists of 512 bytes (a byte is 8 bits). In this "old" BIOS-MBR scheme, usually, a standard sector is 512 bytes. So, the MBR occupies the first sector of a disk. What's in it? The first 446 bytes of the MBR contains bootloader code (e.g., GRUB). (This bootloader code is often referred to as Stage 1 code). The next 64 bytes of the MBR contains the partition table for the disk. The remaining two bytes of the MBR contains the ending boot signature (AA 55--Or end-of-file--in hexadecimal, 0xAA55).

And here's how this whole thing works: You turn on the PC. The central processing unit of the PC (the CPU) starts the BIOS. The BIOS finds a bootable disk and checks the MBR of that bootable disk for bootloader code Stage 1 and turns control over to Stage 1. Stage 1 bootloader code looks at the partition table (in that MBR), finds a bootable partition containing an operating system (OS), and passes control to Stage 2 bootloader code, which in turn loads the OS into RAM and passes control to the OS (which then runs in RAM--random access memory).

So what's wrong with this? For many of you, for the near future, there's nothing wrong with this, it works rather well. But there are two possible issues:
(1) Your hard disk drive (HDD) may be too large for the partition table of the MBR to handle.
(2) You may buy a new computer and find out that it runs on the newer UEFI-GPT system-scheme, and this will be discussed below.

As for (1), the traditional BIOS-MBR system restricts the total disk size to be 2 TiB or less (similarly, the limit on partition sizes is 2 TiB). This is because of the 64-byte partition table of the MBR. If you follow the math on it, you'll see where the 2 TiB limit comes from. See this for a fuller explanation:
Post #2 above, GRUB 2, continued from Post #1, the section called "GPT: GUID Partition Table,"
https://www.kubuntuforums.net/showth...l=1#post193706

I wouldn't spend too much time on BIOS-MBR, but, that said:
See a graphical representation of the MBR here: http://en.wikipedia.org/wiki/Master_Boot_Record
And for BIOS, see http://en.wikipedia.org/wiki/BIOS

Fact is, the MBR has other problems: It is easily damaged (as many people learn, and then find themselves visiting TestDisk to recover their MBR and their partitions). It is limited to four primary partitions, or more if you make one primary partition an extended partition and put logical partitions "inside" the extended partition (but then, because the logical partitions are connected as a linked data structure, if you change or damage one of them, it may mess up access to others; furthermore, this arrangement is somewhat clumsy and inconvenient).

And by the way, there's an issue of where to put Stage 2 bootloader code. In the paragraph above, we said that Stage 1 code (in the first 446 bytes of the MBR) passes control to the Stage 2 bootloader code. Traditionally, usually, on PCs, the Stage 2 GRUB bootloader code has been placed right after the MBR but before the start of the first partition. (This always works out OK, whether the first partition starts at sector 63 (= the second "Track" on the disk), or whether it starts at 2048 sectors (of 512 B/sector = 1 MiB). No matter: there is always room for Stage 2 to fit right after the MBR in the BIOS-MBR scheme. However, there is no guarantee that the Stage 2 code will be safe there! It could become damaged or be damaged by some other over-writing software actions, and there's no backup for it on the disk (a good reason to copy using dd your MBR to a thumb drive, just in case).

The GPT Solution

GPT, developed by Intel, defines a new scheme for the layout of a partition table on a hard disk. GPT = GUID Partition Table, where GUID = Globally Unique Identifier, and GUID is a specific implementation (example) of the UUID, the Universally Unique Identifier (there are many types or examples of GUIDs; GPT uses one such implementation).

The UUIDs and GUIDs are 128-bit values, stored as 32 hexadecimal digits, separated by hyphens into five groups. (Hexadecimal is base 16, with 16 basic symbols, for the sixteen "numbers" zero through 15: 0-9, A, B, C, D, E, F; each hexadecimal digit represents 4 bits ( observe: 2**4 = 16); 128 bits = 32 hexadecimal digits; a byte (= 8 bits) is represented by two hexadecimal digits.) For canonical forms and more on these "unique" identifiers used in software, see the following two links:
http://en.wikipedia.org/wiki/Univers...que_identifier
http://en.wikipedia.org/wiki/Globally_unique_identifier

For GPT, two excellent sources to start with are:

GUID Partition Table
http://en.wikipedia.org/wiki/GUID_Partition_Table

and

Make the Most of Large Drives with GPT and Linux, by Rod Smith
http://www.ibm.com/developerworks/linux/library/l-gpt/
(You only need the 03 July 2012 PDF cited at the end of the first paragraph as it supersedes the rest of the web page article.)

This is the sort of material that you'll probably want to read and re-read a couple times, and refer back to.

-----> Note the author of the IBM PDF is Rod Smith.
He also maintains the boot manager rEFInd, and he's the author of the GPT disk utility GPT fdisk (which includes the family gdisk, cgdisk, and sgdisk).

Tip: About sectors
As you read material on GPT and later UEFI, watch for mention of "sectors" and sector sizes. As I said above, traditionally, for BIOS-MBR, we have become used to the 512-byte sector size. That is changing. Watch for examples of this as you read the material. Also, keeping with the 512-byte sector, keep an eye on how partitioning is changing.
Examples:
"Hard disk manufacturers are transitioning to 4,096-byte sectors." [with 512-byte logical sectors ... etc.]
"Since Windows Vista, the first partition usually starts after a gap of 2,047 sectors at LBA 2,048 as part of its new 1 MiB partition alignment policy,..." (Note: With 512-byte sectors, 2048 sectors is 1,048,576 bytes = 1 MiB. You often see this if you run "sudo fdisk -lu" from Konsole to see how your disk is partitioned.)
"...on most large disks produced since early 2010: These disks use 4KiB physical sectors but 512-byte logical sectors. This discrepancy creates potentially severe performance issues if partitions aren't aligned on physical sector boundaries. Partitioning tools released since late 2010 generally handle this well, but if you're using older tools, be sure to create properly aligned partitions." (From Rod Smith's IBM PDF, 2012.)

--> Remember, with LBA, logical block addressing, the first sector is sector 0 or LBA 0, the second sector is sector 1 or LBA 1, etc.

A couple references inserted here ...

Linux on 4KB-sector disks: Practical advice, by Rod Smith
http://www.ibm.com/developerworks/li...-sector-disks/

The 1 MiB gap, or alignment: This is discussed somewhat in the GPT and UEFI articles of Wikipedia; and also here:
https://en.wikipedia.org/wiki/1_MB_p...1_MB_alignment

MiB vs MB ...
--> Btw, in case you haven't thought about megabyte MB (10**6) versus mebibyte MiB (2**20), the former is base 10, the latter is base 2 (binary). See the explanation and table here:
http://en.wikipedia.org/wiki/MiB
http://en.wikipedia.org/wiki/Binary_...ndard_prefixes

OK, back to the GPT ... The advantages of the GPT vs the MBR are several. The GPT scheme overcomes the 2 TiB disk limit of the MBR scheme; you can have 8.6 billion TiB with GPT, assuming 512-byte sectors. GPT supports the new firmware interface UEFI (discussed below). By default, with GPT you can have 128 partitions, and do away with the primary vs logical partition distinction. For a full list of advantages, see the PDF by Roderick W. Smith, IBM:

Make the most of large drives with GPT and Linux, Rod Smith
http://www.ibm.com/developerworks/linux/library/l-gpt/

The picture to have in your mind ...

-- MBR. This is easy:

Picture the first 512 bytes of your disk (HDD or USB). That's where the MBR goes. Then there's a gap. Then the first partition starts.

There may be a gap of 62 sectors (62 * 512 = 31,744 bytes, so the first partition starts after 32,256 bytes = 31,744+512 = 63 sectors). Or, the first partition may start at LBA 2048 = 1 MiB = 1,048,576 bytes, leaving a gap of 1,048,576 - 512 = 1,048,064 bytes. Or, the gap may be some other number of bytes. Stage 2 of the GRUB 2 bootloader (or other bootloaders) usually fits into this gap.

-- GPT. This is also easy, but flexible!

At the start of this article:
http://en.wikipedia.org/wiki/GUID_Partition_Table
on the right, is an excellent graphic of the GPT layout and scheme.

In the GPT scheme, space is still set aside for a traditional 512-byte MBR, at location LBA 0 (the first 512-byte sector of the disk); and it is called the "protective MBR." (If the GPT sector size is greater than 512 bytes, then there will be a gap after the MBR and before the Partition Table Header.)

Then, at the start of the GPT is the header, the Partition Table Header, starting at the second sector of the disk, or LBA 1.
And then comes the partition table, or "partition entry array," at LBA 2, containing the partition entries, one entry for each partition.
Then come the actual partitions on the disk.
The last sector of the disk (LBA -1) contains the secondary or backup Partition Table Header; and the sector preceding the last sector (LBA -2) contains the secondary or backup partition table.

The thing to note is that the sector size need not be 512 bytes; it can be anything.
And this: "The EFI stipulates a minimum of 16,384 bytes be reserved for the partition table array, so there are 128 partition entries reserved, each 128 bytes long."

--> Thus, you can have 128 partitions with a GPT setup.

If you know the sector size, you can always picture where you're at on the GPT disk. (By the way, of course, both the bootloader and the OS must be aware of the sector size used.)

The LBA 34 thing ...
For example, if the sector size is 512 bytes ...
... and if the partition table has a full 128 entires, each 128 bytes long, that's 16,384 bytes, or 32 sectors (each 512 bytes). Add 1 sector for the protective MBR and 1 sector for the Partition Table Header, you get 34 sectors (each 512 bytes). So LBA 34 (the 35th sector) would be the first available address for the start of the first partition (but for optimal partition alignment, you may choose a larger sector number for starting the first partition, such as the 1 MiB mark = 2048 sectors (each 512 bytes)).

- - - - -

To use GPT, the following must be GPT-aware:

the kernel, the bootloader, and low-level disk partitioning utilities.
--> Since 2010, you've got this support in Linux (including support from the Kubuntu installer).
GRUB 2 is GPT-aware.
The graphical GParted (built on libparted) is GPT-aware.
The text-mode GPT fdisk is GPT-aware. Rod Smith is its author, and the family of utilities includes gdisk, cgdisk, and sgdisk). (But note that the older fdisk family is not GPT-aware: fdisk, cdisk, sdisk.)

- - - - -

Creating a GPT formatted disk and partitioning:
Simply use GParted as usual except start with Devices, Create Partition Table, click Advanced, and select gpt. Or use GPT fdisk (gdisk, cgdisk, sgdisk).

- - - - -

GPT works with both the BIOS firmware interface and the UEFI firmware interface (see below for more on UEFI).

BIOS Boot Partition

When using GPT with BIOS, Stage 1 of GRUB 2, called boot.img will fit into the first 446 bytes of the protective MBR, but you need room for the second stage of GRUB 2, the core.img. With the GPT layout, there is no gap, no room, for core.img (in GPT, the Partition Table Header starts immediately after the 512-byte MBR). Thus, you need a BIOS Boot Partition for the core.img of GRUB 2.

Flag: Using the graphical GParted, create the BIOS Boot Partition, and set the flag on it as: bios_grub; using gdisk, it is of type EF02.

Size: Minimum size is 32 KiB, but most people are using 1 MiB (which also serves certain optimum partition-alignment goals--which, btw, these goals are also served by modern partitioning tools since about 2010).

Note that the BIOS Boot Partition does not have a filesystem on it; it only holds raw binary code (the core.img stage of GRUB 2).

- - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -

UEFI

UEFI = Unified Extensible Firmware Interface
UEFI is a software interface between an operating system and platform firmware.
UEFI is intended to replace BIOS.
GPT is a subset of the UEFI specifications.
And UEFI+GPT is intended to replace BIOS+MBR.

CSM, Legacy mode: UEFI must also support the MBR scheme. Even under GPT, you have the Protective MBR in the first sector of the disk. UEFI can boot in legacy mode, using the MBR, and using its Compatibility Support Module, CSM.

An excellent source to start with is:
Unified Extensible Firmware Interface
http://en.wikipedia.org/wiki/Unified...#DISKDEVCOMPAT

Like BIOS, UEFI is software (called firmware) that comes on a chipset (in a special Read Only Memory) located on the motherboard of your computer. But unlike BIOS, UEFI is flexible, more sophisticated, capable of reading filesystems, in theory makes it easier to have multiple bootloaders and OSs on the disk(s) (by use of the "ESP"),

(U)EFI System Partition: ESP

A UEFI implementation uses a special partition called the EFI System Partition, or ESP.
The ESP contains all EFI bootloaders for all the OSs installed in the UEFI setup. It also contains device drivers, utilities, and data files (logs), especially files to be used in the pre-boot environment.

Specs of the ESP:

-- It might be convenient if the ESP is the first partition listed in your partition table (the GPT) (Microsoft recommends it be the first partition).
-- Size: It can be small, 100-512 MiB. See Notes below.
-- File system format: FAT32 (although FAT 16 may work; Windows expects FAT 32)
-- Type: EF00 or ef00 in the GPT disk (0xEF in MBR disk)
-- Boot flag: in GParted (or libparted-based tools), set the "boot" flag on the ESP
-- GUID of the ESP partition: C12A7328-F81F-11D2-BA4B-00A0C93EC93B
-- The top-level directory (on the FAT32 partition ESP): /EFI
-- Example of the subdirectory used by Kubuntu boot and related files: /EFI/ubuntu
-- Mount point of the ESP (viewed from the installed Kubuntu OS filesystem): /boot/efi
-- The Kubuntu directory of files, viewed as mounted: /boot/efi/EFI/ubuntu
-- Default bootloader is /EFI/BOOT/bootx64.efi, mounted as: /boot/efi/EFI/BOOT/bootx64.efi
-- Example of a directory made up to hold the rEFInd bootloader, mounted at /boot/efi: /boot/efi/EFI/rEFInd/refind.efi
-- Filename extension to indicate an EFI bootloader: .efi

Notes:

No other partition in a UEFI setup has a boot flag set; only the ESP. And from Arch Linux Wiki: "... the boot flag has different effect in MBR and GPT ... In MBR disk, it marks the partition as active. In GPT disk, it changes the type code of the partition to EFI System Partition type.")

Size of the ESP, again, from the Arch Linux Wiki: "If you use the Linux kernel's EFI stub loader or ELILO, you may need to store your kernel on the ESP, so creating an ESP on the large end of the scale is advisable. In case of EFISTUB, the kernels and initramfs files should be stored in the EFI System Partition. For sake of simplicity, you can also use the ESP as the /boot partition itself instead of a separate /boot partition, for EFISTUB booting."

The default bootloader, /EFI/BOOT/bootx64.efi, is used in the event no bootoloader is set in the EFI firmware (or if pertinent NVRAM variables(s) are damaged or erased). EFI requires a 64-bit OS.

Filenames: As Rod Smith and the Arch Linux Wiki remind us, "FAT is a case-insensitive filesystem. You may run into variants of ... [the] filenames that differ only in case."

efi filename extension: "... this filename extension denotes an EFI binary file, such as a boot loader file." (Rod Smith)

A cautionary note about mount points (Rod Smith):
"Note: Although /boot/efi is the most common mount point for the ESP, other mount points are possible. Some users like to mount the ESP at /boot because this practice causes Linux kernels to be automatically placed on the ESP, which is useful if you're using ELILO or the kernel's EFI stub loader (often in conjunction with rEFInd or gummiboot). On the other hand, mounting the ESP at /boot will complicate kernel upgrades if your package system creates symbolic links within /boot. Some versions of Ubuntu do this, so mounting the ESP at /boot is undesirable with Ubuntu."

Reading:

A basic reference on the ESP is
EFI System partition, http://en.wikipedia.org/wiki/EFI_System_partition#Linux

Then, for more, see Rod Smith's introductory page on (U)EFI and the ESP:

Managing EFI Boot Loaders for Linux: Basic Principles
http://www.rodsbooks.com/efi-bootloa...rinciples.html

Notes:
-- See what Rod Smith says about the size of the ESP under the section EFI Data Structures of this article.
-- The sections titled "The EFI Boot Process" and "Performing a Legacy Boot" are excellent for how EFI boots, The CSM, systems with both MBR and GPT booting, and some possible problems.
-- "If you're having problems with booting on an EFI-enabled computer, you should read your motherboard's manual, check your CSM settings, and try to ascertain whether your OS installer has set itself up to boot in BIOS mode or in EFI mode."

Then, his following article:
Managing EFI Boot Loaders for Linux: EFI Boot Loader Installation
http://www.rodsbooks.com/efi-bootloa...tallation.html

This page covers many useful topics:
-- From Kubuntu, finding the ESP; is it mounted? how to mount it; adding ESP to your fstab file.
-- Using df /boot/efi; blkid /dev/sda1
-- How to copy your bootloader files to the ESP; watch for the required .efi binary bootloader file.
-- Registering the bootloader with the EFI. "The final step to installing a boot loader is to make the EFI recognize it. This step can be tricky because it varies from one system to another."
-- "You can also install any EFI boot loader to a USB flash drive; just treat the flash drive like a hard disk, but be sure to install the boot loader as EFI/BOOT/bootx64.efi."

rEFInd (Rod Smith, author)
"... rEFInd is a boot manager, not a boot loader; however, when paired with a kernel that includes the new (as of the 3.3 kernel series) EFI stub support, rEFInd can boot a Linux kernel without the help of any other boot loader."
See:
Using rEFInd
http://www.rodsbooks.com/efi-bootloaders/refind.html

And for EFI stub support, see:
Using the Kernel's EFI Stub Loader
http://www.rodsbooks.com/efi-bootloaders/efistub.html

Installing Linux in UEFI, don't miss this page:
Linux on UEFI: A Quick Installation Guide
http://www.rodsbooks.com/linux-uefi/
And note his last paragraph: "Beyond these issues, EFI booting problems can be quite idiosyncratic, so you may need to post to a Web forum for help. Be sure to describe the problem as thoroughly as you can. The Boot Info Script can provide useful information—run it and it should produce a file called RESULTS.txt that you can paste into your forum post. Be sure to [paste it into a "code" box], though; otherwise people will complain. Alternatively, upload RESULTS.txt to a pastebin site, such as pastebin.com, and post the URL that the site gives you.

Then, you might want to check the Arch Linux Wiki's and related links there:

Unified Extensible Firmware Interface
https://wiki.archlinux.org/index.php...ware_Interface

A refreshing, theoretical comment from this wiki, on multibooting: "Multibooting in UEFI
Since each OS or vendor can maintain its own files within the EFI System Partition without affecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one boot loader to load another to switch OSes." Gosh, I sure hope so!

And about these slashes in path names, some forward, some backward: " UEFI uses backward slash \ as path separator (similar to Windows paths), but the official efibootmgr pkg supports passing unix-style paths with forward-slash / as path-separator for the -l option. Efibootmgr internally converts / to \ before encoding the loader path."

EFISTUB (including booting in different ways: rEFInd and UEFI shell)
https://wiki.archlinux.org/index.php/EFISTUB

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Kubuntu subforum: UEFI assistance

General > Misc. Linux Info > UEFI assistance
https://www.kubuntuforums.net/forumd...EFI-assistance

Started by SteveRiley, this is your source for specific comments and specific tips, here at Kubuntu. And the place to ask specific questions.

I've snipped some tips from some of the Kubuntu forum posts that I felt might be useful, and copied them to here. In some cases, I do not have the link, but where I do, I include it. You can google on some phrase from the snippet and find the post.

To search the Kubuntu forum using google:

site:kubuntuforums.net "additional drivers" + sound -Windows
site: gives you results from only the site you type; "quotes" gives you exactly what you put in quotes; + will make sure that word is there; - (minus sign) will omit the word.

- - - - - - - - - -

Dual boot with Windows ... nice simplifying summary ...

https://www.kubuntuforums.net/showth...l=1#post327462

The requirements for UEFI dual boot are the same, regardless of whether the Windows version is 7 or 8.

The EFI system partition must be FAT-32. It holds all the boot loaders for every operating system on the computer.
Windows, whether 7 or 8, will require at least one NTFS partition. Usually Windows will create two (a small 100 MB one and then the much larger C: partition) unless you change the defaults during install.
Linux will require at least one EXT4 partition to hold the root (/) file system.

A computer that comes from the manufacturer with Windows installed will typically already have:

An EFI system partition formatted as FAT-32
The small 100 MB (usually) unlabeled NTFS partition
A manufacturer recovery partition at the very end of the drive's space
The remainder of the space as one single NTFS partition, labeled C:

To configure dual-boot, you will need to:

Shrink the large C: partition
Create a new partition in the now unallocated space
Format that as EXT4
Install Kubuntu

You do not need to create any additional EFI (FAT-32) partitions because the installer will detect the existing one and use it accordingly.

- - - - - - - - - -

What to do with a new laptop with Windows ...

This thread is loaded with good stuff:
https://www.kubuntuforums.net/showth...l=1#post342624

My suggestions.

Keep your firmware in UEFI mode. Take the time to learn it. UEFI is the future; the more people who know this, the better off everyone will be. UEFI has many advantages over BIOS.
Use GPT rather than MBR. The distinction between primary and extended partitions goes away, and partition/drive size limits are practically non-problems now.
Disable Secure Boot. It creates a complex layer of hardware-software integration that is cumbersome to maintain and does very little to protect J. Random PCUser from the kinds of attacks s/he is likely to see.
Install the EFI shell into /boot/efi/EFI/boot. Google for the latest EFI shell version 2. The shell exposes the full miniature operating system that is UEFI. Very cool.

and ...

Unlike BIOS, UEFI is a complete pre-boot environment. The UEFI shell presents a command line that allows you to directly explore and manipulate the firmware. It is completely independent of any installed operating system. If you like to tinker with your PC, the UEFI shell is a good thing to have.

I'd also strongly encourage you to ditch GRUB and use rEFInd as your boot manager. Rod Smith, the rEFInd maintainer, has written extensively about UEFI.
(http://www.rodsbooks.com/refind/)

- - - - - - - - - -

Secure Boot: Recommending to disable Secure Boot. He's not the only one to say so.

Have you disabled the Secure Boot feature in your firmware? If not, let me first encourage that you do so. It will greatly simplify installing alternate operating systems, and the feature itself is of little value. The security gain is minimal, because the attacks it's designed to prevent are uncommon. The hassle factor of Secure Boot is very high.

-----------------------

Windows 8 is present

https://www.kubuntuforums.net/showth...l=1#post326091

You cannot convert the installed Windows 8 from UEFI to legacy without an enormous amount of work. Remove all of the Kubuntu stuff you've installed. Put the firmware back into UEFI mode. Then install Kubuntu. The installer is UEFI-aware; it will detect the EFI boot partition and set itself up accordingly.

GRUB may or may not detect the presence of Windows 8. After you finish installing Kubuntu, if GRUB doesn't show you both operating systems in its menu, this can be fixed. Let us know.

The EFI partition already exists -- when the computer manufacturer installed Windows, the partition was created then. You shouldn't have to create another one. The Kubuntu installer will detect the existing partition and place the GRUB EFI boot loader in a separate subdirectory there. It will then update the list of NVRAM variables in your UEFI.

- - - - - - - - - -

Example of using gdisk and what the output looks like ...

sudo gdisk -l /dev/sda

GPT fdisk (gdisk) version 0.8.5

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): ECF8BE59-B005-429C-A5A5-0450C2979099
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 6340 sectors (3.1 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 2097151 1023.0 MiB 2700 Basic data partition
2 2097152 2834431 360.0 MiB EF00 EFI system partition
3 2834432 3096575 128.0 MiB 0C01 Microsoft reserved part
4 3096576 393944232 186.4 GiB 0700 Basic data partition
5 1929101312 1953523711 11.6 GiB 0700 Basic data partition
6 393945088 411523071 8.4 GiB 8200
7 411523072 1778710527 651.9 GiB 0700
8 1778710528 1780664319 954.0 MiB EF00
9 1780664320 1929099263 70.8 GiB 0700

- - - - - - - - - -

GRUB 2 menu (grub.cfg) can start the UEFI boot manager ...

And here's the mysterious "system setup"!

### BEGIN /etc/grub.d/30_uefi-firmware ###
menuentry 'System setup' $menuentry_id_option 'uefi-firmware' {
fwsetup
}
### END /etc/grub.d/30_uefi-firmware ### I've figured this out. Every UEFI-equipped machine includes a very basic boot manager, which displays installed operating systems that the UEFI knows about. GRUB is now providing a menu option to start the UEFI boot manager. Huh. Since I don't use GRUB, I hadn't realized it had gained this capability.

- - - - - - - - - -

GRUB 2 menu (grub.cfg) can boot Windows using the efi boot manager ...

Here's a new menu entry in /boot/grub/grub.cfg that is another way to boot Windows using the efi boot manager! -->
menuentry "Windows 8 (alternate boot method)" {
search --set=root --file /EFI/Microsoft/Boot/bootmgfw.efi
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

-----------------------------

Identifying if an Ubuntu has been installed in EFI mode

An Ubuntu installed in EFI mode can be detected the following way:

> its /etc/fstab file contains an EFI partition (mount point: /boot/efi)
> it uses the grub-efi bootloader (not grub-pc)
> from the installed Ubuntu, open a terminal (Ctrl+Alt+T) then type the following command:
[ -d /sys/firmware/efi ] && echo "Installed in EFI mode" || echo "Installed in Legacy mode"

https://help.ubuntu.com/community/UEFI#Identifying_if_the_computer_boots_the_HDD_in_ EFI_mode

- - - - - - - - - -

rEFInd, as your boot manager ...

https://www.kubuntuforums.net/showth...l=1#post342668

The advantage is that it just works straight away. GRUB 2 is complex, finicky, and prone to packaging errors. Many of the dual-boot problems that plague several Linux distributions are related in some way to weird GRUB configurations. Rod [Smith] discusses these problems on his site.

The Linux kernel is now a self-contained boot loader, as is the Windows kernel. Thus, no separate boot loaders are required. One only needs a boot manager to select from the multiple boot-loadable kernels present on the machine.

rEFInd automatically locates all bootable kernels for Linux, Mac, and Windows on all available partitions and presents them in a menu. You pick the one you want, and UEFI boots the chosen operating system directly. You can control the menu appearance and OS detection logic via /boot/efi/EFI/refind/refind.conf, but there's likely no reason to change things unless you want to, say, switch from graphical to text mode boot (I do this). You can pass kernel parameters in /boot/refind_linux.conf. And that's all you need to do. Quite elegant, really.

The entire point of rEFInd is to offer a simplified boot manager that relies on UEFI's ability to directly start an operating system's boot loader. BIOS-based machines have no similar capability, that's why these machines need an intermediate boot loader step provided by the likes of GRUB, LILO, etc.

and tips to remove GRUB ...

https://www.kubuntuforums.net/showth...l=1#post342730

- - - - - - - - - -

Useful commands:

sudo efibootmgr -v
and
sudo apt-get install tree
tree /boot/efi
and
dpkg -l | grep -i grub

(I need to find specific examples applied to UEFI ... etc. ...)

For some examples, see the following -->

- - - - - - - - - -

The efibootmgr, very good stuff on reading the NVRAM variables ...
https://www.kubuntuforums.net/showth...l=1#post287346

Here's the output of efibootmgr on my X1:

steve@x1:~$ sudo efibootmgr -v
BootCurrent: 0013
Timeout: 0 seconds
BootOrder: 0013,0006,0007,000A,0009,000B,000C,0008,000D
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash Screen
Boot0003 Startup Interrupt Menu
Boot0004 ME Configuration Menu
Boot0005 Rescue and Recovery
Boot0006* USB CD 030a2400d23878bc820f604d8316c068ee79d25b86701296aa 5a7848b66cd49dd3ba6a55
Boot0007* USB FDD 030a2400d23878bc820f604d8316c068ee79d25b6ff015a288 30b543a8b8641009461e49
Boot0008* ATA HDD2 030a2500d23878bc820f604d8316c068ee79d25b91af625956 449f41a7b91f4f892ab0f602
Boot0009* ATA HDD0 030a2500d23878bc820f604d8316c068ee79d25b91af625956 449f41a7b91f4f892ab0f600
Boot000A* USB HDD 030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf 33bc4789bd419f88c50803
Boot000B* PCI LAN 030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b 2afc4ea79cf5cc8f3d3803
Boot000C* ATAPI CD1 030a2500d23878bc820f604d8316c068ee79d25baea2090adf de214e8b3a5e471856a35403
Boot000D* ATA HDD3 030a2500d23878bc820f604d8316c068ee79d25b91af625956 449f41a7b91f4f892ab0f603
Boot000E* IDER BOOT CDROM ACPI(a0341d0,0)PCI(16,2)ATAPI(0,1,0)
Boot000F* IDER BOOT Floppy ACPI(a0341d0,0)PCI(16,2)ATAPI(0,0,0)
Boot0010* ATA HDD 030a2400d23878bc820f604d8316c068ee79d25b91af625956 449f41a7b91f4f892ab0f6
Boot0011* ATAPI CD: 030a2400d23878bc820f604d8316c068ee79d25baea2090adf de214e8b3a5e471856a354
Boot0012* PCI LAN 030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b 2afc4ea79cf5cc8f3d3803
Boot0013* ubuntu HD(1,28,100000,6ead9c9b-5ed2-46a0-80ad-e53905c57b4a)File(\EFI\ubuntu\grubx64.efi) During installation, the setup scripts for grub-efi call efibootmgr to create the NVRAM variable for the operating system being installed. You can see the results in the list: Boot0013. Specifically, the command to create that was:
efibootmgr --create --disk /dev/sda --partition 1 --loader \\EFI\\ubuntu\\grubx64.efi --label ubuntu

So what's all that other stuff?

In the days of BIOS, remember how you could enter a setup menu and alter the ordered list of boot devices? And/or press a key during boot to temporarily choose another device? Well, you can do that in UEFI, too. But unlike BIOS, where that list of devices was something of a secret, in UEFI, the boot list is stored in the Boot Manager, which is a collection of variables in NVRAM. The Boot Manager contains pointers to:

Elements of the UEFI itself
Traditional boot devices
UEFI-aware operating systems that are registered with UEFI

On my X1, variables 0000..0005 point to UEFI elements. Variables 0006..0012 point to boot devices. Variable 0013 points to GRUB.

Notice the asterisks. This symbolizes which devices and boot loaders the UEFI will scan for something it recognizes as bootable. The order of scanning is controlled by the variable BootOrder; note that 0013 is first in my list, so under normal conditions I don't see a boot menu. If I press [F12], the X1's temporary boot order list picker, I will see a list of all devices that were detected as containing something bootable. The UEFI elements themselves don't possess the boot search asterisk because these are useful only when you're in the UEFI setup menu, which I can launch if I press [F1] during boot.

Now here's another neat trick about UEFI. Since everything's a file, that means most items can be manipulated outside the setup menu. I can change the boot order in three places:

The UEFI setup menu, which is expected -- this is how you do it in BIOS, too
The EFI shell
Using the efibootmgr command while the operating system is running

Various switches on the command line allow me to temporarily or permanently alter the boot order. I can also add and delete variables; deleting is permanent, undoable, and unguarded!
See man efibootmgr for more information.

- - - - - - - - - -

How I (sort of) conquered UEFI
https://www.kubuntuforums.net/showth...conquered-UEFI
Re the placement of GRUB during install of OS:
Alright. So now let's try yet another install, and allow GRUB. The installer has always detected partition #1 and correctly marked it as the EFI system partition. When it came time, near the end, to install a boot loader, rather than skipping that, I just decided to let the installer automatically set up GRUB. And to my surprise, it worked perfectly. Contrary to what I've read elsewhere, Ubuntu's setup scripts appear to have shed their bugs. grub-efi, not grub-pc, was downloaded and configured. And all in one step: unlike BIOS+MBR, with UEFI+GPT we know that boot loaders always go in whatever partition is type EF00 and in subdirectory /boot/efi. Gone is the chore of telling your installer where your boot partition is.
The tl;dr version of what I wrote is this: Ubuntu Precise, with its defaults, shows enough maturity to work just fine with UEFI. So long as you don't go diverting from GRUB or fiddling around inside an EFI shell, you probably won't notice the difference. What Canonical should improve is Partman; it ought to be at least as smart as gdisk and get the partition alignment right. Performance will suffer if your first partition begins on sector 34.

- - - - - - - - - -
S-R:
You cannot disable UEFI. The firmware in a PC is either BIOS or UEFI, not both. Your UEFI configuration should expose a BIOS compatibility option, which makes the UEFI emulate a BIOS.

- - - - - - - - - -

UEFI, boot interrupt keys, UEFI boot manager, example using ll -R /boot/efi/EFI, the file EFI\boot\bootx64.efi, Linux & Windows installation media, MBR booting, and more ...
https://www.kubuntuforums.net/showth...l=1#post323991

On machines with UEFI (not BIOS) firmware, the boot interrupt key (it's F12 on my ThinkPads) starts the UEFI boot manager. The boot manager will list:

* Each UEFI NVRAM variable that points to an EFI boot loader (the binary image that starts an operating system)
* Any FAT16/32 volume that contains the file \EFI\boot\bootx64.efi
* Any bootable volume that contains a "standard" boot loader

My T520 contains the following:
steve@t520:~$ ll -R /boot/efi/EFI
/boot/efi/EFI:
total 20
drwxr-xr-x 4 root root 4096 Sep 29 13:15 ./
drwxr-xr-x 3 root root 4096 Dec 31 1969 ../
-rwxr-xr-x 1 root root 334 Mar 8 16:31 addbootvar.sh*
drwxr-xr-x 2 root root 4096 May 19 2012 boot/
drwxr-xr-x 2 root root 4096 Mar 8 17:36 ubuntu/

/boot/efi/EFI/boot:
total 756
drwxr-xr-x 2 root root 4096 May 19 2012 ./
drwxr-xr-x 4 root root 4096 Sep 29 13:15 ../
-rwxr-xr-x 1 root root 763360 May 19 2012 bootx64.efi*

/boot/efi/EFI/ubuntu:
total 45492
drwxr-xr-x 2 root root 4096 Mar 8 17:36 ./
drwxr-xr-x 4 root root 4096 Sep 29 13:15 ../
-rwxr-xr-x 1 root root 17940258 Mar 8 16:20 initrd.img-3.5-generic*
-rwxr-xr-x 1 root root 18075146 Mar 8 17:11 initrd.img-3.8-mainline*
-rwxr-xr-x 1 root root 5125712 Mar 8 16:01 vmlinuz-3.5-generic.efi*
-rwxr-xr-x 1 root root 5427472 Mar 8 17:11 vmlinuz-3.8-mainline.efi* When I start the computer and press F12, I can select four items:

* Ubuntu with kernel 3.8
* Ubuntu with kernel 3.5
* Ubuntu with kernel 3.5 in recovery mode
* The model name/number of my computer's disk drive

The first three items appear in the list because they have corresponding entries in my UEFI's NVRAM variables. The fourth item exists because the UEFI boot manager found the file \EFI\boot\bootx64.efi on my FAT32 volume (which, in my case, is /dev/sda1). This file exists because my normal habit now is to place the EFI Shell on every computer I own. This is a handy tool to have around.

---> Bootable installation media for current Windows and most Linux distros is now constructed so that it will boot on machines that have either UEFI or BIOS. If you have UEFI and you have not enabled BIOS compatibility mode (or "compatibility service module" or "CSM"), then the computer will boot in UEFI mode and will load the file \EFI\boot\bootx64.efi. If you have enabled CSM, the computer will boot in BIOS mode and will load the MBR from the media. If you have regular BIOS, the computer will load the MBR from the media.

---> If a drive happens to have both an MBR and a \EFI\boot\bootx64.efi, then you can detect this if you press your compter's boot interrupt key. The boot manager will list both choices. The choice with "UEFI" in front will start the computer in UEFI mode with the EFI boot loader. The choice without the "UEFI" in front will start the computer in BIOS mode with the MBR.

- - - - - - - - - -
UEFI Shell commands usually support -b option which makes output pause after each page.

- - - - - - - - - -
bcfg

BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" PDF document.
Note: Users are recommended to try bcfg only if efibootmgr fails to create working entries in their system.
To dump a list of current boot entries:
Shell> bcfg boot dump -v

**Qqmike** · Mar 02, 2014, 06:40 PM

Of course, the links I gave in the Study Guide are not all the links one might read--there are many on GPT and UEFI. However, the following three have popped up quite often, so I added them to the list of links in the front matter:

Converting to or from GPT
http://www.rodsbooks.com/gdisk/mbr2gpt.html

Converting a BIOS/MPR installation to UEFI/GPT
https://www.kubuntuforums.net/showth...on-to-UEFI-GPT

UEFI
https://help.ubuntu.com/community/UEFI

**Qqmike** · Mar 20, 2014, 07:24 PM

I edited the Study Guide (Post #109 above) to include two more references, the first of which you may find very interesting (the second one is very good, also, just somewhat technical to Fedora but gives insight into UEFI default booting behavior):

AdamW:
UEFI boot: how does that actually work, then?
https://www.happyassassin.net/2014/0...lly-work-then/

Peter Jones:
The EFI System Partition and the Default Boot Behavior
http://blog.uncooperative.org/blog/2...tem-partition/

**Qqmike** · Mar 08, 2015, 02:22 PM

A new PC build and Kubuntu-only UEFI installation

A new PC build and Kubuntu-only UEFI installation

This post follows the above "Study Guide" for UEFI+GPT:

https://www.kubuntuforums.net/showth...l=1#post346604

A new PC build and Kubuntu-only UEFI installation
Messing with UEFI+GPT

For a Linux-only desktop PC. No Windows. For Windows, see Rod Smith's website and Steve Riley's thread.

This is for the ASUS motherboard. ASUS has excellent UEFI support, imo. But this will alert you to the issues to explore should you use another motherboard.

This is how I did it. There may be other ways, easier ways.

The hardware building part: --> If you are only interested in the UEFI+GPT and Kubuntu part, you can safely skip this brief, summary-level outline of the new PC assembly. You can skip down to Configure UEFI (BIOS).

- - - - - - - - - -

Contents

-- PC assembly/integration summary
-- BIOS Update: Does the ASUS motherboard need a BIOS update first?
-- Configure UEFI (BIOS) for hardware settings and boot priority
-- Configure UEFI (BIOS)
-- Format the HDD for UEFI+GPT, and for Kubuntu OS /, /home, and swap
-- Install the OS in UEFI mode
-- Then re-boot configure the Kubuntu OS ... et cetera, and so on.
-- Exploring the Kubuntu UEFI Setup, or messing around ;-)
--How to know you are running in UEFI mode--Several ways to check it--

- - - - - - - - - -

PC assembly/integration summary. This will be quick and abbreviated.

For basic, mainstream use, the hardware component list:

Motherboard, ASUS HP97-Plus, ASUS ATX DDR3 2600 LGA 1150 Motherboards H97-PLUS
CPU, Intel Core i5-4570, 3.2GHz LGA 1150 84W Quad-Core Intel HD Graphics
Memory, Kingston 4 GB x 2 = 8 GB, 1600MHz PC3-12800 DDR3 Non-ECC CL11 DIMM SR x8
Power Supply, SilverStone 500W , Strider, 80 PLUS, Active PFC Power Supply ST50F-ES (Black)
HDD, Western Digital, black, 500 GB, 3.5 Inch, 7200 RPM, SATA III, 64 MB Cache, 5 Year Warranty
Optical Drive, Samsung, SH-224DB/RSBS 24X SATA DVD±RW Internal Drive
Case: Antec Super Lanboy (old model, 2005); thus the needs for new fans and USB 3 adaptor
Fans - 2, These are 4-pin, PWM support: full motherboard control. One is blue LED, one is no LED
Cooler Master JetFlo 120 - POM Bearing 120mm Blue LED High Performance Silent Fan
USB 3 module, front panel, Anker® 3.5 inch Front Panel USB Hub with 2 USB 3.0 Ports [20 Pin Connector & 2ft Adapter Cable]
Fan extension cablefor front fan, 12" PWM 4 pin extension cable with Black Sleeving # FC44PWM-12BKS
Other I re-used components from other builds: a Samsung monitor, Logitech keyboard, mouse, webcam, and Antec speakers.

Integration sequence and summary outline:

Reminder: Ground yourself at all times by touching the metal case or power supply.
Workspace: a wood table, I placed a folded towel on top of the box the motherboard came in and worked on top of that.
Unpack and examine Power Supply and the connectors.
Prepare the Case: Power supply -- I/O template-- Install the brass stand-offs
Because I reused on old but neat case, I replaced the two case fans and added a USB 3 module in a front 3.5" bay.
Check compatibility of the motherboard and CPU before proceeding.

Populate the motherboard with the CPU, Intel HSF, and Memory (in dual-channel mode).
Attach CPU HSF power connector to motherboard header.
I did this with the motherboard outside the case, as the old case did not have a CPU cutout for double-checking the seating of the push pins of the HSF.

Install motherboard in the case, aligning back panel connectors with holes in I/O template, attach with screws to the brass stand-offs.

Secure cable connections to the motherboard:
Power Switch, Reset Switch, Power LED, Hard Drive Activity LED; front panel USB 2 & 3 ports.
Install HDD and Optical Drive, attach data cables to motherboard headers and attach SATA power cables from the PSU.
Case fans: Install case fans and connect power cables for the case fans, to the motherboard headers for full PWM control.

Connect the two ATX Power connectors--main and auxiliary--from the power supply to the motherboard.
Dress cables, check for good air flow.

Smoke test: with right side panel off, make sure PSU (power supply unit) if off and not connected to electrical supply, check voltage setting on PSU(not necessary w/PFC PSU), plug PSU power cable into wall receptacle, attach to PSU, turn on the PSU. Verify fans are spinning (the power supply fan, CPU fan, and case fan(s)). Turn off the system.

- - - - - - - - - -

BIOS Update: Does the ASUS motherboard need a BIOS update first?
In my case, this time, no. The motherboard shipped with the latest BIOS version. I was prepared though with the proper BIOS file on flash drive to update BIOS if needed.

- - - - - - - - - -

Configure UEFI (BIOS) for hardware settings and boot priority
Turn on PC, at post enter UEFI(-BIOS). Then do it. (For example, for 4-pin PWM MB fan headers, change fan control to PWM, not DC.)

- - - - - - - - - -

Configure UEFI (BIOS)

Turn on the PC, at the POST press the key (F2) to enter UEFI(-BIOS).
CSM (compatibility support module): set to Auto (default).
Disable Secure Boot: Change to “Other O/S”, which disables Secure Boot for the ASUS UEFI. Disable Fast Boot.

- - - - - - - - - -

Format the HDD for UEFI+GPT, and for Kubuntu OS /, /home, and swap

I used GParted Live CD to make a GPT on the new HDD (or your SSD), to set up UEFI (ESP), and to set up partitions for the OS (root /, /home/ swap).

GParted Live CD: I used the 64-bit version for x86-64 PCs, for new PCs > 2010 w/UEFI.

This way, using GParted Live CD:

First select Device: create partition table: GPT. Then partition the GPT:
sda1 = the ESP (the EFI System Partition).
Starting at "the 1 megabyte," at 1 MiB, create a FAT32 partition, 500 MB, with flag "boot," and this automatically sets the esp flag, also, as the ESP is the only partition marked as bootable in a UEFI+ GPT scheme.

Then I created the OS partitions: sda2 = /, sda3 = /home, and sda4 = swap (which I chose to be 30 GB, 100 GB, and 16 GB, respectively, following one rule that swap = 2 x Ram.

- - - - - - - - - -

Install the Kubuntu OS in UEFI mode
--> Must be 64-bit Kubuntu OS for UEFI. I am using Kubuntu 14.04, 64-bit.

Important: You must make certain you are installing Kubuntu in UEFI mode.

I used a Live DVD Kubuntu installer.
Install the DVD in the optical drive, reboot the PC, enter UEFI(-BIOS) by pressing F2.
Under Advanced, find the ASUS boot menu, and the "boot override" menu under that.
The bootable devices will be listed.
Choose the one that corresponds to the Kubuntu UEFI choice.
Look for UEFI / FAT) or some reference to UEFI.
My Live Kubuntu DVD installer showed up twice in UEFI BIOS (under Boot Override) as a "normal" DVD writer, and also as:
UEFI (FAT) TSSTcorp CDDVDW SH-224DB (1028 MB) (= my Samsung DVD player).
Found out you may have to re-boot a time or two for this to appear correctly, so I think.
Select that option from the boot override menu.
The PC will re-boot, and you will see a text mode screen with a grub-like menu. Select install O/S. If, instead, you see the full graphical setup menu, the installer is probably in legacy BIOS mode so reboot, enter the UEFI setup, navigate to boot override and try again.

Kubuntu installation

I chose to use the Manual method. I am told that the automatic method(s) will work just fine and the Kubuntu installer will not only figure it out about the UEFI, but would also partition your disk at GPT with ESP, if necessary. Being more cautious, and something of a control freak, I already did the GPT+ESP partitioning using an up-to-date, 64-bit, GParted Live CD.
I used the partitions (sda2, sda3, sda4) as I listed above under "Format the HDD." Remember, sda1 was created as the ESP. It asked me where to put GRUB, I chose sda because it was the only reasonable choice offered in the drop-down, but I'm sure that the installer knew what to do regarding the ESP and so on. Installation went smoothly and fast.

Then re-boot and configure the Kubuntu OS ... et cetera, and so on.

- - - - - - - - - -
- - - - - - - - - -

Exploring the Kubuntu UEFI Setup, or messing around ;-)

fstab

My fstab has this:
# /boot/efi was on /dev/sda1 during installation
UUID=74D7-02F2 /boot/efi vfat defaults 0 1

Thus, the ESP is mounted on /boot/efi, as it should be.

/boot/grub/grub.cfg

My grub.cfg has this:
### BEGIN /etc/grub.d/30_uefi-firmware ###
menuentry 'System setup' $menuentry_id_option 'uefi-firmware' {
fwsetup
}
### END /etc/grub.d/30_uefi-firmware ###

Also, /boot/grub has this folder: x86_64-efi

Looks like the presence of UEFI.

Try this command

mike@mike-desktop:~$ [ -d /sys/firmware/efi ] && echo "Installed in EFI mode" || echo "Installed in Legacy mode"
Output of this: Installed in EFI mode

gdisk
(Instead of the familiar sudo fdisk -l command for legacy BIOS systems. gdisk is Rod Smith's work.)

Code:

 sudo gdisk -l /dev/sda
 
 GPT fdisk (gdisk) version 0.8.8
 Partition table scan:
   MBR: protective
   BSD: not present
   APM: not present
   GPT: present
 
 Found valid GPT with protective MBR; using GPT.
 Disk /dev/sda: 976773168 sectors, 465.8 GiB
 Logical sector size: 512 bytes
 Disk identifier (GUID): D3B766B4-D998-4351-8F06-13BC87F55BDE
 Partition table holds up to 128 entries
 First usable sector is 34, last usable sector is 976773134
 Partitions will be aligned on 2048-sector boundaries
 Total free space is 676741101 sectors (322.7 GiB)
 
  Number  Start (sector)    End (sector)  Size       Code  Name
    1            2048         1026047   500.0 MiB   [B]EF00[/B]  <-- this is the ESP partition, sda1
    2         1026048        62466047   29.3 GiB    8300   
    3        62466048       267266047   97.7 GiB    8300   
    4       267266048       300034047   15.6 GiB    8200

Command: ll -R /boot/efi/EFI
So, let's try this command to get this output:

Code:

  /boot/efi/EFI:
  

  total 12
  drwxr-xr-x 3 root root 4096 Mar  6 18:30 ./
  drwxr-xr-x 3 root root 4096 Dec 31  1969 ../
  drwxr-xr-x 2 root root 4096 Mar  6 18:30 ubuntu/
 

 /boot/efi/EFI/ubuntu:
  total 3424
  drwxr-xr-x 2 root root    4096 Mar  6 18:30 ./
  drwxr-xr-x 3 root root    4096 Mar  6 18:30 ../
  -rwxr-xr-x 1 root root     126 Mar  6 18:30 grub.cfg*
  -rwxr-xr-x 1 root root  956792 Mar  6 18:30 [B]grubx64.efi[/B]*
  -rwxr-xr-x 1 root root 1178240 Mar  6 18:30 MokManager.efi*
  -rwxr-xr-x 1 root root 1355736 Mar  6 18:30 [B]shimx64.efi[/B]*

Hmmm ... interesting. I recognize /boot/efi/EFI/ubuntu/grubx64.efi (this is in the above Study Guide, for example). But there's the shim thing in there, too (which you may also kind of recognize or recall from Linux work on the MS secure booting thing). The "efi" extension indicates a UEFI bootable file.

Btw, you can also explore this graphically. Open Dolphin, click on root (on the left), navigate to /boot/efi/EFI/ubuntu and you'll see those same files.

Continuing --> -->

Let's try this tip from SteveRiley:
sudo efibootmgr -v

Code:

 sudo efibootmgr -v
 
 BootCurrent: 0000
 Timeout: 1 seconds
 BootOrder: 0000,0003,0001,0002
 [B]Boot0000* ubuntu[/B]        HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\UBUNTU\[B]SHIMX64.EFI[/B])
 Boot0001* Hard Drive    BIOS(2,0,00)..GO..NO........O.W.D.C. .W.D.5.0.0.3.A.Z.E.X.-.0.0.M.K.2.A.0.................>..Gd-.;.A..MQ..L. . . . .W. .-.D.C.W.3.C.5.F.F.X.2.6.F.K........BO
 Boot0002* CD/DVD Drive  BIOS(3,0,00)..GO..NO........O.T.S.S.T.c.o.r.p. .C.D.D.V.D.W. .S.H.-.2.2.4.D.B.................>..Gd-.;.A..MQ..L.9.R.U.4.Y.6.F.B.0.6.4.1.Y.9. . . . . . ........BO
 Boot0003* ubuntu        HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\UBUNTU\[B]GRUBX64.EFI[/B])..BO

Notice the asterisks. This indicates which devices and boot loaders the UEFI will scan for, looking for something it recognizes as bootable. The order of scanning is controlled by the variable BootOrder. (Credit: I think this is a paraphrase of SteveRiley.)

Conclusion thus far
So, it looks like my ASUS UEFI is booting from the file in the ESP partition called
\EFI\UBUNTU\SHIMX64.EFI (since it is labeled in the Boot0000* position).

What is this?

I then googled shimx64.efi, or "the difference between shimx64.efi and grubx64.efi," and got a direct hit.
http://askubuntu.com/questions/34236...64-and-shimx64

EFI\ubuntu\grubx64.efi
EFI\ubuntu\shimx64.efi

They both boot into Ubuntu.
What's the difference between the two and which one should I use?

Answer (by Rod Smith):

Typically, EFI/ubuntu/grubx64.efi on the EFI System Partition (ESP) is the GRUB binary, and EFI/ubuntu/shimx64.efi is the binary for shim. The latter is a relatively simple program that provides a way to boot on a computer with Secure Boot active. On such a computer, an unsigned version of GRUB won't launch, and signing GRUB with Microsoft's keys is impossible, so shim bridges the gap and adds its own security tools that parallel those of Secure Boot. In practice, shim registers itself with the firmware and then launches a program called grubx64.efi in the directory from which it was launched, so on a computer without Secure Boot (such as a Mac), launching shimx64.efi is just like launching grubx64.efi. On a computer with Secure Boot active, launching shimx64.efi should result in GRUB starting up, whereas launching grubx64.efi directly probably won't work.

Note that there's some ambiguity possible. In particular, if you want to use a boot manager or boot loader other than GRUB in a Secure Boot environment with shim, you must call that program grubx64.efi, even though it's not GRUB. Thus, if you were to install rEFInd on a Secure Boot-enabled computer, grubx64.efi could be the rEFInd binary. This binary would probably not reside in EFI/ubuntu, though; both it and a shim binary would probably go in EFI/refind. Also, as you've got a Mac (which doesn't support Secure Boot), there's no need to install rEFInd in this way; it makes much more sense to install rEFInd as EFI/refind/refind_x64.efi (its default location and name).

Note that the rEFInd documentation includes a whole page on Secure Boot. Chances are you won't benefit from reading it, user190735, since you're using a Mac. I mention it only in case some other reader comes along who's trying to use rEFInd in conjunction with Secure Boot.

(The link cited in the response is: http://www.rodsbooks.com/refind/secureboot.html )

Conclusion

My PC is certainly booting by the ASUS UEFI. Everything checks out. And Rod Smith, in the above quote, explains why I'm seeing an apparently different bootloader (in the ESP partition /boot/efi) called /EFI/ubuntu/shimx64.efi. It is calling the bootloader grubx64.efi (also located in the same directory /EFI/ubuntu as shimx64.efi), and grubx64.efi is doing the actual booting of the Kubuntu OS.

**Qqmike** · May 06, 2015, 12:55 PM

Dual Booting Kubuntu 14.04 and 15.04, in UEFI mode

Dual Booting Kubuntu 14.04 and 15.04, in UEFI mode

----------

Added 5/30/15:

For solutions to some of the issues raised here, see the application of GRUB-EFI in SECTIONS 3 & 6 here:

Post #121:
UEFI for Kubuntu--simplified. And ... some dual-booting tips for Kubuntu

https://www.kubuntuforums.net/showth...l=1#post373198

--> SECTION 3: GRUB 2 (for EFI)

--> SECTION 6: Dual/multi-booting: Know what to expect ... and how to deal with GRUB

----------

To date, the Internet articles are somewhat discouraging on dual-booting with UEFI--See the section on this below, and the links cited there.

I am somewhat disappointed after conducting a little experiment of my own.

Bottom-line
I was successful setting up a dual boot in UEFI+GPT with Kubuntu 14.04 and Kubuntu 15.04, but it was not the way I had hoped for or the way I would prefer.

Bottom-line, more detailed

In Experiment #1, I installed Kubuntu 15.04 to available space on a disk that had 14.04 installed. It worked for a dual boot, but the GRUB from 15.04 took over the booting of the PC (I had hoped they would, somehow, be independent, the setup for 14.04 and that for 15.04).

In Experiment #2, I created a second ESP and had hoped the Kubuntu installer and the ASUS firmware would use both ESPs--one to set up 14.04 and one to set up 15.04. This failed: The Kubuntu installer didn't even use the second ESP--it was left empty. The dual boot worked, but it worked exactly as in Experiment #1.

Added (5-11-15):

Experiment #3
Post #116
https://www.kubuntuforums.net/showth...l=1#post371929

Experiment #3
As in Experiment #2, I created a second ESP and had hoped the Kubuntu installer and the ASUS firmware would use both ESPs--one to set up 14.04 and one to set up 15.04. This time, during the installation of 15.04, I explicitly chose the new--the second--ESP partition as the target for grub to be installed. This also failed: The Kubuntu installer didn't use the second ESP--it was left empty. The dual boot worked, but it worked exactly as in Experiment #1.

I knew, or I had read, that in UEFI mode, specifying a target partition for grub is pointless as the installer will do its proper UEFI thing in any case. I was hoping, though, that by using that choice in the Kubuntu installer, that it would work to activate the second ESP partition for the use of 15.04 grub booting files. Nope. Wrong.

Experiment #4

A second drive was added. Again, this was disappointing. With two ESPs--one on the HDD, one on the flash drive--I failed to populate a useful ESP on the flash drive. A successful setup doing so would have to be set up and configured manually, so it seems.

Experiments #1, #2, #3 were done on a system having one HDD.
For experiment #4, I plugged in a 16 GB USB 3.0 flash drive, kept it there, using it as one would use a HDD.

So, we have:

My regular desktop PC's HDD is sda; on sda is sda1 = the ESP for the HDD. Kubuntu 14.04 is installed to sda2.
The flash drive is sdb; on sdb is sdb1 = the ESP for the flash drive. Kubuntu 14.04 is installed to sdb2.
(The Kubuntu installation is a regular, 64-bit, permanent installation; i.e., the flash drive is NOT a live Kubuntu UFD.)

Result:

-- GRUB 2 from the Kubuntu 14.04 on the flash drive took over everything!
-- The ESP on the flash drive is empty--unused--even though during the installation of Kubuntu I directed sdb1 to be used as the ESP and the installer indicated it was "...installing [grub] to sdb1 ..." in the progress indicator.
-- GRUB 2 installed itself to the ESP on sda1: /boot/efi/EFI/ubuntu, overwriting the setup that was there previously. It wrote a new grub.cfg that showed Kubuntu on sda2 and Kubuntu on sdb2, listing sdb2 (the flash drive) first.
-- Upon re-booting and entering ASUS UEFI BIOS setup (by pressing F2), the boot menu changed to show the flash drive first; the rEFInd on sda2 is listed second; and so on. Previously (before using the flash drive at all), rEFInd was first in boot order and controlled everything on the HDD sda.
-- Upon re-booting, if you don't enter the ASUS UEFI BIOS setup (by pressing F2), you will boot by default to Kubuntu 14.04 on the flash drive, sdb2.
-- Upon re-booting, if you enter the ASUS UEFI BIOS setup (by pressing F2), you can select whatever you need from the Boot Override menu--everything on both drives (HDD and flash drive) is listed. If you select rEFInd, you can boot directly to the kernel located on the flash drive, sdb2, and thus boot into Kubuntu 14.04 on the flash drive sdb2.
-- I booted into Kubuntu on the flash drive and installed rEFInd from there. rEFInd installed itself NOT to the ESP on the flash drive (sdb1), but to the ESP on the HDD at sda1. It did, however, set itself up as #1 in the boot order (the NVRAM variables in the ASUS UEFI firmware).

=> Thus, it all works. You can boot into anything on either drive--the HDD sda or the flash drive sdb. But it is all controlled by the ESP files on the HDD sda; the ESP on the flash drive sdb1 is empty. GRUB 2, when installed in the Kubuntu on the flash drive truly did take over the show and wrote its boot files and grub.cfg to the ESP on the HDD sda1. And rEFInd seemed to follow. The ESP on the flash drive sdb1 remains empty, unused.

- - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - -

Setup
Motherboard/firmware: ASUS H-97 Plus
One HDD
Partitions:

Code:

 Number  Start (sector)    End (sector)  Size       Code  Name
    1            2048         1026047   500.0 MiB   EF00   
    2         1026048        62466047   29.3 GiB    8300   
    3        62466048       267266047   97.7 GiB    8300   
    4       267266048       300034047   15.6 GiB    8200   
    5       300034048       361474047   29.3 GiB    8300   
    6       361474048       566274047   97.7 GiB    8300

Partition sda1 is my existing ESP (EFI System Partition).
Partition 2 is the root partition for Kubuntu 14.04.
Partition 3 is the /home partition for Kubuntu 14.04.
Partition 4 is swap.
Partitions 5 and 6 are empty and available for installing Kubuntu 15.04 (root / and /home).

The ESP, /dev/sda1, is mounted (as seen by Kubuntu 14.04) as /boot/efi.
There, you see /boot/efi/EFI/ubuntu, where EFI is the main directory of the ESP, and where ubuntu contains these four files:

Code:

 mike@mike-desktop:~$ ls -l /boot/efi/EFI/ubuntu
 total 3416
 -rwxr-xr-x 1 root root     126 Mar  6 17:30 grub.cfg
 -rwxr-xr-x 1 root root  956792 Mar  6 17:30 grubx64.efi
 -rwxr-xr-x 1 root root 1178240 Mar  6 17:30 MokManager.efi
 -rwxr-xr-x 1 root root 1355736 Mar  6 17:30 shimx64.efi

This is pretty much standard stuff, nothing unusual, it's the way the Kubuntu 14.04 installer sets things up with GRUB 2 (for UEFI) on the ESP.

Note that the grub.cfg here is simple. It is a configfile command pointing at the full grub.cfg for my Kubuntu 14.04 at /boot/grub/grub.cfg (the UUID is for /dev/sda2 = hd0, GPT partition 2, which is where my Kubuntu 14.04 root file system is).
The grub.cfg at /boot/efi/EFI/ubuntu/grub.cfg is simply:

Code:

 search.fs_uuid 127fc14b-aa8a-4c00-b781-0a70a88cf07c root hd0,gpt2  
 set prefix=($root)'/boot/grub'
 configfile $prefix/grub.cfg

Experiment #1: Simply try to add Kubuntu 15.04 to my HDD containing 14.04.
This worked but with a caveat.

Backup: Before installing Kubuntu 15.04, I made a backup of the four files in /boot/efi/EFI/ubuntu, I placed them in a folder I called my_Kubuntu_backups, and I stored that folder at /boot/efi/EFI/ my_Kubuntu_backups, also a copy on my Desktop (14.04), and a copy on a flash drive.

I had used GParted to make partitions 5 and 6 for the new Kubuntu 15.04 OS, so I ran the 15.04 live flash drive installer and installed 15.04 that way. During installation, I selected the Manual method (was that called "something else"? I don't recall), and for "Device for bootloader," I selected simply /dev/sda (I believe for UEFI the GRUB installer scripts ignore any such device paths--they are used for legacy BIOS setups). (Btw, I chose not to install updates or 3rd party software, I went slowly, read everything, took a few notes by hand, and the installation took just 16 minutes--I could do it again in, probably, 13 minutes, I think.)

Re-booting the PC now, I got a GRUB boot menu showing options for booting into the new 15.04, the existing 14.04, Recovery modes for each, and System Setup (which takes me to the ASUS UEFI configuration menus in firmware).

AND ... importantly ...

(1) I note that the GRUB boot menu is from the 15.04 OS root partition, /boot/grub/grub.cfg in partition 5; thus, the GRUB in 15.04 took over the booting from the GRUB in 14.04.

(2) My ESP was simply re-used: The contents of /boot/efi/EFI/ubuntu looked the same, containing the same-named four, standard files as were there before installing 15.04: grub.cfg, grubx64.efi, MokManager.efi, and shimx64.efi.
(The previous four files were either changed or they were overwritten completely by the new 15.04 installation of GRUB 2.) The file /boot/efi/EFI/ubuntu/grub.cfg now pointed at (using configfile) the grub.cfg file in the 15.04 OS: /boot/grub/grub.cfg.

Thus, the booting of the PC is now controlled by the GRUB setup by 15.04.
If I delete Kubuntu 15.04, my PC will not boot (until I use a live rescue DVD or USB to fix things).

Restoring the ESP backup and restoring boot control to GRUB 2 of Kubuntu 14.04:

Since I view 14.04 as my main OS, and 15.04 as my "testing" OS, I prefer the booting to be controlled by my GRUB in 14.04. So, I simply deleted the contents of /boot/efi/EFI/ubuntu, and restored my previous backup files from my_Kubuntu_backups, re-booted, and everything works as it worked before this experiment. However, to include 15.04 in the boot menu (of the GRUB 2 in 14.04), I first had to run (from Konsole in 14.04):

sudo grub-mkconfig -o /boot/grub/grub.cfg

Experiment #2: Repeat Experiment #1, installing Kubuntu 15.04, this time pointing the Kubuntu installer at a second ESP partition, hoping the installer will use it, and hoping that 14.04 and 15.04 would be installed independently, that their GRUBs would act independently, one ESP controlling 14.04, and the other ESP controlling 15.04.

(Details: First, I used GParted to re-format the partitions for 15.04, thus essentially "deleting" the existing 15.04 from Experiment #1-- this was partitions 5 &6 -- and I used GParted to create a new, a second, ESP as sda7--as FAT32, 500 MB, tagged as boot. I also restored the first original ESP to its original state, using my ESP backup.)

Bad news:
It didn't work the way I had hoped.

Good news:
The Kubuntu installer DID, however, detect the new partition I had made for the second ESP and it DID offer me the capability for marking it as "Use EFI System Partition."

Result: As it turned out, the final installation of 15.04 looked exactly like the result of Experiment #1:
The original (first) ESP was re-used, the GRUB 2 from 15.04 controlled the boot menu and booting of both 14.04 and 15.04; and, in fact, the newly created ESP, the second ESP, was left empty! not used at all. The output of
sudo efibootmgr -v
showed the same boot order (in firmware) as for Experiment #1.

The blame?
The blame for the failure of Experiment #2 could go to either or both the Kubuntu installer (and GRUB installer scripts) or the ASUS UEFI firmware design.

Caution, warning, notice
Everything done here was specific to my firmware (ASUS H-97 Plus motherboard and firmware), and specific to the operating system and installer Kubuntu 15.04 (and 14.04).
Change either the firmware maker and/or the OS, and your experience may change--for better or for worse.

Recommendation

To dual boot two or more Linux OS, do what I did here, Experiment #1. Know how to use GRUB 2 commands so you can make the booting controlled by whatever OS you wish the booting to be controlled by.

Or ...

You might try using two ESPs to dual boot two Linux OSs, see if it would work for you.

Or ...

Try Rod Smith's boot manager rEFInd. See how it would work in this context (dual-booting).
I have not tried it yet. Others here at Kubuntu forums have tried it. Perhaps they know and can report or experiment and report. I am not clear how it works with GRUB 2, the logistics. I'm also not clear on how to run it to set up a dual boot: I presume you could install rEFInd, install your OS(s), perhaps one-by-one, and after each installation, letting GRUB 2 (for UEFI) do whatever it does, you could then do a "refresh" of rEFInd ( ? ) to generate a good boot menu?

Or ...

Use the Arch links below to figure out how to set up a dedicated GRUB partition or GRUB ESP (a GRUB directory in the ESP) that would act as a boot manager.

I may return to this subject later. I'm just glad I didn't permanently ruin my existing setup.

The Literature is a Bit Discouraging (my comments, as of 5-6-15)

To date, the Internet articles are somewhat discouraging on dual-booting with UEFI.

http://askubuntu.com/questions/61704...hard-drive-wit

Note the first answer is from Rod Smith. He recommends using separate ESP partitions (which didn't work for me); or using some other boot loader and/or boot manager, like his rEFInd (probably a very good idea).
--> Perhaps I could get it to work with two ESPs if I did a custom installation/configuration of GRUB 2 to each of the two ESPs. The Arch how-to's on using UEFI and GRUB 2 could be helpful (see links below).

Here's another one:
http://askubuntu.com/questions/56307...dows-8-on-uefi

And here's Adam W, who is real clear on his experience with it:
UEFI boot: how does that actually work, then?

The following are AdamW’s General Recommendations On Managing System Boot, offered with absolutely no guarantees of accuracy, purity or safety.

If you can possibly manage it, have one OS per computer. If you need more than one OS, buy more computers, or use virtualization ...
If you absolutely must have more than one OS per computer, at least have one OS per disk ...
If you absolutely insist on having more than one OS per disk, understand everything written on this page, understand that you are making your life much more painful than it needs to be, lay in good stocks of painkillers and gin, and don’t go yelling at your OS vendor, whatever breaks. Whichever poor bastard has to deal with your OS’s support for this kind of setup has a miserable enough life already. And for the love of cookies, don’t mix UEFI-native and BIOS-compatible OS installations, you have enough pain to deal with already.

Source:
https://www.happyassassin.net/2014/0...lly-work-then/

See these references for more help, more ideas, more tools

Linux on UEFI:
A Quick Installation Guide
http://www.rodsbooks.com/linux-uefi/
(Rod Smith: and see his entire listing of articles for UEI, GRUB, rEFInd, UEFI issues)

GRUB
https://wiki.archlinux.org/index.php/GRUB
(excellent ideas on GRUB 2 for UEFI, customizing)

Unified Extensible Firmware Interface
https://wiki.archlinux.org/index.php/UEFI

**Qqmike** · May 06, 2015, 01:50 PM

----------

Added 5/30/15:

For solutions to some of the issues raised here and in the above post, see the application of GRUB-EFI in SECTIONS 3 & 6 here:

Post #121:
UEFI for Kubuntu--simplified. And ... some dual-booting tips for Kubuntu

https://www.kubuntuforums.net/showth...l=1#post373198

--> SECTION 3: GRUB 2 (for EFI)

--> SECTION 6: Dual/multi-booting: Know what to expect ... and how to deal with GRUB

----------

Original text of this post:

And so, what's my point?

I started by thinking there should be an easy way for a casual user to set up a basic dual boot for two or more Kubuntu OSs, a way that uses only the Kubuntu installer, GRUB 2, and the UEFI firmware (especially ASUS firmware, which seems very well done and user friendly).

To date, setting up even a basic dual boot in UEFI requires some manual configuration. This is not different from the standard GRUB 2 for PCs or from GRUB Legacy on BIOS+MBR machines.

I was hoping because of the UEFI setup that dual-booting might be easier, in some way.

There are three factors that come into play: the computer's UEFI firmware; GRUB 2 installer scripts for UEFI setups; and the Kubuntu installer (which, in part, of course, calls on the GRUB installer scripts). Between the three of them, we would hope a clear solution might be possible.

Here's a simple thing to think about: take the directory /boot/efi/EFI/ubuntu. Why could there not also be a directory /boot/efi/EFI/ubuntu-2? Why couldn't GRUB 2 UEFI be auto-configured to not only load each ubuntu OS, but also serve as the boot manager? Could it not (automatically) go into the ESP in a separate directory?

Many writers have remarked how complex GRUB 2 is, and I must agree. I don't understand it from any programming standpoint, but as a user it sure as h*ll is more complicated than was GRUB Legacy, for which almost anyone with a sense of adventure could guess at a bootable menuentry. Now, it's difficult to even read and partly understand the grub.cfg file.

As Experiment #1 shows, there is an easy way for the casual user to install two versions of Kubuntu in dual boot; however, the devil being in the details, should that user damage or delete or replace the second Kubuntu installation, she/he would lose their boot menu for booting the first Kubuntu installation and would then have to fix it manually or run Boot Repair.

It seems, as of this date, most users wanting to dual boot must be prepared for some manual configuration work. Especially so if you were to design your own GRUB 2 partition or GRUB 2 ESP directory (and then, how about updates to the GRUB software, how would they find their target?).

**Qqmike** · May 08, 2015, 01:54 PM

For the UEFI+GPT reading list.

Somehow, I missed this one until now. Excellent article on the ESP--what it is and what it isn't--and reading the boot variables.

The EFI System Partition and the Default Boot Behavior
http://blog.uncooperative.org/blog/2...tem-partition/

**Qqmike** · May 08, 2015, 05:15 PM

Continuing, in
https://www.kubuntuforums.net/showth...l=1#post371746

Experiment #3
As in Experiment #2, I created a second ESP and had hoped the Kubuntu installer and the ASUS firmware would use both ESPs--one to set up 14.04 and one to set up 15.04. This time, during the installation of 15.04, I explicitly chose the new--the second--ESP partition as the target for grub to be installed. This also failed: The Kubuntu installer didn't use the second ESP--it was left empty. The dual boot worked, but it worked exactly as in Experiment #1.

I knew, or I had read, that in UEFI mode, specifying a target partition for grub is pointless as the installer will do its proper UEFI thing in any case. I was hoping, though, that by using that choice in the Kubuntu installer, that it would work to activate the second ESP partition for the use of 15.04 grub booting files. Nope. Wrong.

Again, imo, both GRUB 2 (UEFI) and the Kubuntu UEFI installer could do a better job and help make this work.

(Btw, again, nothing seen in the ASUS UEFI boot setup menus; and nothing from efibootmgr -v.)

**Qqmike** · May 11, 2015, 09:30 AM

rEFInd

A solution to many dual-booting issues is a good boot manager. If your PC's UEFI boot manager is a good one, you have a solution there, assuming you don't mind pressing the keys necessary to access your system's UEFI boot menu.

So I can easily reference this topic to help people solve some booting problems on the forum, I want to make a brief post on rEFInd at this spot, in line with the above experiments on dual booting two Linux OSs.
Read a discussion with SteveRiley about rEFInd here:
https://www.kubuntuforums.net/showth...l=1#post371747

The maintainer of rEFInd is Rod Smith. Here's his page:
http://www.rodsbooks.com/refind/
You may also read his other pages on UEFI,
http://www.rodsbooks.com/linux-uefi/
His main page: http://www.rodsbooks.com/

On installing rEFInd, I made some notes for Kubuntu, I clipped and pasted those notes here:

Setting up booting in Kubuntu

(Assumes you have GRUB 2 installed. If you wish to remove GRUB 2 from your PC, please post questions in the general kubuntuforums and someone will advise you.)

Install Kubuntu. (Ignore this if you have a Kubuntu OS installed.)
Let it install GRUB 2 and set up the usual /boot/efi/EFI/ubuntu directory, populated by the GRUB boot files. Make a backup of this directory and contents, call it something like my_ubuntu_backups_dated, store it on flash drive.

If rEFInd is already installed, re-boot, let it run, hit the proper key (ESC) to refresh its boot menu.

If rEFInd is not already installed, install rEFInd:

Install rEFInd

https://launchpad.net/~rodsmith ; click on Personal Package Archive > rEFInd link and open this:
https://launchpad.net/~rodsmith/+archive/ubuntu/refind; Follow all instructions shown:

sudo add-apt-repository ppa:rodsmith/refind # add his PPA repository
sudo apt-get update
sudo apt-cache search refind
sudo apt-get install refind
and it ended saying, Installing it! rEFInd has been set as the default boot manager. Creating //boot/refind_linux.conf; edit it to adjust kernel options. Setting default boot options based on //etc/default/grub Installation has completed successfully.

Note: The PPA can be added to your system manually by copying the lines below and adding them to your system's software sources, /etc/apt/sources.list, make sure you have this in your /etc/apt/sources.list file (which you must edit as root):

# PPA for Rod Smith's rEFInd
deb http://ppa.launchpad.net/rodsmith/refind/ubuntu trusty main
deb-src http://ppa.launchpad.net/rodsmith/refind/ubuntu trusty main

But, it doesn't look like that takes care of the signing key & etc.
Thus, as above, I did the sudo add-apt-repository ppa:rodsmith/refind
Note: Example: Signing key: 4096R/9122E0C2; Fingerprint: 89C46C2592C9924469026E52DE32F3C29122E0C2

Then check it out:
Check /boot/efi/EFI/refind to see how it got installed
Then do:
sudo efibootmgr -v # to see your boot order (the NVRAM variables)
Then do:
tree /boot/efi

Then re-boot to try it.

Configure /boot/efi/refind/refind.conf (open as root to edit this file) <-- Optional
How you configure rEFInd is up to you. Open and read Rod Smith's guidance in the file /boot/efi/refind/refind.conf . You may not have to do anything if you are happy with its default settings.

Example, configuring rEFInd Here's what I did (two choices made in refind.conf):

I prefer text rather than the icons (on the rEFInd options screen) ...

# Use text mode only. When enabled, this option forces rEFInd into text mode.
# Passing this option a "0" value causes graphics mode to be used. Pasing
# it no value or any non-0 value causes text mode to be used.
# Default is to use graphics mode.
#
textonly

And this slight delay of 2 seconds:

# Delay for the specified number of seconds before scanning disks.
# This can help some users who find that some of their disks
# (usually external or optical discs) aren't detected initially,
# but are detected after pressing Esc.
# The default is 0.
#
scan_delay 2

Notes:
(Paraphrased from SteveRiley in the thread linked above) rEFInd will create its own NVRAM variable and set that to the highest boot priority. When you then boot the computer, rEFInd's list will show all discovered kernels, Windows (if you have it), and GRUB (rEFInd detects GRUB's EFI loader). So, it peacefully co-exists with what's already installed. rEFInd displays the list of discovered bootloaders each time you boot the computer. That's why it's superior to Gummiboot and to the UEFI bulit-in boot manager. Both these tools require you to manually copy all bootloaders (kernels for Linux, that .efi file for Windows) from their normal locations to the ESP itself. That's extra work that you must remember to perform each time you upgrade a kernel.

**xennex81** · May 11, 2015, 11:04 AM

I haven't read everything (and I can't, from a mobile phone), but it goes to show how complex this issue is (or, how complicated). Everything is ill-defined. Now we have a layer above the boot loader that can also be configured (above the boot record on the harddisk). RIGHT? Maybe I'm wrong. But I can't know, because everything is so ill-defined.

**Qqmike** · May 13, 2015, 02:59 PM

Continuing, in
Dual Booting Kubuntu 14.04 and 15.04, in UEFI mode
https://www.kubuntuforums.net/showth...l=1#post371746

Experiment #4: A second drive was added. Again, this was disappointing. With two ESPs--one on the HDD, one on the flash drive--I failed to populate a useful ESP on the flash drive. A successful setup doing so would have to be set up and configured manually, so it seems.

Experiments #1, #2, #3 were done on a system having one HDD.
For experiment #4, I plugged in a 16 GB USB 3.0 flash drive, kept it there, using it as one would use a HDD.

So, we have:

My regular desktop PC's HDD is sda; on sda is sda1 = the ESP for the HDD. Kubuntu 14.04 is installed to sda2.
The flash drive is sdb; on sdb is sdb1 = the ESP for the flash drive. Kubuntu 14.04 is installed to sdb2.
(The Kubuntu installation is a regular, 64-bit, permanent installation; i.e., the flash drive is NOT a live Kubuntu UFD.)

Result:

-- GRUB 2 from the Kubuntu 14.04 on the flash drive took over everything!
-- The ESP on the flash drive is empty--unused--even though during the installation of Kubuntu I directed sdb1 to be used as the ESP and the installer indicated it was "...installing [grub] to sdb1 ..." in the progress indicator.
-- GRUB 2 installed itself to the ESP on sda1: /boot/efi/EFI/ubuntu, overwriting the setup that was there previously. It wrote a new grub.cfg that showed Kubuntu on sda2 and Kubuntu on sdb2, listing sdb2 (the flash drive) first.
-- Upon re-booting and entering ASUS UEFI BIOS setup (by pressing F2), the boot menu changed to show the flash drive first; the rEFInd on sda2 is listed second; and so on. Previously (before using the flash drive at all), rEFInd was first in boot order and controlled everything on the HDD sda.
-- Upon re-booting, if you don't enter the ASUS UEFI BIOS setup (by pressing F2), you will boot by default to Kubuntu 14.04 on the flash drive, sdb2.
-- Upon re-booting, if you enter the ASUS UEFI BIOS setup (by pressing F2), you can select whatever you need from the Boot Override menu--everything on both drives (HDD and flash drive) is listed. If you select rEFInd, you can boot directly to the kernel located on the flash drive, sdb2, and thus boot into Kubuntu 14.04 on the flash drive sdb2.
-- I booted into Kubuntu on the flash drive and installed rEFInd from there. rEFInd installed itself NOT to the ESP on the flash drive (sdb1), but to the ESP on the HDD at sda1. It did, however, set itself up as #1 in the boot order (the NVRAM variables in the ASUS UEFI firmware).

=> Thus, it all works. You can boot into anything on either drive--the HDD sda or the flash drive sdb. But it is all controlled by the ESP files on the HDD sda; the ESP on the flash drive sdb1 is empty. GRUB 2, when installed in the Kubuntu on the flash drive truly did take over the show and wrote its boot files and grub.cfg to the ESP on the HDD sda1. And rEFInd seemed to follow. The ESP on the flash drive sdb1 remains empty, unused.

**Qqmike** · May 14, 2015, 02:04 PM

Fix UEFI+GPT with Testdisk & gdisk -- Deleted partitions & damaged GPT structure

Summary
For a UEFI+GPT setup, if you damaged your GPT structure, or if you accidentally lost/damaged your partitions, you may be able to use TestDisk and gdisk to recover. One goal here is to see how TestDisk worked on GPT. Good news: It recovers deleted partitions. But: I could not use TestDisk to repair either the Partition Header or the Partition Table entries. For those two tasks, I used gdisk. I did five experiments. There are references included along the way for everything. (If you can use TestDisk to fix the damage described in experiments 4 & 5, let us know.)

Set-up

ASUS UEFI+GPT system, desktop PC
/dev/sda: HDD: Kubuntu 14.04
/dev/sdb: USB 3.0 flash drive, set up for this test, contains 5 partitions, including ESP, bootable Kubuntu 14.04, /home, /swap, and an ext4 data partition.
All experiments were applied to the flash drive.

The flash drive setup
First, for reference, here's what the flash drive looks like before the experiments:

Code:

 [SIZE=3]sudo gdisk -l /dev/sdb[/SIZE]
 [SIZE=3]GPT fdisk (gdisk) version 0.8.8[/SIZE]
 

 [SIZE=3]Partition table scan:[/SIZE]
   [SIZE=3]MBR: protective[/SIZE]
   [SIZE=3]BSD: not present[/SIZE]
   [SIZE=3]APM: not present[/SIZE]
   [SIZE=3]GPT: present[/SIZE]
 
 [SIZE=3]Found valid GPT with protective MBR; using GPT.[/SIZE]
 [SIZE=3]Disk /dev/sdb: 30728832 sectors, 14.7 GiB[/SIZE]
 [SIZE=3]Logical sector size: 512 bytes[/SIZE]
 [SIZE=3]Disk identifier (GUID): E300869C-A7DA-4A42-9CF2-A7D6F72288FD[/SIZE]
 [SIZE=3]Partition table holds up to 128 entries[/SIZE]
 [SIZE=3]First usable sector is 34, last usable sector is 30728798[/SIZE]
 [SIZE=3]Partitions will be aligned on 2048-sector boundaries[/SIZE]
 [SIZE=3]Total free space is 418365 sectors (204.3 MiB)[/SIZE]
 
 [SIZE=3]Number  Start (sector)    End (sector)  Size       Code  Name[/SIZE]
    [SIZE=3]1            2048          411647   200.0 MiB   EF00  [/SIZE] 
    [SIZE=3]2          411648        12699647   5.9 GiB     8300  [/SIZE] 
    [SIZE=3]3        12699648        14952447   1.1 GiB     8300  [/SIZE] 
    [SIZE=3]4        14952448        17000447   1000.0 MiB  8200  [/SIZE] 
    [SIZE=3]5        17000448        30312447   6.3 GiB     8300 [/SIZE]

TestDisk setup
To set the details aside, I will include a technical section at the end showing you how to set up and use TestDisk. For now, assume it is installed and ready in a location where you will do this work. You can do this work from three choices: Another Kubuntu partition or disk, a rescue CD/DVD, or a live Kubuntu DVD that you use as a rescue CD/DVD.

Experiments

Experiment 1 Delete and recover a data partition, with TestDisk
Experiment 2 Delete and recover the /home partition of an OS, with TestDisk
Experiment 3 Delete and recover an OS partition, with TestDisk
Experiment 4 Repair a damaged Partition Table Header: gdisk works; TestDisk did not work.
Experiment 5 Repair a damaged Partition Table: gdisk works; TestDisk did not work.

Code:

 [SIZE=3]error: failure to read sector[etc--repeating different sectors]Experiment 1   Delete and recover a data partition, with TestDisk
 
 In GParted, delete ext 4 partition sdb5.  Of course, that does not generate any errors or problems upon re-booting as it was only a data partition.
 Re-boot into my regular 14.04 (on sda2) to run TestDisk and recover the partition. No problems, straightforward.  TestDisk works well on the GPT as it does on MBR.
 You have to reboot for the change to take effect, and you must re-boot anyway to test it.
 

 Experiment 2   Delete and recover the /home partition of an OS, with TestDisk
 
 sdb2 is for Kubuntu 14.04, its /home partition is sdb3.  Delete sdb3 and see what happens.  TestDisk worked easily.  Reboot for the change to take effect and to test it.
 

 Experiment 3  Delete and recover an OS partition, with TestDisk
 
 sdb2 is for Kubuntu 14.04, its /home partition is sdb3.  Delete sdb2 and see what happens.
 Re-boot to see the effect:
 Black screen white print:
 
 [SIZE=3]error: no such device [listed the UUID][/SIZE]
 [SIZE=3]error: disk 'hd1,gpt2' not found[/SIZE]
 [SIZE=3]Aborted. Press any key to exit.[/SIZE]

Start TestDisk (from Kubuntu 14.04 on sda2) and try to fix it: OK, no problem.
Re-boot. OK, worked fine.

[/SIZE]GPT -- the GUID Partition Table experiments

Check these references for GPT structure, and see Technical Note at the end of this post:

GPT, UEFI -- Study Guide, Post #109 in this thread (above):
https://www.kubuntuforums.net/showth...l=1#post346604
and see
https://en.wikipedia.org/wiki/GUID_Partition_Table

This for the dd command:
The dd Command
https://www.kubuntuforums.net/showth...The-dd-Command

In quick summary, the structure of the GPT setup is as follows:

Protective MBR -- 512 bytes
Partition Table Header -- 512 bytes
The Partition Table entries (128 of them are available in this setup, each has 128 bytes).
The actual partitions (those listed in the Partition Table entries)
The end-of-disk backup to the Partition Table
The end-of-disk backup to the Partition Table Header

Thus, to cause damage to the partition table, it seems it would be sufficient to write zeros to the Partition Table Header, and/or to the actual Partition Table entries. You could also cause damage to the Protective MBR, as an experiment, but since mine is basically empty, I did not mess with it (it is easy to do, if you wish to try, as you'll see).

To see current Protective MBR in the UEFI+GPT setup:

Code:

 [SIZE=3]sudo dd if=/dev/sdb bs=512 count=1 | hexdump -C[/SIZE]
 [SIZE=3]1+0 records in[/SIZE]
 [SIZE=3]1+0 records out [/SIZE] 
 [SIZE=3]0.000899789 s, 569 kB/s[/SIZE]
 [SIZE=3]512 bytes (512 B) copied[/SIZE]
 [SIZE=3]00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|[/SIZE]
 [SIZE=3]000001c0  01 00 ee fe ff ff 01 00  00 00 7f e2 d4 01 00 00  |................|[/SIZE]
 [SIZE=3]000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|[/SIZE]
 [SIZE=3]*[/SIZE]
 [SIZE=3]000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 [B]55 aa[/B]  |..............U.|[/SIZE]
 [SIZE=3]00000200[/SIZE]

You can see the EOF indicated by the hex 55 aa. There are mostly zeros, but a few entries.
On the left are hex locations (e.g., 000001d0), indicating a count of the records (the bytes) in the printout of the table. Get a hex-decimal calculator (on-line or Qalculate) to do your own calculations. The asterisk * indicates repeated zeros.

Experiment 4 Repair a damaged Partition Table Header: gdisk works; TestDisk did not work.

We can damage the Partition Table Header by writing zeros to part of it. I''ll write 500 zeros to it (skipping over the Protective MBR):

sudo dd if=/dev/zero of=/dev/sdb bs=1 seek=512 count=500
Then using
sudo dd if=/dev/sdb bs=512 count=2 | hexdump -C
you can see the 500 zeros we put there following the EOF of the Protective MBR:

Write 500 zeros over th Partition Table Header (skipping the Protective MBR with seek=512):

Code:

 [SIZE=3]sudo dd if=/dev/zero of=/dev/sdb bs=1 seek=512 count=500[/SIZE]
 [SIZE=3]500+0 records in[/SIZE]
 [SIZE=3]500+0 records out[/SIZE]
 [SIZE=3]500 bytes (500 B) copied, 0.0193112 s, 25.9 kB/s[/SIZE]

Check it out to see it (examine the first two sectors of 512 bytes each):

Code:

 [SIZE=3]mike@mike-desktop:~$ sudo dd if=/dev/sdb bs=512 count=2 | hexdump -C[/SIZE]
 [SIZE=3]2+0 records in[/SIZE]
 [SIZE=3]2+0 records out[/SIZE]
 [SIZE=3]1024 bytes (1.0 kB) copied[/SIZE]
 [SIZE=3]0.00151993 s, 674 kB/s[/SIZE]
 [SIZE=3]00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|[/SIZE]
 [SIZE=3]000001c0  01 00 ee fe ff ff 01 00  00 00 7f e2 d4 01 00 00  |................|[/SIZE]
 [SIZE=3]000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|[/SIZE]
 [SIZE=3]*[/SIZE]
 [SIZE=3]000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 [B]55 aa[/B]  |..............U.|[/SIZE]
 [SIZE=3]00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|[/SIZE]
 [SIZE=3]*[/SIZE]
 [SIZE=3]0000[U]0400[/U][/SIZE]

Note the EOF 55aa of the Protective MBR, then the following zeros in the Partition Table Header. Note that hex 0400 = 1024 decimal = 2 x 512.

Now re-boot to see what happens. Tried to boot into Kubuntu 12.04 on sdb2. Same error sequence I got in Experiment #3 above.
Use TestDisk to try to fix this partition table: Doesn't look like TestDisk can fix this, although it did identify the faulty GPT Partition and signature. It is not fixed.

I remembered Rod Smith's website, the writer of gdisk for GPT:
http://www.rodsbooks.com/gdisk/repairing.html

From my regular Kubuntu 14.04 on sda2, I ran this:

Code:

 [SIZE=3]sudo gdisk -l /dev/sdb[/SIZE]
 [SIZE=3]GPT fdisk (gdisk) version 0.8.8[/SIZE]
  
 [SIZE=3]Caution: invalid main GPT header, but valid backup; regenerating main header[/SIZE]
 [SIZE=3]from backup![/SIZE]
                           
[SIZE=3]Partition table scan:[/SIZE]
   [SIZE=3]MBR: protective[/SIZE]
   [SIZE=3]BSD: not present[/SIZE]
   [SIZE=3]APM: not present[/SIZE]
   [SIZE=3]GPT: damaged[/SIZE]
  
 [SIZE=3]****************************************************************************[/SIZE]
 [SIZE=3]Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk[/SIZE]
 [SIZE=3]verification and recovery are STRONGLY recommended.[/SIZE]
 [SIZE=3]****************************************************************************[/SIZE]
 [SIZE=3]Disk /dev/sdb: 30728832 sectors, 14.7 GiB[/SIZE]
 [SIZE=3]Logical sector size: 512 bytes[/SIZE]
 [SIZE=3]Disk identifier (GUID): 851B055F-55AC-C846-B925-643E27AEB146[/SIZE]
 [SIZE=3]Partition table holds up to 128 entries[/SIZE]
 [SIZE=3]First usable sector is 34, last usable sector is 30728798[/SIZE]
 [SIZE=3]Partitions will be aligned on 2048-sector boundaries[/SIZE]
 [SIZE=3]Total free space is 418381 sectors (204.3 MiB)[/SIZE]
  
 [SIZE=3]Number  Start (sector)    End (sector)  Size       Code  Name[/SIZE]
    [SIZE=3]1            2048          411647   200.0 MiB   EF00  [/SIZE] 
    [SIZE=3]2          411648        12699647   5.9 GiB     0700  [/SIZE] 
    [SIZE=3]3        12699648        14952447   1.1 GiB     0700  [/SIZE] 
    [SIZE=3]4        14952448        17000431   1000.0 MiB  8200  [/SIZE] 
    [SIZE=3]5        17000448        30312447   6.3 GiB     0700  [/SIZE]

BUT IT DIDN'T FIX IT.

So, try using the gdisk program to fix it:

Code:

 [SIZE=3]sudo gdisk /dev/sdb[/SIZE]
 [SIZE=3]Command (? for help): ?[/SIZE]
 [SIZE=3]b       back up GPT data to a file[/SIZE]
 [SIZE=3]c       change a partition's name[/SIZE]
 [SIZE=3]d       delete a partition[/SIZE]
 [SIZE=3]i       show detailed information on a partition[/SIZE]
 [SIZE=3]l       list known partition types[/SIZE]
 [SIZE=3]n       add a new partition[/SIZE]
 [SIZE=3]o       create a new empty GUID partition table (GPT)[/SIZE]
 [SIZE=3]p       print the partition table[/SIZE]
 [SIZE=3]q       quit without saving changes[/SIZE]
 [SIZE=3]r       recovery and transformation options (experts only)[/SIZE]
 [SIZE=3]s       sort partitions[/SIZE]
 [SIZE=3]t       change a partition's type code[/SIZE]
 [SIZE=3]v       verify disk[/SIZE]
 [SIZE=3]w       write table to disk and exit[/SIZE]
  [SIZE=3]x       extra functionality (experts only)[/SIZE]          
[SIZE=3]?       print this menu[/SIZE]
  
 [SIZE=3]Command (? for help): r[/SIZE]
                             
[SIZE=3]Recovery/transformation command (? for help): ?[/SIZE]
 [SIZE=3]b       use backup GPT header (rebuilding main)[/SIZE]
 [SIZE=3]c       load backup partition table from disk (rebuilding main)[/SIZE]
 [SIZE=3]d       use main GPT header (rebuilding backup)[/SIZE]
 [SIZE=3]e       load main partition table from disk (rebuilding backup)[/SIZE]
 [SIZE=3]f       load MBR and build fresh GPT from it[/SIZE]
 [SIZE=3]g       convert GPT into MBR and exit[/SIZE]
 [SIZE=3]h       make hybrid MBR[/SIZE]
 [SIZE=3]i       show detailed information on a partition[/SIZE]
 [SIZE=3]l       load partition data from a backup file[/SIZE]
 [SIZE=3]m       return to main menu[/SIZE]
 [SIZE=3]o       print protective MBR data[/SIZE]
 [SIZE=3]p       print the partition table[/SIZE]
 [SIZE=3]q       quit without saving changes[/SIZE]
 [SIZE=3]t       transform BSD disklabel partition[/SIZE]
 [SIZE=3]v       verify disk[/SIZE]
 [SIZE=3]w       write table to disk and exit[/SIZE]
 [SIZE=3]x       extra functionality (experts only)[/SIZE]
 [SIZE=3]?       print this menu[/SIZE]
 
  [SIZE=3]Recovery/transformation command (? for help): b[/SIZE]
  
 [SIZE=3]Recovery/transformation command (? for help): w[/SIZE]
 [SIZE=3]Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING[/SIZE]
 [SIZE=3]PARTITIONS!![/SIZE]
                        
[SIZE=3]Do you want to proceed? (Y/N): y[/SIZE]
 [SIZE=3]OK; writing new GUID partition table (GPT) to /dev/sdb.[/SIZE]
 [SIZE=3]The operation has completed successfully.[/SIZE]

Looks OK (at least it wrote something there!):

Code:

 [SIZE=3]sudo dd if=/dev/sdb bs=512 count=2 | hexdump -C[/SIZE]
 [SIZE=3]2+0 records in[/SIZE]
 [SIZE=3]2+0 records out[/SIZE]
 [SIZE=3]0.00139589 s, 734 kB/s[/SIZE]
 [SIZE=3]00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|[/SIZE]
 [SIZE=3]*[/SIZE]
 [SIZE=3]1024 bytes (1.0 kB) copied000001c0  01 00 ee fe ff ff 01 00  00 00 7f e2 d4 01 00 00  |................|[/SIZE]
 [SIZE=3]000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|[/SIZE]
 [SIZE=3]*[/SIZE]
 [SIZE=3]000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|[/SIZE]
 [SIZE=3]00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|[/SIZE]
 [SIZE=3]00000210  d2 d7 cd 80 00 00 00 00  01 00 00 00 00 00 00 00  |................|[/SIZE]
 [SIZE=3]00000220  7f e2 d4 01 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|[/SIZE]
 [SIZE=3]00000230  5e e2 d4 01 00 00 00 00  5f 05 1b 85 ac 55 46 c8  |^......._....UF.|[/SIZE]
 [SIZE=3]00000240  b9 25 64 3e 27 ae b1 46  02 00 00 00 00 00 00 00  |.%d>'..F........|[/SIZE]
 [SIZE=3]00000250  80 00 00 00 80 00 00 00  36 3e 38 66 00 00 00 00  |........6>8f....|[/SIZE]
 [SIZE=3]00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|[/SIZE]
 [SIZE=3]*[/SIZE]
 [SIZE=3]00000400[/SIZE]

Re-boot to try it. It worked: The Kubuntu OS on sdb2 booted fine.

Experiment #5 Repair a damaged Partition Table: gdisk works; TestDisk did not work.

Cause damage to the actual Partition Table entries, where the 5 partitions of sdb are listed.
Each partition has 128 bytes as a Partition Table entry. 5 partitions = 5x128 = 640 bytes. (The Partition Table is 128 x 128 = 16,384 bytes.)

You can look at 1024 bytes following the Protective MBR and the Partition Table Header:
sudo dd if=/dev/sdb bs=512 skip=2 count=2 | hexdump -C
and see stuff there--either garbage or valid entries in the partition table.

We can damage 1024 bytes of it by writing zeros. Note the use of seek and skip in the dd statement, see man dd.

Code:

 [SIZE=3]sudo dd if=/dev/zero of=/dev/sdb bs=512 seek=2 count=2[/SIZE]
 [SIZE=3]2+0 records in[/SIZE]
 [SIZE=3]2+0 records out[/SIZE]
 [SIZE=3]1024 bytes (1.0 kB) copied, 0.00315958 s, 324 kB/s[/SIZE]

Check to see the zeros:

Code:

 [SIZE=3]sudo dd if=/dev/sdb bs=512 skip=2 count=2 | hexdump -C[/SIZE]
 [SIZE=3]2+0 records in[/SIZE]
 [SIZE=3]2+0 records out[/SIZE]
 [SIZE=3]1024 bytes (1.0 kB) copied[/SIZE]
 [SIZE=3]0.00118284 s, 866 kB/s[/SIZE]
 [SIZE=3]00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|[/SIZE]
 [SIZE=3]00000400[/SIZE]

Re-boot to see the effect of the damage to the Partition Table entry array: Same "white print on a black screen" message as above in Experiment #3: no disk.

Try to fix this using gdisk:

Code:

 [SIZE=3]sudo gdisk /dev/sdb[/SIZE]
  
 [SIZE=3]GPT fdisk (gdisk) version 0.8.8[/SIZE]
  
 [SIZE=3]Caution! After loading partitions, the CRC doesn't check out![/SIZE]
 [SIZE=3]Warning! Main partition table CRC mismatch! Loaded backup partition table[/SIZE]
 [SIZE=3]instead of main partition table![/SIZE]
  
 [SIZE=3]Warning! One or more CRCs don't match. You should repair the disk![/SIZE]
  
 [SIZE=3]Partition table scan:[/SIZE]
   [SIZE=3]MBR: protective[/SIZE]
   [SIZE=3]BSD: not present[/SIZE]
   [SIZE=3]APM: not present[/SIZE]
   [SIZE=3]GPT: damaged[/SIZE]
  
 [SIZE=3]****************************************************************************[/SIZE]
 [SIZE=3]Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk[/SIZE]
 [SIZE=3]verification and recovery are STRONGLY recommended.[/SIZE]
 [SIZE=3]****************************************************************************[/SIZE]
                        
[SIZE=3]Command (? for help): ?[/SIZE]
 [SIZE=3]... [same menu as above] ...[/SIZE]
 [SIZE=3]r       recovery and transformation options (experts only)[/SIZE]
 [SIZE=3]... [same menu as above] ...[/SIZE]
 [SIZE=3]w       write table to disk and exit[/SIZE]
  
 [SIZE=3]Command (? for help): r[/SIZE]
  
 [SIZE=3]Recovery/transformation command (? for help): ?[/SIZE]
 [SIZE=3]b       use backup GPT header (rebuilding main)[/SIZE]
 [SIZE=3]c       load backup partition table from disk (rebuilding main)[/SIZE]
 [SIZE=3]... [same menu as above] ...[/SIZE]
 [SIZE=3]w       write table to disk and exit[/SIZE]
 [SIZE=3]... [same as menu above] ...[/SIZE]
  
 [SIZE=3]Recovery/transformation command (? for help): c[/SIZE]
 [SIZE=3]Warning! This will probably do weird things if you've converted an MBR to[/SIZE]
 [SIZE=3]GPT form and haven't yet saved the GPT! Proceed? (Y/N): y[/SIZE]
  
 [SIZE=3]Recovery/transformation command (? for help): w[/SIZE]
  
 [SIZE=3]Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING[/SIZE]
 [SIZE=3]PARTITIONS!![/SIZE]
                        
[SIZE=3]Do you want to proceed? (Y/N): y[/SIZE]
 [SIZE=3]OK; writing new GUID partition table (GPT) to /dev/sdb.[/SIZE]
 [SIZE=3]The operation has completed successfully.[/SIZE]

Check to see that gdisk did indeed put something there, using this command:
sudo dd if=/dev/sdb bs=512 skip=2 count=2 | hexdump -C
(remember we are skipping the Protective MBR (512 B) and the Partition Table Header (512 B))

Looks like it might be OK. Re-boot to try it. It worked, sdb2 booted fine.
And sudo gdisk -l /dev/sdb shows no problems.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Technical note: TestDisk

Downloading TestDisk/PhotoRec to a personal directory.

> Create a directory for it and download TestDisk into that folder:

Choose a directory to work in. Obvious choices might be your home or Desktop.
For the example, let's use /home/your_name/Desktop/TestDisk_here.
Next, download TestDisk (it includes PhotoRec) to that directory.
Download TestDisk/PhotoRec from the site
http://www.cgsecurity.org/wiki/TestDisk_Download
Select Linux and the proper version for your computer.
Your browser may be set to download to Desktop, or you may be able to select the directory /home/your_name/Desktop/TestDisk_here for the download. In the former case, move the downloaded file testdisk-7.0.linux26-x86_64.tar.bz2 into the TestDisk_here folder.
> To extract the folder (and files) from the tar.bz2 file ...
> Starting in the folder TestDisk_here, right click on testdisk-7.0.linux26-x86_64.tar.bz2 and select Extract here.
You want to keep everything—the tar.bz2 and the extracted folder/files-- in the folder TestDisk_here because it will be simpler to manage and contained where you can work with it. It is also the folder you probably want PhotoRec to save the recovered files to if you use PhotoRec. TestDisk will place its log files there, also.

Explore the subfolder TestDisk_here/testdisk-7.0 to find the TestDisk executable (program), testdisk_static. That's the program you'll run.

At Konsole, change into /home/your_name/Desktop/TestDisk_here/testdisk-7.0 (where testdisk-7.0 is the final subdirectory containing the two executables testdisk_static and photorec_static), and then, to run TestDisk or PhotoRec from there:
sudo ./testdisk_static
Or,
sudo ./photorec_static
where the leading dot slash ./ means “the current working directory."
Or, this way:
cd into /home/your_name/Desktop/TestDisk_here and run
sudo testdisk-7.0/testdisk_static

You can easily keep the log files in TestDisk folder.

Using TestDisk: The tutorials at the website are sufficient if you study them carefully.
Step-by-Step
http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step
http://www.cgsecurity.org/wiki/TestDisk

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Technical note: GPT structure

For the GPT partition table, we need this from the GPT, UEFI Study Guide, Post #109 above, https://www.kubuntuforums.net/showth...l=1#post346604

-- GPT. This is also easy, but flexible!

At the start of this article:
http://en.wikipedia.org/wiki/GUID_Partition_Table
on the right, is an excellent graphic of the GPT layout and scheme.

In the GPT scheme, space is still set aside for a traditional 512-byte MBR, at location LBA 0 (the first 512-byte sector of the disk); and it is called the "protective MBR." (If the GPT sector size is greater than 512 bytes, then there will be a gap after the MBR and before the Partition Table Header.)

Then, at the start of the GPT is the header, the Partition Table Header, starting at the second sector of the disk, or LBA 1.
And then comes the partition table, or "partition entry array," at LBA 2, containing the partition entries, one entry for each partition.
Then come the actual partitions on the disk.
The last sector of the disk (LBA -1) contains the secondary or backup Partition Table Header; and the sector preceding the last sector (LBA -2) contains the secondary or backup partition table.

The thing to note is that the sector size need not be 512 bytes; it can be anything.
And this: "The EFI stipulates a minimum of 16,384 bytes be reserved for the partition table array, so there are 128 partition entries reserved, each 128 bytes long."

--> Thus, you can have 128 partitions with a GPT setup.

If you know the sector size, you can always picture where you're at on the GPT disk. (By the way, of course, both the bootloader and the OS must be aware of the sector size used.)

The LBA 34 thing ...
For example, if the sector size is 512 bytes ...
... and if the partition table has a full 128 entires, each 128 bytes long, that's 16,384 bytes, or 32 sectors (each 512 bytes). Add 1 sector for the protective MBR and 1 sector for the Partition Table Header, you get 34 sectors (each 512 bytes). So LBA 34 (the 35th sector) would be the first available address for the start of the first partition (but for optimal partition alignment, you may choose a larger sector number for starting the first partition, such as the 1 MiB mark = 2048 sectors (each 512 bytes)).

Announcement

GRUB 2: A Guide for Users

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment