GRUB 2: A Guide for Users

[Qqmike]

rEFInd: Make a live CD to boot into your system

rEFInd: Make a live CD to boot into your system


If you move into the newer UEFI booting with the GPT partition model (and have a newer computer equipped to do so, say > 2011-2012), and especially if you are dual/multi-booting, keeping a rEFInd CD handy might be a smart thing to do. It's easy and quick. If you are unable to boot normally into your OS, you can use the rEFInd CD to do so. Once you are there, you can then try to fix whatever problem you are having.

For rescue or emergencies:
You can make a rEFInd CD in a live Kubuntu session, using your Kubuntu live USB flash drive installer. You can not do this if you are using a live Kubuntu DVD unless you have two CD/DVD drives in your computer. You need a free CD drive for making the rEFInd CD.
--> See the tips at the end (below) for how to do this.

If you prefer to make a rEFInd USB, see this:
https://www.kubuntuforums.net/showth...l=1#post379352

rEFInd is a boot manager for UEFI booting that should be able to boot all you bootable media, files, OSs, and it is discussed elsewhere:
UEFI for Kubuntu--simplified
https://www.kubuntuforums.net/showth...l=1#post373198


Where to get it and how to do it

Get the CD-R Image from here (click link):
http://www.rodsbooks.com/refind/getting.html

Download the file:
For example, refind-cd-0.8.7.zip -- downloaded to my Downloads folder: /home/mike/Downloads.
Create a directory (a folder) for the iso: refind_iso_CD; so now you have /home/mike/Downloads/refind_iso_CD.
Move the .zip file into the folder you just created.
Unzip the file:
right-click on refind-cd-0.8.7.zip, Extract > Extract archive here;
inside that folder you will now find the iso: refind-cd-0.8.7.iso;
open k3b and burn the iso to a CD (in k3b, you can navigate to that iso by clicking the browse icon)..
(K > Applications > System > Disk burning (K3b) -> choose more actions, then burn image)

Test it by booting your computer with the CD
Re-boot your computer with the rEFInd CD.
At the POST, enter your UEFI setup (by pressing the correct key for your computer).
Select from the boot/boot override menu to boot from the rEFInd CD in UEFI mode.
Example: mine showed up as
UEFI(FAT)TSSTcorpCDDVDSH-224DB(1MB)
(select it, press Enter to boot--Note the UEFI string descriptor)

The rEFInd screen
Use arrow keys to navigate to an icon. A description of the (boot) option represented by that icon appears below the two rows of icons; eg., Boot EFI\ubuntu\grubx64.efi from ESP_sda1
(back slashes are used in UEFI; forward slashes are used in your Linux: they mean the same thing)

In my example, I see 27 boot options! (I have 12 partitions and all sorts of OSs, ESPs, and .efi's.)

You will also see an EFI Shell (the terminal icon) and other options: shutdown; restart; re-boot to computer Setup utility (= your firmware setup).

The EFI shell is for advanced users. Most users will instead use the simpler efibootmgr command (from their OSs or from a live OS DVD/USB) to work with their UEFI setup (see man efibootmgr). So be careful here, but I'll mention it anyway:

Start EFI shell (by clicking on the terminal icon). To see just one page of output at a time on your screen, use the -b option in commands.
To see the help menu listing of commands:
Shell> help -b
To list the NVRAM boot variables, one page at a time:
Shell> bcfg boot dump -v -b
To Exit the EFI shell and return to your rEFInd menu:
Shell> exit

Important UEFI Shell Commands
https://wiki.archlinux.org/index.php...ace#UEFI_Shell

EFI Shells and Scripting
https://software.intel.com/en-us/art...and-scripting/m


/////////////////////////////////////////////


In a live Kubuntu session ...

Tips for doing this work in a live Kubuntu session, booting your computer with your Kubuntu USB flash drive installer.

Boot your computer with your Kubuntu USB flash drive plugged in.
At the POST screen, press the magic key for your computer to enter your UEFI firmware ("BIOS") setup menus and find the boot menu(s).
Select your USB flash drive from the boot menu, making sure it says UEFI in its description.
Your computer will boot to a Kubuntu live session.
Select Start Kubuntu.
Select Try Kubuntu.
Open Firefox (K > Firefox, or K > Applications > Internet > Firefox).

Now proceed exactly as above: Where to get it and how to do it, but note that in your live session, the home folder you will use might be called something like /home/kubuntu, then /home/kubuntu/Downloads. To navigate to it, you might have to open Dolphin, click the red root place on the left side bar, click home, then kubuntu, then Downloads, and you are there.

After k3b finishes burning your rEFInd CD, it will eject that CD.
Then exit your live session: K > Leave > Restart
and you will be prompted to remove your live Kubuntu USB flash drive.

[Qqmike]

Installing Kubuntu -- Using the "Manual" Installation Type, with your own partitioning


Contents:
Installing GParted (gparted)
Setting up your partitions using GParted
Special steps for UEFI: ESP; creating GPT
Ways to use your live Kubuntu DVD/USB
Using the Manual installation method when installing Kubuntu

Two steps:
-- First, set up your partitions for Kubuntu.
-- Then install Kubuntu using the "Manual" method of installation.

--> If you've already set up the partitions you want to use, skip Step 1 and go to Step 2.

Note: For an UEFI installation, you need an EFI System Partition (ESP)--see below.


Step 1 Partitioning for Kubuntu

Many long-time users of Kubuntu prefer to do their own partitioning using GParted (or similar programs) instead of allowing the Kubuntu installer to do the partitioning.

Instead of using GParted, you may use the partitioning tool that comes with Kubuntu, the KDE Partition Manager. You'll find it in Kubuntu and in the live Kubuntu USB/DVD as K > Applications > System > KDE Partition Manager If you want to use KDE Partition Manager, you may skip all references to GParted below.



Three choices for running GParted:

-- If you have a Kubuntu/Linux OS installed to a disk on your computer that is separate from the partition you wish to use for the new Kubuntu, you can run gparted from your existing Kubuntu/Linux OS. (You may have to install gparted to your existing OS, though--see the Tip below.)
or,
-- You can use GParted from a live CD/USB;
or,
-- You can run the Kubuntu installer (live) DVD/USB, select "Try Kubuntu" to run a live session, install "gparted" in your live session and use it there (prior to installing Kubuntu from the live DVD/USB).

--> For doing this, see the Tips below.


Partitioning:
So, use GParted to partition your drive for Kubuntu, making partitions for root /, and /home (if you use a separate home partition), and swap. If you already have a swap partition set up for another K(U)buntu/Linux OS, you do not need to create another swap partition for the Kubuntu OS you are installing now.


For UEFI systems, you need GPT and ESP:

-- GPT
If this is a new disk, or an existing disk you are clearing for Kubuntu, for a UEFI installation you should partition the disk as a GUID Partition Table (GPT).
In GParted: Device > Create Partition Table, Select new partition table type: gpt.
-- ESP
For UEFI, you need an EFI System Partition (ESP). It should be 100-512 MB (512 MB is preferred, but 200 MB is also OK), format as FAT 32, and in GParted set the "boot" flag on the partition (by: highlight the ESP, then Partition > Manage Flags > boot). It is common to use the first partition for the ESP; this is not required, but it may be good practice if it works out that way for you. I've seen some systems use the second partition. In theory, you can use any partition for the ESP.

Reference on UEFI, ESP, GPT:
UEFI for Kubuntu--simplified ... and some dual-booting tips for Kubuntu
https://www.kubuntuforums.net/showth...l=1#post373198


Tips for installing and using GParted

GParted Live CD/USB

The live CD/USB:
http://gparted.org/livecd.php
The Manual shows you how to do partitioning operations:
http://gparted.org/display-doc.php?n...ed-live-manual
Make sure you choose the right version of GParted, read the Note:
http://gparted.org/download.php
--> For UEFI and newer computers, select the correct version (indicated on the site).


Installing GParted (gparted) in Kubuntu or in a live Kubuntu session

Live session details: You can run the live Kubuntu installation DVD/USB, and before installing Kubuntu, you can do the partitioning in the live session, first by installing gparted in your live session. When you re-boot your computer with the Kubuntu installer DVD/USB inserted, boot into it (by entering your computer's UEFI or BIOS firmware setup and selecting the DVD/USB), then you may see a GRUB menu from which you should select "*Try Kubuntu," then at the Welcome screen, Live Session User, simply press Enter to log in to your Kubuntu live session.

Installing gparted in Kubuntu (whether it is a live session or an installed Kubuntu OS)
Two methods:
-- Use Muon (K > Applications > System > Software Center (Muon Discover)). In Search, type gparted, then Install.
-- Use the command line Konsole (K > Applications > System > Terminal (Konsole))
Type
sudo apt-get install gparted
press Enter, answer any questions with Yes (Y).

Where to find GParted after installing it
Probably here: K > Applications > System > Partition Editor (GParted).


Step 2 Install Kubuntu using the "Manual" method of installation

--> I'll assume you are booting up the Kubuntu DVD/USB fresh. If you already booted into the live Kubuntu session to do the partitioning (see above), then simply exit your live session and select Install Kubuntu to get going.

If you already have your live Kubuntu DVD/USB installer medium, skip down below to "Boot your computer with the Live Kubuntu medium." Otherwise:

Download Kubuntu, check it, and make the installer medium
Download the correct version of Kubuntu (use 64-bit for newer UEFI+GPT systems). Run checks on it (MD5 or Shasums).
Burn the iso image to DVD (using K3b or similar), or make a live USB flash drive
( https://www.kubuntuforums.net/showth...aller-using-dd ).


Boot your computer with the Live Kubuntu medium
Reboot your computer with the DVD or flash drive installed.
At the computer's POST screen, hit the proper key to enter the firmware ("BIOS") setup.
Locate the boot or boot override menu.
Select the DVD or USB flash drive to boot from.
(If you are installing in UEFI mode: Your DVD or flash drive may have more than one boot menu entry; choose the entry that says UEFI or EFI.)

--> Thus, boot your PC with the DVD/USB Kubuntu installer medium.

Get to the Kubuntu welcome page and select Install Kubuntu (your other choice will be to Try Kubuntu [without installing]).


Installation Type screen: Select Manual.

Prepare Partition screen (the left side bar may say "Disk Setup"):

You will see a list of all your partitions, including those you created in GParted for Kubuntu.
Highlight a partition you want to use (for example, for root / or for /home or for swap).
Hit the Change button.
You will see a menu called Edit Partition.
New size: do not change what you did in GParted, leave it as it is.
"Use as":
Format partition: No, do not check this box -- leave the format as you did it in GParted.
Mount point: Drop-down list: you will see /, /home, etc. If in GParted, you formatted it as swap, you will also see that choice here. Choose one (/, /home, or swap).
Hit the OK button.
Repeat this by highlighting another partition you wish to use for Kubuntu (/, /home, swap).
Bootloader:
When you are done you may also see a choice where to install the bootloader (GRUB2). You can say sdX, where X is the drive you wish GRUB to go on; if you are using UEFI mode, it doesn't matter what you say here: GRUB will go to the ESP, usually sda1, automatically; thus, you can say sda, if you wish. If you are using UEFI, make sure you created an ESP partition (see above).


Finally, click Install Now.
(Or, you can click Back; or Quit if you wish to NOT install Kubuntu at this time.)


Note
Since you did your partitioning ahead of time using GParted (or similar), there are other options you will see that you will NOT use, like these: new partition table, Add, Delete. If you make any mistakes or are not sure about what you did, there is a button called "Undo all changes."

[Qqmike]

Post #121 above:

UEFI for Kubuntu--simplified. And ... some dual-booting tips for Kubuntu

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


I went through it (again) and caught some typos/edits, nothing serious (but a couple things that could be confusing to a beginner). Things like: grub64.efi should be grubx64.efi; a few spellings; some formatting (bold or Undl ON); refind.efi should be refind_x64.efi; code tags corrected; and so on. I caught 16 edits this time around.

As you read this (if you read this stuff--any/all of it), please don't hesitate to point out typos that need to be corrected--whether substantial or trivial. Coming from an academic background, I'm used to being beat up by editors, humiliated by students, edited like h&ll by fellow academics (who LOVE doing it to their colleagues in red ink), and called a "cow turd" by idle, do-nothing philosophers. No problem, baby, bring it on.

There's some useful stuff here. I find I forget some of it if I don't use it for awhile, and that's a bit frustrating. I did test everything I wrote here, usually more than once, on my system (ASUS H97-Plus motherboard firmware, GRUB2-EFI, Kubuntu 14.04 and 15.04, and rEFInd -- all as of August 2015).

[Qqmike]

Table of Contents of my UEFI posts

We have various versions of GRUB floating around:
Grub Legacy, GRUB 2 for BIOS+MBR, GRUB 2 for EFI+GPT

For GRUB2-EFI, I listed the how-to's I've written in the front matter to GRUB 2: A Guide for Users, which is Post #1 of this topic you are now reading:
https://www.kubuntuforums.net/showth...uide-for-Users

These topics, my how-to's, which appear in this thread as posts:

UEFI for Kubuntu--simplified. And ... some dual-booting tips for Kubuntu
https://www.kubuntuforums.net/showth...l=1#post373198

GPT, UEFI -- Study Guide
https://www.kubuntuforums.net/showth...l=1#post346604

A new PC build and Kubuntu-only UEFI installation
https://www.kubuntuforums.net/showth...l=1#post368216

Dual-booting: How to Use Multiple ESPs
https://www.kubuntuforums.net/showth...l=1#post376040

Dual-booting Kubuntu: A summary of your options
https://www.kubuntuforums.net/showth...l=1#post376269

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

rEFInd: Make a live CD to boot into your system
https://www.kubuntuforums.net/showth...l=1#post376838

Fix UEFI+GPT with Testdisk & gdisk -- Deleted partitions & damaged GPT structure
https://www.kubuntuforums.net/showth...417#post372417

Re-install GRUB2 from Live DVD/USB flash drive
https://www.kubuntuforums.net/showth...l=1#post374017

Building a Kubuntu live USB installer using dd
https://www.kubuntuforums.net/showth...aller-using-dd

Installing Kubuntu -- Using the "Manual" Installation Type, with your own partitioning
https://www.kubuntuforums.net/showth...688#post377688

[Qqmike]

Labels on UEFI Boot Entries -- using efibootmgr -L
How to "change" an "ubuntu" label (/EFI/ubuntu)

Quick Summary Version

How to create a label for a UEFI firmware NVRAM variable so you can recognize it in the UEFI firmware boot menus and the BootOrder efibootmgr listing.

Fact:
You can't change or edit an existing UEFI boot entry to add a label or change the current label.
Instead, you must create a new boot variable (pointing at the same EFI subdirectory and the same UEFI bootloader files as the existing boot variable) labeled whatever you wish to use for a label. Then, if you wish, you can delete the old boot variable, or keep it.

The set up is:
You have a UEFI boot variable, say BootXXXX (in the BootOrder), and you'd like to create a new label for it (as seen in the UEFI firmware boot menu(s) and the output of sudo efibootmgr). This boot variable uses the following bootloader file in its ESP (assume the ESP is sdxn): /EFI/<directory_current>/<boot_loader>.
The current label that you see in boot listings is <directory_current>.
Goal: Change the label to NewLabel.

Solution:
As noted above, you can't change the label; instead, create a new boot variable having the label NewLabel and using the same ESP sdxn and same boot files in /EFI/<directory_current>/<boot_loader>.
So, boot (in UEFI mode) into your OS. Then issue this command:

sudo efibootmgr -c -d /dev/sdx -p n -L NewLabel -l  \\EFI\\<directory_current>[B]\\[/B]<boot_loader>

This creates and registers another UEFI firmware NVRAM variable, having label L=NewLabel, pointing at the boot loader l in the EFI subdirectory /EFI/<directory_current>/<boot_loader>, in the ESP at /dev/sdx partition n (so sdxn is the ESP).

If you wish, you can delete the old boot variable (having the old label <directory_current>) using sudo efibootmgr -b XXXX -B.
This deletes only the listing of the variable in UEFI firmware boot menu(s). It does not delete anything in the ESP or in the Linux filesystem. See man efibootmgr.

Example:
For the ESP sda10, NewLabel = K1504-sda12, current label = ubuntu, bootloader = /EFI/ubuntu/grubx64.efi:

sudo efibootmgr -c -d /dev/sda -p 10 -L K1504-sda12 -l \\EFI\\ubuntu\\grubx64.efi

This creates and registers the new boot label K1504-sda12 you will see in the listing from sudo efibootmgr and you should see in your computer's UEFI firmware boot menus. It does not disturb the old label "ubuntu" or the contents of /EFI/ubuntu/grubx64.efi.

Changing the boot order
Every time a new boot entry is created, it is (or probably may be) placed first in the BootOrder listing. You can very easily change the boot order to anything you wish, simply by using efibootmgr command with the -o option. See the examples at the end of the man page man efibootmgr.


Creating a whole new EFI subdirectory and EFI boot label

Inside your mounted ESP, i.e., in /boot/efi, under the subdirectory /boot/efi/EFI, you can created any subdirectory you wish, populated it with valid bootloader files and configuration files, and register and created a UEFI firmware boot label for it using the above method.

As one example of this, let's say your Kubuntu boot files are in /boot/efi/EFI/ubuntu (which will include a GRUB executable grubx64.efi and probably a grub.cfg (and maybe other files). You can work in your file manager as root, create a new subdirectory, say /boot/efi/EFI/myKubuntu1404, copy all the files from /boot/efi/EFI/ubuntu into this new subdirectory, and use the above command to register and create the label myKubuntu1404 for this new UEFI boot variable.


[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[

Details, tutorial version

How to create a label for a UEFI firmware NVRAM variable so you can recognize it in the UEFI firmware boot menus and the BootOrder efibootmgr listing.

We'll go through an example. You can skip through any details you don't care to follow, but I'm including them for people who might be looking for details and subtleties.

The example has one HDD, sda, 12 partitions, sda1-sda12:

[B]sudo gdisk -l /dev/sda [/B]
GPT fdisk (gdisk) version 0.8.10 

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

Found valid GPT with protective MBR; using GPT. 
[B]Disk /dev/sda[/B]: 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 111493101 sectors (53.2 GiB)                     
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   
  7       566274048       567298047   500.0 MiB  EF00   
  8       567298048       669698047   48.8 GiB   8300   
  9       669698048       772098047   48.8 GiB   8300   
 [B]10[/B]       772098048       773122047  500.0 MiB   EF00    <-- [COLOR=#ff3333][B]sda10 ESP[/B][/COLOR]
  11       773122048       824322047   24.4 GiB   8300   
 [B]12[/B]       824322048       865282047  19.5 GiB    8300   <-- Kubuntu 15.04 on sda12

ESPs (EFI System Partitions):
There are three ESPs: sda1, sda7, and sda10, indicated by the Code EF00. Most users will have just one ESP, usually sda1 or sda2. Kubuntu 15.04 on sda12 was set up to use the ESP sda10. (Ignore sda1 and sda7, as they were setup for another experiment.)

--> We will be focusing on Kubuntu 15.04, installed to sda12, and using the ESP sda10.

The list of UEFI firmware NVRAM boot variables is as follows, first the short version, then the long version (-v). Boot entries in UEFI firmware, short version:

[B]sudo efibootmgr[/B] BootCurrent: 0000 
Timeout: 1 seconds 
BootOrder:
[B]0000[/B],0003,0001,0004,000A,0005,0006,0002,000C,000D 
Boot[B]0000[/B]* ubuntu <-- This is my main
Kubuntu 14.04 OS Boot0001* debian 
Boot0002* grub_sda5K1504 
Boot0003* rEFInd Boot Manager 
Boot0004* Mint_2 
Boot0005* Hard Drive  
Boot0006* CD/DVD Drive  
Boot000A* Mint_1 
[B]Boot000C* ubuntu[/B] <-- This is Kubuntu 15.04 (sda12), using sda10 ESP bootloader files
Boot000D* ubuntu <-- This is a Mint OS (on sda11, using sda7 ESP)

Note that Boot0000 is first in BootOrder.

Boot entries in UEFI firmware, long version (-v), showing more details about the booting:

sudo efibootmgr -v 
BootCurrent: 0000 
Timeout: 1 seconds 
BootOrder:
0000,0003,0001,0004,000A,0005,0006,0002,000C,000D 
Boot0000* ubuntu       
HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\UBUNTU\GRUBX64.EFI)
Boot0001* debian       
HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\debian\grubx64.efi)
Boot0002* grub_sda5K1504       
HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File
(\EFI\GRUB_SDA5K1504\SHIMX64.EFI) 
Boot0003* rEFInd Boot Manager  
HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File
(\EFI\REFIND\REFIND_X64.EFI) 
Boot0004* Mint_2       
HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\MINT_2\GRUBX64.EFI)
Boot0005* 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 
Boot0006* 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 
Boot000A* Mint_1       
HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\MINT_1\SHIMX64.EFI)
[B]Boot000C[/B]* [B]ubuntu[/B]       
HD(a,2e054800,fa000,[B]48318e7e-c8b2-4621-9887-4a2dac8ee62d[/B])File(\EFI\UBUNTU\GRUBX64.EFI)..BO
Boot000D* ubuntu     
HD(7,21c0a800,fa000,e0211180-3fb4-4014-8af9-a8112840a308)File(\EFI\UBUNTU\GRUBX64.EFI)..BO

GUIDs
The output of efibootmgr -v lists GUIDs (the format is: "HD(n1,n2,n3,then a GUID, then a File(...)"). So to get the correspondence, let's list all the GUIDs on the HDD:

[B]ls -l /dev/disk/by-partuuid[/B] 
lrwxrwxrwx 1 root root 10 Aug 26 07:43
047177d3-54ce-41e1-9172-fadb450a02e3 -> ../../sda4 
lrwxrwxrwx 1 root root 10 Aug 26 07:43
0b3a3e36-b506-4f4a-9811-8549f1b5d884 -> ../../sda1 
lrwxrwxrwx 1 root root 10 Aug 26 07:43
300dbc2c-e8a7-41e7-8f55-86490efa4347 -> ../../sda2 
lrwxrwxrwx 1 root root 11 Aug 26 07:43
[B]48318e7e-c8b2-4621-9887-4a2dac8ee62d -> ../../sda10 [/B]
lrwxrwxrwx 1 root root 10 Aug 26 07:43
691d4772-f33f-4a3f-a03e-3ba0ea4470cc -> ../../sda5 
lrwxrwxrwx 1 root root 10 Aug 26 07:43
7b90016d-0690-4502-af32-b47ea3274df6 -> ../../sda6 
lrwxrwxrwx 1 root root 11 Aug 26 07:43
86e45577-5fb4-4162-aeb4-1d145456fa81 -> ../../sda11 
lrwxrwxrwx 1 root root 10 Aug 26 07:43
8d5f478c-fcc5-434b-b87f-f4e48ede2631 -> ../../sda9 
lrwxrwxrwx 1 root root 11 Aug 26 07:43
c725fa95-c976-416a-bb63-5f38bca602e1 -> ../../sda12 
lrwxrwxrwx 1 root root 10 Aug 26 07:43
d7a590f0-a1bc-4457-ae26-4b483085917e -> ../../sda8 
lrwxrwxrwx 1 root root 10 Aug 26 07:43
e0211180-3fb4-4014-8af9-a8112840a308 -> ../../sda7 
lrwxrwxrwx 1 root
root 10 Aug 26 07:43 fc532291-73ff-4e96-9d11-8314ec41479b ->
../../sda3

You can see the GUID for the sda10 ESP.
Kubuntu 15.04 (on sda12) stores its bootloader files in the sda10 ESP. (It is NOT obvious why that is true! For our purposes here, you can take my word for it that it was set up this way for an experiment.) In fact, "Boot000C ubuntu" (which corresponds to the Kubuntu 15.04 on sda12) boots from File(\EFI\UBUNTU\GRUBX64.EFI) on the ESP. To see this, refer to the output of efibootmgr -v above. The UEFI bootloader is GRUBX64.EFI, which you may also see written grubx64.efi.

Notice the labels for the Boot variables listed for efibootmgr -v. There are three boot variables that have the same label "ubuntu": Boot0000, Boot000C, and Boot000D. As explained in my UEFI how-to's (see the list at the end), all Ubuntu derivative OSs share the same name, "ubuntu," for their ESP subdirectory /boot/efi/EFI/ubuntu, where their UEFI bootloaders are placed. In the present example, Boot0000 corresponds to my main Kubuntu 14.04 OS, and you'll note that it is first in the BootOrder:
BootOrder: 0000,0003,0001,0004,000A,0005,0006,0002,000B,000C
The Boot000C corresponds to the Kubuntu 15.04 OS installed on sda12, the one we are interested in here.

The Boot000D corresponds to a Mint OS installed on sda11 (Mint is in the Ubuntu "family").

ESP structure: Suppose we UEFI-boot into the Kubuntu 15.04 on sda12. Recall that its ESP (sda10) is mounted (in the Kubuntu filesystem) at /boot/efi. Inside that is top-level subdirectory EFI: /boot/efi/EFI. Inside that is the ubuntu subdirectory: /boot/efi/EFI/ubuntu. The subdirectory ubuntu holds the UEFI bootloader files for the Kubuntu 15.04 OS, and you can list them (in this case, four files):

ls -l /boot/efi/EFI/ubuntu
total 1008
drwxr-xr-x 2 root root   4096 Nov 27  2016 fw
-rwxr-xr-x 1 root root  64352 Nov 27  2016 fwupx64.efi
-rwxr-xr-x 1 root root    126 Aug 29  2017 grub.cfg
-rwxr-xr-x 1 root root 958328 Aug 29  2017 grubx64.efi

Change the UEFI boot label for Kubuntu 15.04 (installed on sda12)

The label for Kubuntu 15.04 (installed on sda12, using ESP sda10) is "ubuntu":

  Boot000C* ubuntu HD(a,2e054800,fa000,48318e7e-c8b2-4621-9887-4a2dac8ee62d)File(\EFI\UBUNTU\GRUBX64.EFI)..BO

Fact: You can't edit or modify the existing boot entry "Boot000C ubuntu". That is, you can't "change" the current "ubuntu" label. Instead, you must CREATE a new boot variable labeledwhatever you wish to use for a label. Then, if you wish, you can delete the old boot variable "Boot000C ubuntu."

Suppose we want to create a boot variable for the Kubuntu 15.04 and label it "K1504-sda12" (without the quotes). The command (which automatically generates the output you see) is:

[B]sudo efibootmgr -c -d /dev/sda -p 10 -L K1504-sda12 -l \\EFI\\ubuntu\\grubx64.efi [/B]
BootCurrent: 0000 
Timeout: 1 seconds 
BootOrder:
[B]0007[/B],0000,0003,0001,0004,000A,0005,0006,0002,000C,000D 
Boot0000* ubuntu 
Boot0001* debian 
Boot0002* grub_sda5K1504 
Boot0003* rEFInd Boot Manager 
Boot0004* Mint_2 
Boot0005* Hard Drive  
Boot0006* CD/DVD Drive  
Boot000A* Mint_1 
Boot000C* ubuntu <-- the old (but still
active) boot variable for Kubuntu 15.04 Boot000D* ubuntu 
[B]Boot0007* K1504-sda12[/B] [COLOR=#ff3333][B]<-- the new boot variable for Kubuntu15.04[/B][/COLOR]
Boot000A* Mint_1[B]
Boot000C[/B]* [B]ubuntu[/B]
Boot000D* ubuntu HD(7,21c0a80

The long version of the BootOrder is:

 sudo efibootmgr -v 
BootCurrent: 0000 
Timeout: 1 seconds 
BootOrder:
[B]0007[/B],0000,0003,0001,0004,000A,0005,0006,0002,000C,000D 
Boot0000* ubuntu HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\UBUNTU\GRUBX64.EFI)
Boot0001* debian HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\debian\grubx64.efi)
Boot0002* grub_sda5K1504 HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\GRUB_SDA5K1504\SHIMX64.EFI)
Boot0003* rEFInd Boot Manager HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\REFIND\REFIND_X64.EFI)
Boot0004* Mint_2 HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\MINT_2\GRUBX64.EFI)
Boot0005* 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 
Boot0006* 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 
[B]Boot0007* K1504-sda12[/B] HD(a,2e054800,fa000,[U]48318e7e-c8b2-4621-9887-4a2dac8ee62d[/U])[B]File(\EFI\ubuntu\grubx64.efi)[/B]
Boot000A* Mint_1 HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\MINT_1\SHIMX64.EFI)
[B]Boot000C[/B]* [B]ubuntu[/B] HD(a,2e054800,fa000,[U]48318e7e-c8b2-4621-9887-4a2dac8ee62d[/U])File(\EFI\UBUNTU\GRUBX64.EFI)..BO
Boot000D* ubuntu HD(7,21c0a800,fa000,e0211180-3fb4-4014-8af9-a8112840a308)File(\EFI\UBUNTU\GRUBX64.EFI)..BO

Let's discuss this.

Kubuntu 15.04 (on sda12) became first in BootOrder:
BootOrder: 0007,0000,0003,0001,0004,000A,0005,0006,0002,000C,000D
(and what used to be first, namely, 0000, became second).

Thus, the computer would automatically boot to the Kubuntu 15.04 OS unless you intervene and select some other Boot entry from the UEFI firmware boot menu.

The old boot entry "Boot000C ubuntu" for Kubuntu 15.04 (on sda12) is still present, and it would also work to get you booted into this Kubuntu 15.04 OS on sda12.

To delete the old boot entry Boot000C (having label "ubuntu") (see man efibootmgr):

sudo efibootmgr -b 000C -B

If you delete it, it will be gone from the listing efibootmgr -v, and you will not see it in the UEFI firmware boot menu of your computer. However, if you look in the ESP for this Kubuntu 15.04 OS, you WILL see the same as before:
/boot/efi/EFI/ubuntu
containing the same four files grub.cfg, grubx64.efi, MokManager.efi, and shimx64.efi.

"000C ubuntu" is deleted ONLY from the firmware boot list; nothing is deleted from your ESP or from your Linux OS filesystem.
--> In fact, the new firmware boot variable (Boot0007 K1504-sda12) will point at the same four bootloader files in the same subdirectory of the same ESP (sda10): /boot/efi/EFI/ubuntu. (The GUIDs and the FILE string in the long version efibootmgr -v are useful for seeing this.)

What does rEFInd see?
rEFInd may not see this newly created, labeled boot entry. But is does see the ESP sda10. (Note: So I could identify this ESP in the boot menus and in rEFInd, I put a label on it: K1504Test using GParted Live CD under Partitions > Label). If you have rEFInd (boot manager) installed, it will also see the kernel vmlinuz residing in the Kubuntu 15.04 OS filesystem.


The command

sudo efibootmgr -c -d /dev/sda -p 10 -L K1504-sda12 -l \\EFI\\ubuntu\\grubx64.efi

Using the man page: man efibootmgr ...

-c create a new boot variable
-d The disk containing the bootloader, the disk containing the ESP. For the example, it is /dev/sda.
-p The partition containing the bootloader. For the example, it is 10 (thus, sda10).
-L Label, UEFI firmware boot manager display label. For the example, I chose K1504-sda12.
-l The loader, the bootloader: you give the path to the bootloader. For the example, the path (and bootloader grubx64.efi) is /EFI/ubuntu/grubx64.efi . This is written in Linux notation. For UEFI, you should write it using backslashes and double them: \\EFI\\ubuntu\\grubx64.efi .

Discussion

The double backslashes \\ slashes are required. The first slash in each sequence is an escape character.
https://en.wikipedia.org/wiki/Escape_character
Let's not worry about this here. See Rod Smith on registering boot NVRAM variables in your UEFI:
http://www.rodsbooks.com/efi-bootloa....html#register
If you search, you will find all sorts of discussions about how to place a label on a UEFI boot variable entry. In my experience, some work, some don't. It may depend on efibootmgr version, or on the firmware, or on your OS, I'm not sure. For example, some references write
-l "\EFI\ubuntu\grubx64.efi". Some references, for the label, write: -L "K1504-sda12" (using double quotes). That didn't work for me. In fact, here's the boot entry it resulted in, see the quotes around the label and the "File" path at the end (which is not even a path):

 Boot0007*
"K1504-sda12"  
HD(a,2e054800,fa000,48318e7e-c8b2-4621-9887-4a2dac8ee62d)File(“EFIubuntugrubx64.efi”)

<-- Ignore. Example of an error.

What's another thing you could do so you can better identify your UEFI boot options?

At least 2 things:

(1) Create separate EFI subdirectories for your (K)Ubuntu (derivative) OSs.
Creative use of the more general grub-install command
sudo grub-install --efi-directory=DIR --bootloader-id=some_name with the added option --no-uefi-secure-boot.
See my how-to, "UEFI for Kubuntu--simplified. And ... some dual-booting tips for Kubuntu"
See SECTION 6: Dual/multi-booting: Know what to expect ... and how to deal with GRUB
https://www.kubuntuforums.net/showthread.php?43221-GRUB-2-A-Guide-for-Users&p=373198&viewfull=1#post373198
(In this method, the use of grub-install results in the registering (in UEFI firmware) of a subdirectory label.)

(2) (If you're curious and want to play with this ... ) Create a new subdirectory under /EFI (in the ESP sda10), populate it with the same four bootloader files being used now (the four files contained in /EFI/ubuntu--grub.cfg, grubx64.efi, MokManager.efi, and shimx64.efi), and see what happens: does that help make the choice of K 15.05 in sda12 more clear in the boot menus? (Answer: Yes, it will.)

Let's look at (2) details for something you must do to make it work -->

We will use Dolphin, as root, to create the subdirectory /EFI/Kubuntu_1504_sda12, and we will copy the four bootloader files from /EFI/ubuntu into /EFI/Kubuntu_1504_sda12.

When that is done (it took less than 1 minute), we see the contents of /EFI are:

ls -l /boot/efi/EFI 
total 8
drwx------2 root root 4096 Aug 26 08:25 [B]Kubuntu_1504_sda12[/B] [COLOR=#ff3333][B]<-- new subdirectory[/B][/COLOR]
drwx------ 2 root root 4096 Jul 11 10:56  [B]ubuntu[/B]

Both subdirectories of the ESP (sda10)--Kubuntu_1504_sda12 and ubuntu--contain the same four bootloader files and point at the Kubuntu15.04 OS on sda12.

Now, we have the BootOrder:

sudo efibootmgr -v BootCurrent: 0000 
Timeout: 1 seconds 
BootOrder:
[B]0007[/B],0000,0003,0001,0004,000A,0005,0006,0002,000C,000D 
Boot0000* ubuntu 
Boot0001* debian 
Boot0002* grub_sda5K1504 
Boot0003* rEFInd Boot Manager 
Boot0004* Mint_2 
Boot0005* Hard Drive  
Boot0006* CD/DVD Drive  
Boot000A* Mint_1 
Boot000C* ubuntu <-- the old (but still active) boot variable for Kubuntu 15.04 Boot000D* ubuntu 
[B]Boot0007* K1504-sda12[/B]

--> ! Nothing changed in the UEFI firmware BootOrder. In fact, we see no evidence of the newly created EFI subdirectory Kubuntu_1504_sda12.

Re-boot to see what happens:

With UEFI firmware menu: nothing new listed on main menu; but Kubuntu_1504_sda12 is listed on a separate Boot Menu accessed by another key.

rEFInd: Lists it this way: /EFI/Kubuntu_1504_sda12 from K1504Test (K1504Test is a label I created in GParted for the ESP on sda10 when sda10 was first set up).

So, we try this plan: We need to register the new boot variable with the UEFI formware

To get /EFI/Kubuntu_1504_sda12 listed by UEFI firmware, you need to register it somehow, say, using efibootmgr. One way is to create a boot variable with a label, where the boot variable uses the same bootloader files in /EFI/Kubuntu_1504_sda12.

To identify the output and listings easily, let's create a boot variable with label "Test_Kubuntu_1504_sda12" (without the quotes) for the newly created (but not yet fully recognized) subdirectory Kubuntu_1504_sda12.

sudo efibootmgr -c -d /dev/sda -p 10 -L Test_Kubuntu_1504_sda12 -l  \\EFI\\Kubuntu_1504_sda12\\grubx64.efi 
BootCurrent: 0003 
Timeout: 1 seconds 
BootOrder:
[B]0008[/B],0007,0000,0003,0001,0004,000A,0005,0006,0002,000D 
Boot0000* ubuntu
Boot0001* debian
Boot0002* grub_sda5K1504
Boot0003* rEFInd Boot Manager
Boot0004* Mint_2
Boot0005* Hard Drive Boot0006* CD/DVD Drive
Boot0007* K1504-sda12
Boot000A* Mint_1
Boot000D* ubuntu
[B]Boot0008* [/B][B]Test_Kubuntu_1504_sda12[/B] [COLOR=#ff3333][B]<-- new boot variable[/B][/COLOR]

You can see its details:

sudo efibootmgr -v 
BootCurrent: 0003 
Timeout: 1 seconds 
BootOrder:
[B]0008,[/B]0007,0000,0003,0001,0004,000A,0005,0006,0002,000D 
Boot0000* ubuntu HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\UBUNTU\GRUBX64.EFI)
Boot0001* debian HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\debian\grubx64.efi)
Boot0002* grub_sda5K1504 HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\GRUB_SDA5K1504\SHIMX64.EFI)
Boot0003* rEFInd Boot Manager HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\REFIND\REFIND_X64.EFI)
Boot0004* Mint_2 HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\MINT_2\GRUBX64.EFI)
Boot0005* 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 
Boot0006* 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 
Boot0007* K1504-sda12 HD(a,2e054800,fa000,48318e7e-c8b2-4621-9887-4a2dac8ee62d)File(\EFI\UBUNTU\GRUBX64.EFI)
[B]Boot0008* Test_Kubuntu_1504_sda12[/B] HD(a,2e054800,fa000,[U]48318e7e-c8b2-4621-9887-4a2dac8ee62d[/U])[B]File(\EFI\Kubuntu_1504_sda12\grubx64.efi)
[/B]Boot000A* Mint_1 HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\MINT_1\SHIMX64.EFI)
Boot000D* ubuntu  HD(7,21c0a800,fa000,e0211180-3fb4-4014-8af9-a8112840a308)File(\EFI\UBUNTU\GRUBX64.EFI)..BO

Looks OK. Note that the newly created boot variable, Boot0008, took first place in BootOrder, bumping the previous #1 boot variable (0007) down the list by one place.

When we re-boot, we see:

UEFI firmware boot menu: OK, the UEFI firmware menus pick up Test_Kubuntu_1504_sda12as first in the BootOrder.

rEFInd: Nothing changed, it is not picking up the new label; but it continues to show /EFI/Kubuntu_1504_sda12, and that's OK. It also shows the kernel vmlinuz file which can be booted.


Changing the boot order

You'll notice that every time a new boot entry is created (by you, by grub, by efibootmgr, whatever), it is placed first in the BootOrder listing (and so will be the default boot option booted by UEFI firmware each time to boot your computer). You can very easily change the boot order to anything you wish, simply by using efibootmgr command with the -o option. See the examples at the end of the man page man efibootmgr.


]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]


Other discussions of labeling UEFI firmware NVRAM boot variables,
and links to my how-to's on UEFI topics for Kubuntu

Rod Smith on registering bootloaders with your UEFI firmware
http://www.rodsbooks.com/efi-bootloa....html#register
(which
uses # efibootmgr -c -d /dev/sda -p 1 -l
\\EFI\\newloader\\loadername.efi -L NewLoader)

Gentoo Wiki
https://wiki.gentoo.org/wiki/Efibootmgr
(which uses this: root #efibootmgr -c -d /dev/sda -p 2 -L "Gentoo" -l "\efi\boot\bootx64.efi")

Arch wiki
https://wiki.archlinux.org/index.php...ace#efibootmgr
(which uses # efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "rEFInd")

More discussion
https://bbs.archlinux.org/viewtopic.php?id=155830


Links to my how-to's for UEFI topics for Kubuntu

UEFI for Kubuntu--simplified. And ... some dual-booting tips for Kubuntu
https://www.kubuntuforums.net/showth...l=1#post373198

GPT, UEFI -- Study Guide
https://www.kubuntuforums.net/showth...l=1#post346604

A new PC build and Kubuntu-only UEFI installation
https://www.kubuntuforums.net/showth...l=1#post368216

Dual-booting: How to Use Multiple ESPs
https://www.kubuntuforums.net/showth...l=1#post376040

Dual-booting Kubuntu: A summary of your options
https://www.kubuntuforums.net/showth...l=1#post376269

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

rEFInd: Make a live CD to boot into your system
https://www.kubuntuforums.net/showth...l=1#post376838

Fix UEFI+GPT with Testdisk & gdisk -- Deleted partitions & damaged GPT structure
https://www.kubuntuforums.net/showth...417#post372417

Re-install GRUB2 from Live DVD/USB flash drive
https://www.kubuntuforums.net/showth...l=1#post374017

Building a Kubuntu live USB installer using dd
https://www.kubuntuforums.net/showth...aller-using-dd

Installing Kubuntu -- Using the "Manual" Installation Type, with your own partitioning
https://www.kubuntuforums.net/showth...688#post377688

[Qqmike]

Remove GRUB from UEFI -- Instead, use rEFInd and/or UEFI firmware boot menus

/////
Added new:
Boot Kubuntu Using UEFI Only (no GRUB, no rEFInd, no boot loader or boot manager, except the UEFI firmware).
https://www.kubuntuforums.net/showth...l=1#post396271
/////

First the Outline. Then the Details.

OUTLINE

If you have not yet installed Kubuntu, see Case 1.
If you have already installed Kubuntu the normal way (installing GRUB with it), see Case 2.
Then after doing either Case 1 or Case 2, read the section "After you remove GRUB".

Getting rid of GRUB: Case 1 and Case 2


Case 1 If you have not yet installed Kubuntu, you have two options, Option (1) and Option (2):

Option (1) Install your Kubuntu OS as usual, letting the installer install GRUB.

If you do this, then do (a), (b), and (c):

(a) Install rEFInd (the easy, best way); or build a live rEFInd.

Reason: After you remove GRUB, you must have a way of booting into your Kubuntu OS. You will use the boot manager rEFInd to do so.

(Note: If, using another OS on your computer, you have already installed rEFInd, then you can rely on that to boot into your newly installed Kubuntu OS.)

(b) Remove GRUB from your Kubuntu system.

(c) Re-boot back into your Kubuntu OS to see how it goes.

To do so, you will use rEFInd that you installed. If instead of installing it, you made a live rEFInd CD, then re-boot your computer using that CD and select from its boot options the option to boot into your Kubuntu OS.


Option (2) Install Kubuntu without installing GRUB (or any bootloader)

In this case, you must have a way to boot into your newly installed Kubuntu OS, so make a live rEFInd CD BEFORE installing Kubuntu.

(Note: If, using another OS on your computer, you have already installed rEFInd, then you can rely on that to boot into your newly installed Kubuntu OS.)


How to install Kubuntu without installing GRUB
Boot your computer with your live DVD/USB Kubuntu installer medium.
Select: Try Kubuntu.
Open Konsole (K > Applications > System > Terminal Konsole).
Type this command, then press enter:

ubiquity --no-bootloader

The Kubuntu installer will open.
Run the installer as you normally would.
It will install Kubuntu without installing GRUB.


Case 2 If you have already installed Kubuntu the normal way, with GRUB, then:

See Case 1, Option (1), and follow steps (a), (b), and (c), where you will remove GRUB from your installed Kubuntu OS.


=> Thus, at this point, you have removed GRUB, or you never installed it to begin with.


After you remove GRUB ... two things to be aware of

-- Try to ensure that GRUB is not installed when you get updates to your OS (which happens when GRUB is updated or when the kernel is updated).

-- Configure your UEFI booting

Three general choices for configuring the UEFI booting:

-- Let rEFInd do the booting using the kernel "stub loader" method; or,
-- Create a custom boot entry in the rEFInd configuration file; or
-- Create a UEFI boot variable for the stub loader method.


]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]


DETAILS (Details closely follow the above outline)


Installing rEFInd when you are booted into an OS (you only need to install it once, from any OS on your computer):

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

rEFInd -- Rod Smith's pages (he is the author of rEFInd)
http://www.rodsbooks.com/refind/getting.html

rEFInd: Make a live CD
https://www.kubuntuforums.net/showth...l=1#post376838


Installing Kubuntu without GRUB
Command:
ubiquity --no-bootloader

Notes

Ubiquity is the default installer for Ubuntu and its derivatives. It is run from the Live CD or USB and can be triggered to run from the options on the device or on the desktop of the Live mode. It was first introduced in Ubuntu 6.06 LTS (Dapper Drake).

https://en.wikipedia.org/wiki/Ubiquity_%28software%29


Remove GRUB from your Kubuntu system

To get an idea of where the string "grub" occurs in your Kubuntu filesystem, try this command:

cd / && sudo find -name *grub*

You may see quite a long listing. Some items are not even relevant, some are trivial, some are data or configuration files, and some are key GRUB boot files.

Important directories are:

-- /usr/lib/grub contains GRUB2-EFI master files (e.g., x86_64.efi[-signed])
-- /boot/efi/EFI/ubuntu contains the main GRUB2-EFI UEFI bootloader files; e.g., grubx64.efi.
-- /boot/grub contains a configuration file, grub.cfg, and other GRUB files and executables (e.g., /boot/grub/x86_64-efi/grub.efi)

ESP structure (EFI System Partition)
Recall that when booted into your Kubuntu OS, the ESP used by that OS is mounted in your Kubuntu filesystem at /boot/efi. The top-level subdirectory of the ESP is EFI: /boot/efi/EFI. Inside that is your ubuntu subdirectory that contains the GRUB bootloader files for your Kubuntu: /boot/efi/EFI/ubuntu containing, as an example, grub.cfg, grubx64.efi , MokManager.efi, shimx64.efi, where grubx64.efi is the main GRUB EFI executable.


What GRUB packages are installed on your system?

Example: Use Muon Package Manager to find out. Open it, and in the search box type "grub" (without the quotes). In one experiment, these were installed:
grub-common, grub-efi-amd64-bin, grub-efi-amd64-signed, grub-efi-amd64, grub2-common
These are key GRUB packages.

Use Muon to purge these files. (Select them, right click, mark for purge, Apply.)
You may find if you purge one (e.g., grub-common), others may also be purged. Get them purged.

After doing so, you may have to manually delete a few key files that didn't remove with the purging:

Delete these (probably doing it as root, say by kdesudo dolphin):
/boot/efi/EFI/ubuntu/grubx64.efi
/boot/efi/EFI/ubuntu/grub.cfg
/boot/grub
/boot/grub/grub.cfg
/boot/grub/x86_64-efi/grub.efi
/boot/grub/grubenv


(For /boot/grub, I deleted the whole /grub subdirectory and contents; and for /boot/efi/EFI/ubuntu, I deleted the entire /ubuntu subdirectory and contents.)
If you then run the command
cd / && sudo find -name *grub*
you may still see quite a listing. Don't worry about it.
However, by now, the following folders under /usr/lib/grub should be gone: x86_64-efi and x86_64-efi-signed, and anything else that looks like GRUB executables under /usr/lib/grub (with .efi extensions).


Re-boot back into your Kubuntu OS using rEFInd

(Using rEFInd that you installed, or your live rEFInd CD.)

To select your Kubuntu from its boot options, look for anything you can identify that is associated with your Kubuntu on the partition you installed it to. rEFInd will list your kernel. For example, "vmlinuz-3.13.0-62"; or "vmlinuz-3.19.0-22-generic-efi.signed from 19 GiB volume." To prepare for this, when you are booted into your Kubuntu (one way or another, perhaps by guessing from rEFInd's menu), identify your kernel using this command: uname -a for the kernel version .

mike@mike-desktop:~$ [B]uname -a[/B]
 Linux mike-desktop [COLOR=#0000ff][B]3.13.0-62-generic[/B][/COLOR] #102-Ubuntu SMP Tue Aug 11 14:29:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

And the command df-hT would give you the size of your partitions and their mount points.


After you remove GRUB ...

-- Try to ensure that GRUB is not installed when you get updates to your OS (which happens , for example, when GRUB is updated or when the kernel is updated).

We will simply add a configuration file to this directory: /etc/apt/preferences.d

----------
Credit and Disclaimer
Credit goes to SteveRiley. Disclaimer is that I didn't really look into this myself, except to see that it is used in discussions of pinning and blacklisting. In the first stanza entry, there is
Package: grub*
Pin: version 0.0
Pin-Priority: -1
I do not know if the wildcard * following grub will work in the file. However, in my example (below), I included plenty of other stanzas to cover everything, and the example worked fine on my system in several experiments. Relevant links to SteveRiley posts:
https://www.kubuntuforums.net/showth...l=1#post342730
https://www.kubuntuforums.net/showth...l=1#post351393
https://www.kubuntuforums.net/showth...-and-dual-boot
----------
Comment
After removing GRUB from your Kubuntu system, you don't want it coming back. But, fact is, worst case, if somehow it does reappear, it's no big deal to simply remove it again (use Muon, mark and purge all GRUB-related packages under the search term "grub"; then manually delete a few files as we did above).
----------

Bottom-line, the solution is to make this text file (as root, perhaps by kdesudo dolphin):
/etc/apt/preferences.d/no-boot-loaders
with this content (or, for that matter, whatever content you think is right -- I used Muon to see what packages were related to "grub" and found several):

 
Package: grub* 
Pin: version 0.0
Pin-Priority: -1

Package: grub-efi-amd64-bin
Pin: version 0.0
Pin-Priority: -1

Package: grub-common
Pin: version 0.0
Pin-Priority: -1

Package: grub-efi-amd64-signed
Pin: version 0.0
Pin-Priority: -1

Package: grub-pc
Pin: version 0.0
Pin-Priority: -1

Package: grub-pc-bin
Pin: version 0.0
Pin-Priority: -1

Package: grub-efi-amd64
Pin: version 0.0
Pin-Priority: -1

Package: grub2-common
Pin: version 0.0
Pin-Priority: -1

Package: grub2
Pin: version 0.0
Pin-Priority: -1

Package: lilo
Pin: version 0.0
Pin-Priority: -1 

Package: os-prober
Pin: version 0.0
Pin-Priority: -1

Testing this, comment
After taking major system updates (200 MB), including kernel, in a new installation of Kubuntu, after all is said and done, it looks like only some grub legacy files are around, but I don't see any main (U)EFI GRUB2 executables. (Strangely, I could only find some GRUB legacy files installed! Like these: /usr/lib/grub-legacy, /usr/lib/grub/i386-pc. GRUB Legacy files will not affect your UEFI system.) No EFI GRUB bootloader was installed. Upon re-booting, nothing changed--I still had to use rEFInd to get booted into Kubuntu; no GRUB boot menus seen.

The KEY directories you do not want to see populated by GRUB UEFI executables (".efi" files, as discussed above somewhere) are:
/boot/efi/EFU/ubuntu
and
/usr/lib/grub
and
/boot/grub


Configure your UEFI booting

Three general choices for configuring the UEFI booting:

-- Let rEFInd do the booting using the kernel "stub loader" method.

In other words, do nothing, leave it as it is, as we've used in the above examples where rEFInd booted the kernel files vmlinuz using the stub loader method.

or,

-- Create a custom boot entry in the rEFInd configuration file called refind.conf.

This is discussed in the # comments at the end of the rEFInd configuration file (with examples) that comes with rEFInd when you install it. Find it here in your Kubuntu filesystem: /boot/efi/EFI/refind/refind.conf.

or,

-- Create a UEFI boot variable for the kernel stub- loader method.

Using the kernel's EFI stub loader.

In late 2011, Linux kernel developers began work on a new way to boot Linux on EFI-based systems. This approach turns the Linux kernel [3.3.0 and later] into an EFI application. Once loaded, the kernel takes over the computer, effectively bypassing the need for a boot loader in the strictest sense.

Rod Smith, the author of rEFInd, tells how to make a UEFI firmware boot entry:
http://www.rodsbooks.com/efi-bootloaders/efistub.html

Steve Riley shows how to make an UEFI firmware boot entry, for stub-loading:
Going GRUB-less with UEFI
https://www.kubuntuforums.net/showth...l=1#post309652
Kano's instructions:
http://www.phoronix.com/forums/forum...791#post377791


Clarifying comment

Notice that when we use rEFInd to get booted into the Kubuntu OS (without using GRUB), rEFInd does this by direct use of the kernel stub-loader method. There is no boot variable (NVRAM variable) set up in your UEFI firmware. The method "Create a UEFI boot variable for the stub loader method)" does create an UEFI firmware boot variable.

When you have a (UEFI NVRAM) boot variable (that is actually "registered" with your computer's EFUI firmware), you can see it and manipulate it by (1) entering your firmware setup upon re-booting, at POST, by pressing your magic key to do so; or by (2) using the Linux command efibootmgr (see man efibootmgr); or by (3) (for advanced users) using the EFI Shell.

When we use rEFInd to boot into an OS, rEFInd itself is a UEFI NVRAM boot variable, registered with the firmware. When you install rEFInd, it sets itself up in the computer's firmware as a boot variable, and, in fact, puts itself as first in the boot order (BootOrder--run sudo efibootmgr to see this). Using efibootmgr (with the -o option) you can change the boot order of the UEFI firmware boot variables.

You can see your UEFI NVRAM boot variables (and EFI executables, .efi's) by issuing this command:
sudo efibootmgr (short version), or sudo efibootmgr -v (long version).

Personal, aside ... I have not removed GRUB from my computer, I use it alongside rEFInd for tests and such. I often use rEFInd for booting by the stub-loader method. I have not tried creating a new UEFI boot variable for the kernel stub-loading boot option; but if you want to, you can consult the references by Rod Smith and SteveRiley.


]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]


See a list of my UEFI how-to's at the front of this:

GRUB 2 A Guide for Users

https://www.kubuntuforums.net/showth...uide-for-Users

[Qqmike]

Building a Kubuntu live USB flash drive installer using dd

Assume you have downloaded the Kubuntu iso file (and checked it out with either md5sum or SHA sum). To write this to a flash drive so it becomes a "live Kubuntu" USB installer medium:

Command

sudo dd if=/path/to/iso of=/dev/sdX bs=16M

/dev/sdX is the device notation for your USB flash drive as seen from your operating system.
/path/to/iso is the path to where you have downloaded your Kubuntu iso file.
bs is block size; you may also try using bs=4M or bs=8M.

Caution
You must specify the sdX VERY carefully or you could damage or destroy the data on one of your drives. /dev/sdX should be the correct device notation for the flash drive you are using to build your Live Kubuntu USB flash drive.
--> See the reference (below): The dd Command.


Example
(showing the output result; the flash drive is seen as /dev/sdb)

sudo dd if=/home/mike/Downloads/kubuntu-14.04.2-desktop-amd64.iso of=/dev/sdb bs=16M
65+1 records in
65+1 records out
1093238784 bytes (1.1 GB) copied, 149.653 s, 7.3 MB/s

How to find where your flash drive is, the /dev/sdX

Try the command: lsblk.
Or, you can use GParted (Partition Editor) to see what it sees;
Or, try sudo fdisk -l;
Or, try sudo gdisk -l /dev/sda, or sudo gdisk -l /dev/sdb, then gdisk -l /dev/sdc, etc. to identify the flash drive device.


Notes

(1) This works no matter what was previously on the flash drive (nothing, an MBR, or a GPT).

(2) This works with K(U)buntu images starting with K(U)buntu 11.10 "Oneiric" (about October 2011).
See this for the history and why's:

--> Ubuntu switched to Hybrid Disc Images: What this means for the End User
http://www.tuxgarage.com/2011/06/ubu...sc-images.html

ISO Image
https://en.wikipedia.org/wiki/ISO_image
Hybrid ISO
https://plus.google.com/105696767572...ts/X51mGnyiZq9

(3) This will not create a persistent flash drive.
For that, try to use standard tools, such as UNetbootin and Startup Disk Creator.
http://www.tuxgarage.com/2011/06/cre...usb-drive.html

(4) The (partition) structure of the live flash drive
See the discussion
https://www.kubuntuforums.net/showth...l=1#post370705

(5) An additional tool called dcfldd is based on dd but displays a progress meter, showing percent done.
It uses the same arguments as dd (and more).
See man dcfldd.
https://en.wikipedia.org/wiki/Dd_%28Unix%29#Dcfldd
https://plus.google.com/105696767572...ts/KQYVTrjcDwG
https://en.wikipedia.org/wiki/Dd_%28Unix%29#Dcfldd

(6) The dd Command
https://www.kubuntuforums.net/showth...The-dd-Command

[Qqmike]

rEFInd: Make a live USB flash drive to boot into your system

rEFInd: Make a live USB flash drive to boot into your system

If you move into the newer UEFI booting with the GPT partition model (and have a newer computer equipped to do so, say > 2011-2012), and especially if you are dual/multi-booting, keeping a rEFInd USB flash drive handy might be a smart thing to do. It's easy and quick. If you are unable to boot normally into your OS, you can use the rEFInd USB flash drive to do so. Once you are there, you can then try to fix whatever problem you are having.

If you prefer a rEFInd CD, see this:
https://www.kubuntuforums.net/showth...l=1#post376838


For rescue or emergencies:
You can make a rEFInd USB flash drive in a live Kubuntu session, using your Kubuntu live USB flash drive installer or your Kubuntu live DVD installer. You need to have the right number of correct ports to work with, either CD/DVD drive(s) or USB ports.
--> See the tips at the end (below) for how to do this.


rEFInd is a boot manager for UEFI booting that should be able to boot all your bootable media, files, OSs, and it is discussed elsewhere:
UEFI for Kubuntu--simplified
https://www.kubuntuforums.net/showth...l=1#post373198


Where to get it and how to do it

Get the USB flash drive image file from here (click link):
http://www.rodsbooks.com/refind/getting.html

Download the file:
For example, refind-flashdrive-0.9.0.zip -- downloaded to my Downloads folder: /home/mike/Downloads.
Create a directory (a folder) for this work: refind_USB; so now you have /home/mike/Downloads/refind_USB.
Move the .zip file into the folder you just created.
Unzip the file:
right-click on refind-flashdrive-0.9.0.zip, Extract > Extract archive here;
inside that folder you will now find the folder: refind-flashdrive-0.9.0;
inside that folder, you will find the img file we need: refind-flashdrive-0.9.0.img (which is like an iso file).

Now you need to make a USB flashdrive from that img file.
I chose to do this using the dd command.
For example:

 sudo dd if=/home/mike/Downloads/refind_USB/refind-flashdrive-0.9.0/refind-flashdrive-0.9.0.img of=/dev/sdb

For the principles of using dd to make live media, see
https://www.kubuntuforums.net/showth...712#post378712


The important point is that you must get the "of=/dev/sdx" right.
That's the device notation for your flash drive as it's plugged into your system, in Kubuntu.
As you can see, mine was /dev/sdb; yours could be anything. Do NOT make a mistake here.


How to find where your flash drive is, the /dev/sdX

Try the command: lsblk.
Or, you can use GParted (Partition Editor) to see how it sees your drives, sda, sdb, sdc, etc.
Or, try sudo fdisk -l;
Or, try sudo gdisk -l /dev/sda, or sudo gdisk -l /dev/sdb, then sudo gdisk -l /dev/sdc, etc. to identify the flash drive device you wish to use.


Test it by booting your computer with the rEFInd USB flash drive
Re-boot your computer with the rEFInd USB flash drive.
At the POST, enter your UEFI setup (by pressing the correct key for your computer).
Select from the boot or boot override menu the rEFInd USB in UEFI mode.
Example: mine showed up as
UEFI(FAT)Kingston3.0DT(16GB)
(select it, press Enter to boot--Note the UEFI descriptor)

The rEFInd screen
Use arrow keys to navigate to an icon. A description of the (boot) option represented by that icon appears below the two rows of icons; eg., Boot EFI\ubuntu\grubx64.efi from ESP_sda1
(back slashes are used in UEFI; forward slashes are used in your Linux: they mean the same thing)

In my example, I see 27 boot options! (I have 12 partitions and all sorts of OSs, ESPs, and .efi's.)

You will also see an EFI Shell (the terminal icon) and other options: shutdown; restart; re-boot to computer Setup utility (= your firmware setup).

The EFI shell is for advanced users. Most users will instead use the simpler efibootmgr command (from their OSs or from a live OS DVD/USB) to work with their UEFI setup (see man efibootmgr). So be careful here, but I'll mention it anyway:

Start EFI shell (by clicking on the terminal icon). To see just one page of output at a time on your screen, use the -b option in commands.
To see the help menu listing of commands:
Shell> help -b
To list the NVRAM boot variables, one page at a time:
Shell> bcfg boot dump -v -b
To Exit the EFI shell and return to your rEFInd menu:
Shell> exit

Important UEFI Shell Commands
https://wiki.archlinux.org/index.php...ace#UEFI_Shell

EFI Shells and Scripting
https://software.intel.com/en-us/art...and-scripting/


/////////////////////////////////////////

In a live Kubuntu session ...

Tips for doing this work in a live Kubuntu session, booting your computer with your live Kubuntu USB flash drive installer or with a live Kubuntu CD installer.


Boot your computer with your live Kubuntu medium (DVD or USB) plugged in.
At the POST screen, press the magic key for your computer to enter your UEFI firmware ("BIOS") setup menus and find the boot menu(s).
Select your live Kubuntu medium (DVD or USB) from the boot menu, making sure it says UEFI in its description.
Your computer will boot to a Kubuntu live session.
Select Start Kubuntu.
Select Try Kubuntu.
Open Firefox (K > Firefox, or K > Applications > Internet > Firefox).

Now proceed exactly as above: Where to get it and how to do it, but note that in your live session, the home folder you will use might be called something like /home/kubuntu, then /home/kubuntu/Downloads. To navigate to it, you might have to open Dolphin, click the red Root place on the left side bar, click home, then kubuntu, then Downloads, and you are there.

Before running the dd command, you will plug your empty flash drive into an empty USB port.
Then run the dd command.

--> After dd finishes, you can safely remove and unplug that flash drive -- but don't unplug your live Kubuntu USB if you are booting into your live session that way!
Then you can exit out of all your programs in the live session.
And re-boot: K > Leave > Restart
and you will be prompted to remove your live Kubuntu medium (DVD or USB) and press Enter when ready.

Or,

--> After dd finishes, you can leave that flash drive plugged in if you wish to test it now.
Then you can exit out of all your programs in the live session.
And re-boot: K > Leave > Restart
and you will be prompted to remove your live Kubuntu medium (DVD or USB) and press Enter when ready -- but don't unplug your rEFInd USB.

[Qqmike]

Using Your Live Kubuntu DVD/USB to Fix Things


Part 1:
How can you use your live Kubuntu DVD or USB flash drive to fix things? Here are some tasks you can perform.

Part 2:
"Comments, Tips, some Details" are given next, including some links.

Part 3:
If you need some basics of using Kubuntu, see the section at the end called "Basic Tasks in Kubuntu."

Note:
Try to use a LiveCD of the same release (Kubuntu 14.04, Kubuntu 15.04, etc.) as the OS you are trying to fix.


PART 1: Using the Kubuntu live DVD/USB to fix things in your installed Kubuntu OS


Getting help from the Kubuntu forum, other forums, or from Internet searches
Use Firefox (or your favorite browser).
If you can get an Internet connection in your live Kubuntu session (most people can), then you have access to all sorts of help: simply open the Firefox web browser and go. Or, in your live session, using Muon, install a web browser you prefer.

Rescuing your data off a partition when you can't boot into that partition.

Mount and copy
You can boot your computer into a live Kubuntu session, mount the partition you need to take a look at, and simply copy files either into your live session (say, into the live session's /home/kubuntu/Documents directory)--but before you quit the live session, you must copy those files onto a flash drive or another drive; or copy files directly onto a flash drive (that you insert during the live session); or copy files from the "broken" partition directly into a directory on a known-good partition (that you also mounted in the live session or that you were able to access using Dolphin).
See below: Comments, Tips, some Details on "Mount and copy"

PhotoRec (or other specialized data recovery tools)
You can run the PhotoRec program in a live Kubuntu session. Use it to try to recover lost files. After recovery, you will have to copy the recovered files to a safe, permanent location (e.g., a flash drive, an external drive, or to a good partition).

Fixing your partition table, restoring lost partitions
TestDisk
gdisk
You can run the TestDisk program or gdisk in a live Kubuntu session.


Partitioning; partition editing
GParted
KDE Partition Manager
The KDE Partition Manager can be run from your live Kubuntu session. Also, you can install the popular partition editor gparted in a live session and run it.


Edit Kubuntu system files
In your live Kubuntu session, you can edit your installed Kubuntu system files--with root privileges--and save the result in your installed Kubuntu OS file system.


Fix booting problems when you can't boot into your OS
Fixing the GRUB bootloader. Using Boot Repair. Getting rEFInd. Using chroot.

When you have a problem booting into an OS, you might be able to easily fix the problem if you could get booted into that OS. Thus, the goal is to either fix the problem from outside the OS (from your live Kubuntu session) or use your live Kubuntu session to help you get booted into the broken OS (where then you can fix the problem). So, thinking this through now ...

You can fix GRUB from your live Kubuntu session.

This may involve re-installing GRUB (to the broken OS), and/or fixing a configuration file, and/or regenerating a new GRUB boot configuration file (/boot/grub/grub.cfg).
Do you have an Internet connection in your live session?
Getting Boot Repair and rEFInd requires an Internet connection in your live Kubuntu session. Using chroot to fix GRUB manually does not require an Internet connection. (Of course, if you already have Boot Repair and rEFInd CD/USBs, then no Internet connection is required.)

Boot Repair: re-install GRUB
The easy way would be to use Boot Repair, which will re-install GRUB for you (and do other things, if you like). You can install Boot Repair in your live Kubuntu session and run it from there.

rEFInd: it will boot you into your OS
For newer systems (say after 2011) using UEFI booting, with GPT partition scheme, rEFInd is a boot manager that can get you booted into your OS, even if your GRUB bootloader is not working. The problem is, you must install it from your OS. Or, use a rEFInd CD or USB flash drive. Fortunately, you can make a rEFInd CD or USB flash drive in your live Kubuntu session, then re-boot using it, and from the rEFInd boot menu you will select what you wish to boot. After booting into your installed (broken) Kubuntu OS, you can repair GRUB yourself with two commands:
sudo grub-install
sudo update-grub
And/or, after using rEFInd to boot into your installed Kubuntu OS, you can then install rEFInd to your computer from within Kubuntu. (rEFInd and GRUB will not interfere with each other, they can work alongside each other.)

Fix things manually using chroot
From your live Kubuntu session, you can use the powerful command chroot to work on your installed (broken) Kubuntu OS; in particular, you can re-install GRUB and generate a new GRUB boot file (/boot/grub/grub.cfg). This option is for people who feel comfortable working at the command line as root, and working on their system; there are plenty of step-by-step how-to's on it. It is simple, but you do need to pay attention as you work. Using chroot, you can run the two commands for fixing GRUB: sudo grub-install and sudo update-grub.


Replace your Kubuntu!

Simply click the Install option and go!


//////////////////////////////////////////////////////
//////////////////////////////////////////////////////


PART 2: Comments, Tips, some Details


The tips given here follow the sequence of topics in Part 1.


"Mount and copy"

In your live session, open the file manager Dolphin, note the Places side bar on the left, look through the Devices category, and if you identify the partition you are interested in, left-click it and that partition will be mounted and open. (To unmount a listed device, right-click it, select unmount.)

If you don't see the partition listed in Dolphin, then mount it manually:
Suppose the partition is sdxn (e.g., like sda3). Open Konsole. Create a directory: sudo mkdir /mnt/sdxn. Mount the partition at that directory: sudo mount /dev/sdxn /mnt/sdxn. Now, open Dolphin, navigate to the directory /mnt, you'll see sdxn, then left-click on it to open it. When done, exit out (File > Quit/Exit or click the Close X at top right of open windows), then unmount the partition with sudo umount /mnt/sdxn (note the unmount command is spelled umount).

(Working at Konsole instead: On the other hand, after mounting /dev/sdxn at /mnt/sdxn, to use the command line instead of Dolphin, at Konsole change directory into it and you can list the contents and begin your work at Konsole: cd /mnt/sdxn, then list the files in sdxn using ls or ls -a, or ls -al.)

Dolphin should detect and list your Windows partitions, too. If not,
Mounting Windows Partitions
https://help.ubuntu.com/community/Mo...dowsPartitions


Copying files off your broken partition
After mounting and opening the broken partition, you can copy and paste as you normally do (with right-clicking or using Dolphin). You might copy them to a folder you make under Documents: /home/kubuntu/Documents, in your live session. Then, when done, copy that folder to a flash drive or external drive (that you plug in during the live session) or copy it to another partition you've accessed via Dolphin.


PhotoRec
PhotoRec is included with TestDisk, which is found here:
http://www.cgsecurity.org/wiki/TestDisk
(see left side bar for PhotoRec link)


Although it's been awhile you should find helpful tips about PhotoRec and TestDisk in this:
Rescue Partitions and Data
https://www.kubuntuforums.net/showth...tions-amp-Data

For tips on setting up and managing your work with TestDisk/PhotoRec, continue reading on TestDisk ...

TestDisk: A tip on setting it up

The website: http://www.cgsecurity.org/wiki/TestDisk
Step-by-Step: http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

You can use TestDisk three ways: From another Kubuntu partition or disk; from a rescue CD/DVD; or from a live Kubuntu DVD. See TestDisk website for a list of live CDs that include TestDisk (GParted Live CD is among them).

Although you can install TestDisk in your live Kubuntu session using Muon Package Manager, keep reading for another idea.

Tip: Download TestDisk/PhotoRec to a personal directory and keep everything together

> 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/testdisk-7.0 to find the TestDisk executable (program), testdisk_static. That's the program you'll run.

At Konsole, change directory (cd) 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


Fixing your partition table, restoring lost partitions: TestDisk and gdisk

Discussion, examples:
Fix UEFI+GPT with Testdisk & gdisk -- Deleted partitions & damaged GPT structure
https://www.kubuntuforums.net/showth...l=1#post372417

Install gdisk (GPT fdisk) in your live session using Muon or at Konsole: sudo apt-get install gdisk.
GPT Fdisk Tutorial
http://www.rodsbooks.com/gdisk/


Partitioning; partition editing
GParted
KDE Partition Manager

You can install gparted in your live session using Muon Package Manager. Both GParted and KDE Partition Manager can be found at K > Applications > System > Partition Editor.
GParted Live Manual:
http://gparted.org/display-doc.php?n...ed-live-manual


Edit Kubuntu system files

In your live Kubuntu session, you can edit your installed Kubuntu system files--with root privileges--and save the result in your installed Kubuntu OS filesystem.

First, if it is not already mounted or listed in Dolphin, mount the partition containing the file you need to edit. (See "Mount and copy" above; when done editing, unmount the partition using sudo umount.)

Then you have a couple choices:

Open Dolphin as root and go to work: kdesudo dolphin.
Or, open the file directly in the text editor Kate:
kdesudo kate /mnt/sdxn/path-to-the-file
(where the target partition is sdxn and is mounted at /mnt/sdxn).
--> When done, File > Save and File > Quit.
--> If you make a mistake or are not sure or want to get out, File > Quit without saving.
(Note: kdesudo allows you to edit the system file with root privileges, to work "as root".)


Fix booting problems when you can't boot into your OS
Fixing GRUB bootloader. Using Boot Repair. Getting rEFInd. Using chroot.


Boot Repair
In theory, you should be able to use the live Kubuntu session to make a Boot Repair CD/USB, re-boot with it, and fix GRUB. In my brief experiment, I ran into difficulties (e.g., dd did not work to make the live Boot Repair USB; Unetbootin made the USB but then failed to boot me into Boot Repair).

So here's what I suggest. Use the guidance from Ubuntu (which works also for Kubuntu) here:
https://help.ubuntu.com/community/Boot-Repair

To install Boot Repair in your live session, open Konsole and type these commands:

 sudo add-apt-repository ppa:yannubuntu/boot-repair
  sudo apt-get update
  sudo apt-get install -y boot-repair && boot-repair

It will open after the last command. If you are not ready, close it. To open Boot Repair again, two ways:
Open Konsole and type boot-repair (or sudo boot-repair).
Or,
K > Applications > System > Repair the boot of the computer (Boot Repair)
Most people can simply use the Recommended Repair.
Others will want to study the settings and options; pay attention to these:
advanced options --> re-install GRUB; use the standard EFI file? (check the drop-down list if you have more than one ESP--separate GRUB locations); GRUB options--turn off Secure Boot? (might be a good idea); purge GRUB before re-installing? edit GRUB config file /etc/default/grub?


rEFInd -- making a live CD or USB in your live session
See the first link for CDs and the second link for USBs:
https://www.kubuntuforums.net/showth...l=1#post376838
https://www.kubuntuforums.net/showth...l=1#post379352


Using chroot to fix GRUB. This does not require an Internet connection.
See this for step-by-step:
https://www.kubuntuforums.net/showth...l=1#post374017


//////////////////////////////////////////////////////
//////////////////////////////////////////////////////


Part 3: Basic Tasks in Kubuntu


Your live Kubuntu session works about the same as an installed Kubuntu in terms of accessing your applications and files. Jut a few tips for new users.

Start a live session:
Boot your computer using the Kubuntu live DVD/USB. If UEFI booting, at POST enter firmware/"BIOS" setup and select the UEFI mode of the DVD/USB to boot. Then you'll see and click Start Kubuntu. Then Try Kubuntu -- you then have a live session.

Note that the "K" on the Desktop is the K button at lower left, similar to the Start Menu button in Windows.

Note this!
Everything in the live session is gone after you exit the live session! During the live session, everything occurs in RAM only, not on your hard drives (unless you make changes to your hard drives).

Your home will be called something like /home/kubuntu in a live session.


Dolphin is your file manager, used to navigate your personal and system directories. To access system directories, click the red Root under Places (on the left). To open Dolphin as root, type, at Konsole, kdesudo dolphin. Find Dolphin here: K > Applications > System > File Manager (Dolphin)

Konsole is a terminal where you can enter commands. K > Applications > System > Terminal (Konsole).

Muon
Use Muon to install programs like gparted. You'll see Muon Discover here:
K > Applications > System > Software Center (Muon Discover).
To install a program, type its name in the search window, or explore the categories on the left.
To install Muon Package Manager (which is more complete), type Muon Package Manager in the search window of Muon Discover and click Install. Then:
K > Applications > System > Package Manager (Muon Package Manager)

Burning a CD/DVD iso: k3b
K > Applications > System > Disk Burning (k3b)

Explore, find the device notation (/dev/sdxn) of your drives and flash drives: commands
sudo fdisk -l
sudo gdisk /dev/sda (or /dev/sdb, etc.)
lsblk
UEFI booting information: sudo efibootmgr (or more details: sudo efibootmgr -v)


References Getting started with a live DVD/USB; using commands at Konsole

Booting from USB stick
https://help.ubuntu.com/community/In...n/FromUSBStick

BurningIsoHowTo (making a live DVD, scroll down for Kubuntu)
https://help.ubuntu.com/community/BurningIsoHowto

How to burn a DVD on Windows
http://www.ubuntu.com/download/deskt...dvd-on-windows

Installation/CDIntegrityCheck (using md5sum and shasums)
https://help.ubuntu.com/community/In...IntegrityCheck

Commands at Konsole
https://www.kubuntuforums.net/showth...sole-Beginners

[dequire]

Qqmike - That post is really insightful. I think we've all been in one of these "tight" spots or another. I've bookmarked your post for future reference should I need it. Well done. I'd also add that a few other things I've done from a live Kubuntu session:

• Install ClamAV and ClamTK (graphical front-end to ClamAV) to virus-scan other drives and partitions
• Easy bulk copy / paste across different drives
• If your system is borked and you can't boot, you can backup important files (as you've outlined above), download a fresh new kubuntu.iso image right from within the live session, and either use K3b to burn said image to DVD, or install Unetbootin to install the image to a USB stick

Note that, at the time of this writing, usb-creator-kde seems broken, hence using the need to install unetbootin in the live session to make the USB. Also note that you need to use KDE Partition Manager first on your USB stick, as unetbootin does not automatically format the stick.

Liva the power of GNU / Linux!

[Qqmike]

Thanks, dequire. I incorporated your 3rd suggestion in Part 1, thanks.

usb-creator-kde seems broken, hence using the need to install unetbootin in the live session to make the USB. Also note that you need to use KDE Partition Manager first on your USB stick, as unetbootin does not automatically format the stick.

Personally, I'm now skeptical of UNetbootin after seeing so many posts complaining about it and reading the cautions @ Ubuntu how-to's, and hearing from some of our members. OTOH, dd is not for people who aren't comfortable with the CLI. KDE Partition Manager, yes, or install gparted in the live session. In general, I'm extremely skeptical of any installer or utility (like UNetbootin) formatting anything. Since the Kubuntu iso is a hybrid iso, dd will work to build the flash drive without any partitioning--it will work no matter the state of the flash drive, partitioned/formatted or not.

[Qqmike]

UEFI Simplified, a quicker version


This is intended to be a quicker version (more to-the-point) of the more tutorial "UEFI for Kubuntu--simplified. And ... some dual-booting tips for Kubuntu."
https://www.kubuntuforums.net/showth...l=1#post373198

For full UEFI/GPT references, see the above link to "UEFI for Kubuntu--simplified" and see the Study Guide:
https://www.kubuntuforums.net/showth...l=1#post346604


KEY references:
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/
Rod Smith web pages: Managing EFI Boot Loaders for Linux
http://www.rodsbooks.com/efi-bootloaders/index.html
gdisk tutorial: http://www.rodsbooks.com/gdisk/
rEFInd: http://www.rodsbooks.com/efi-bootloaders/refind.html
Wikipedia articles on special topics (UEFI, GPT, etc.).

--> The Cheat Sheet is redesigned and a copy placed at the end here.


[[[[[[[[[[]]]]]]]]]][[[[[[[[[[]]]]]]]]]]


List of topics, in sequential order

UEFI+MBR replaces BIOS+MBR
Installing the OS in UEFI mode, doing your own partitioning, include ESP
How will you know you are booting in UEFI mode?
How UEFI booting works
ESP -- EFI System Partition
GPT -- GUID Partition Table
Two important commands: sudo gdisk and sudo efibootmgr
GRUB2-EFI, grub-install
rEFInd boot manager: recommended
Dual-booting with Kubuntu and GRUB2-EFI
Dual-booting: Summary of 5 options
Separate EFI directories for your OSs
Using more than one ESP
Changing labels on UEFI Boot entries: sudo efibootmgr -L
Fixing things: GRUB, booting issues, GPT, files

Cheat Sheet


\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////

UEFI+GPT is replacing BIOS+MBR
The old way of booting your computer is with BIOS and an MBR (Master Boot Record). The new way is with UEFI and GPT. UEFI is Unified Extensible Firmware Interface, a software interface between an operating system and platform firmware. GPT is GUID Partition Table. There are mixed or hybrid systems, where, for example, you use UEFI firmware to boot MBR in Legacy mode; or use UEFI to boot with GPT but do so in BIOS mode; or use BIOS to boot with GPT. In general, these mixed systems are not recommended. Windows requires a straight system: either BIOS+MBR or UEFI+GPT. If you need a mixed system, make a note to learn about CSM (Compatibility Support Module), the BIOS boot partition (bios_grub or EF02; no filesystem: raw binary code for GRUB core.img), the Protective MBR, and start by consulting the advanced material at Rod Smith's site (rodsbooks.com).

--> Simple, conceptually: You install OSs as usual: root /, /home, /swap. In addition, there is a UFI System Partition (ESP) where ALL the boot-loaders go for all your OSs. When you boot the computer, its firmware checks the ESP to see what to boot and how.

Installing the OS in UEFI mode

Use 64-bit Kubuntu
Configure your UEFI computer's firmware
Use GParted to do the partitioning and include an ESP (EFI System Partition)
Boot the Kubuntu installer in UEFI mode and install Kubuntu

--> (1) Must use the 64-bit Kubuntu; and (2) You must boot the Kubuntu DVD/USB installer in UEFI mode.

> Access your computer's UEFI firmware setup Learn the key to press during POST to open the computer's firmware setup, including its boot menu(s). (Example: ASUS may be F2) The UEFI firmware acts as a boot manager.

Configure your UEFI firmware This is up to you and depends on what you want or need. Do this before installing Kubuntu.
(Recent personal example, for easy UEFI booting: CSM (compatibility support module): set to Auto (default)--or just turn it OFF; Disable Secure Boot: Change to “Other O/S”, which disables Secure Boot for the ASUS UEFI; and Disable Fast Boot.)

Partition the HDD with GParted: GPT and include an ESP (EFI System Partition)
GParted version you'll need: "amd64 64-bit version runs on x86-64 based computers, with ability to access more than 4 gigabytes of memory, and supports use of multiple processor cores. For newer (>2010) computers with UEFI instead of legacy BIOS try this one."

Prior to installing Kubuntu, partition the drive using GParted Live CD/USB. Do this as you normally do, note two things: (1) Make a new partition table, type GPT (Device > Create Partition Table: gpt); and (2) Make a special partition for the ESP (EFI System Partition: it will contain boot loaders for the computer). It may be anywhere, but keep it simple/standard and, if possible, use the first partition sda1; 100-512 MB (recommended at least 200 MB); FAT 32; in GParted set the boot flag on it (this marks it as the ESP or type EF00); and optionally you may set a label to recognize it (Partition > Label).

Boot the Kubuntu installer in UEFI mode: With the DVD/USB installer, reboot the PC, enter the computer's UEFI setup by pressing the correct key for your computer. Find the boot menu (or boot override menu) where the bootable devices are listed. Choose the one that corresponds to the Kubuntu UEFI DVD or USB (it may also show up as a "normal" DVD/USB choice). Look for UEFI /(FAT) or a reference to UEFI. (Example: a DVD may appear as "UEFI (FAT) TSSTcorp CDDVDW SH-224DB (1028 MB)") Select the UEFI DVD or USB option from the firmware boot menu and boot up with it. Now proceed as you usually do to install Kubuntu. If asked where to install GRUB boot-loader, simply choose sda (it won't really matter as the installer will automatically identify and use the proper ESP (EFI System Partition)).


How will you know you are booting your OS in UEFI mode?

You probably won't notice it when you boot up. You will probably be greeted with a GRUB boot menu. (If you have just one OS installed, the GRUB menu by default will not appear, and you'll boot directly into your OS. Press the Shift key to see the menu. This is controlled by the editable file /etc/default/grub.)

Check to see if you are in UEFI mode:
> Many newer computers (>2010) come with UEFI firmware.
> efibootmgr Issue this key EFI command: sudo efibootmgr [-v]. You should see BootOrder and a list of Boot variables.
> Your /etc/fstab file should show an EFI System Partition (mount point: /boot/efi, type EF00, vfat).
> gdisk See the ESP listed (as Type EF00) and confirm you have a GPT by issuing the command: sudo gdisk -l /dev/sda . (You might have to install gdisk using Muon Package Manager, or sudo apt-get install gdisk.)
> Open /boot/efi (the mount point of the ESP) and see your (U)EFI setup: /EFI/ubuntu and inside that folder, see some boot files: grubx64.efi, grub.cfg, shimx64.efi, etc.
> Your Kubuntu should use the grub-efi bootloader (not grub-pc). Check /usr/lib/grub -- do you see x86_64.efi[maybe also -signed]?
> An installed EFI system and a live system both use the directory /sys/firmware/efi (firmware Boot variables are there).

How UEFI booting works

Turn on your computer, see the Power-On-Self-Test (POST) screen, the UEFI firmware is started and initializes hardware and processes for booting. The UEFI firmware acts as a boot manager, it holds variables called NVRAM variables (NVRAM = non-volatile random access memory), each representing a UEFI application, a boot loader (e.g., GRUB) or another boot manager (e.g., rEFInd). The firmware holds a BootOrder list of NVRAM variables, telling it in what order to try loading the UEFI boot loaders. It finds the boot loaders in the ESP. The UEFI firmware tries to load the first UEFI boot loader (or application) listed in BootOrder. If that fails, it tries to load the second listed in BootOrder. It continues through the BootOrder list until it successfully launches a UEFI boot loader or application.

When you install Kubuntu, it calls setup scripts for GRUB, which call a key UEFI program efibootmgr which creates an NVRAM variable for your Kubuntu OS. This NVRAM variable is stored in the UEFI firmware. GRUB also sets itself up in your OS under /usr/lib/grub and /boot/grub where it stores its main configuration file grub.cfg. After installation finishes, the ESP (mounted in your OS at /boot/efi) will contain a folder for your Kubuntu called /EFI/ubuntu. For example, /boot/efi/EFI/ubuntu may contain these boot files for your Kubuntu: grub.cfg, grubx64.efi, shimx64.efi, and MokManager.efi. About these files:

-- This grub.cfg (in /boot/efi/EFI/ubuntu) is a brief file and used only in the /EFI/ubuntu directory to point at your main GRUB boot configuration file (in your Kubuntu: /boot/grub/grub.cfg). Here's an example of a /EFI/ubuntu/grub.cfg file:

  search.fs_uuid b65ee9d2-6dd4-4e66-bfe5-16bf0a551bd4 root hd1,gpt2   
  set prefix=($root)'/boot/grub'
  configfile $prefix/grub.cfg

Written in GRUB-language. The UUID is that of the partition hd1,gpt2, which corresponds to the second hard drive, the second partition gpt2; usually called sdb2. GRUB counts drives starting at zero (thus, hd1 is the second drive), and it numbers partitions starting at 1. The configfile statement simply re-directs control to the GRUB configuration file /boot/grub/grub.cfg in hd1,gpt2 (= sdb2), where an OS is located.

-- grubx64.efi This is the main GRUB EFI executable--it is a UEFI executable as indicated by the extension .efi.

-- shimx64.efi This is a story. About secure booting. The shim loader is here to handle that; it passes control to the GRUB loader grubx64.efi. Don't worry about it. Rod Smith on this:
http://askubuntu.com/questions/34236...64-and-shimx64
http://www.rodsbooks.com/refind/secureboot.html
MokManager.efi is also about secure booting (machine keys).


ESP -- EFI System Partition

The ESP contains EFI boot-loaders and boot managers for all OSs installed on your computer. It also contains other UEFI data and applications. For convenience and convention, though not required, you can make the ESP the first partition in the GPT on the first HDD: sda1 (also called hd0, gpt1).

Facts and specs

-- You should have at least one ESP. You can have more than one. You can place your ESP(s) anywhere on your HDDs, though sda1 is a popular and "standard" choice. If an ESP has already been set up by another OS (even by Windows), you can use it, too; all OSs on the computer can share the same ESP.
-- Specs: 100-512 MiB (recommended: 200 MiB minimum; preferred: 512 MiB); FAT32 file system; in GParted or libparted-based tools, set the "boot" flag on the ESP--this does not mean "bootable," it marks the partition as the ESP in a GPT, no other partition in a UEFI setup has a boot flag; in CLI tools, the partition type is EF00 or ef00.
-- Mount point: /boot/efi (viewed from the installed Kubuntu OS file system).
The ESP used by your OS is automatically mounted at /boot/efi. The /etc/fstab:
# /boot/efi was on /dev/sda1 during installation
UUID=74D7-02F2 /boot/efi vfat defaults 0 1
Even though you may have other ESPs on your system, when you are booted into an OS, the ESP that is mounted at /boot/efi is the ESP that was used to support the installation of GRUB for that specific OS.
-- /boot/efi/EFI is the top-level directory of the ESP. The subdirectories of /boot/efi/EFI contain the boot loader files (and other files) for each OS or UEFI application. The subdirectory used by Kubuntu and Ubuntu derivatives is /EFI/ubuntu.
-- The default bootloader is /EFI/BOOT/bootx64.efi, mounted as: /boot/efi/EFI/BOOT/bootx64.efi
-- Filename extension to indicate an EFI boot loader (an EFI executable, a binary file): .efi
-- You can work with the /EFI directory using your standard filesystem methods (Dolphin; command line). You can easily make a backup of the files contained in /boot/efi/EFI/ubuntu, for example, and place them in a folder /EFI/my_backups that you create.

3 ways to see what's in your ESP

(1) Use Dolphin. (2) Use the command line: cd /boot/efi, ls -l, cd /EFI, ls -l, etc. (3) Use the command tree (install tree using Muon or sudo apt-get install tree), then issue: tree /boot/efi (or cd /boot/efi, then: tree).
Also, when you run sudo gdisk -l /dev/sdx, it will list your ESP (with Code EF00).

df /boot/efi will show you the ESP your OS is using
If you have multiple ESPs, they could be anywhere on your HDDs, at any sdxy. The ESP for the OS you are booted into is mounted at /boot/efi. While booted into that OS, issue the command df /boot/efi to see what ESP partition is mounted for that OS.

How do firmware Boot (NVRAM) variables get created?

-- When you install an OS, the boot loader files are installed and a new Boot variable is created in the firmware (by GRUB setup scripts and by efibootmgr).
-- When you install a boot manager, like rEFInd, a Boot variable is created for it.
-- You can use the command sudo efibootmgr -c to create NVRAM variables (see man efibootmgr).
-- When you issue the grub-install command, a Boot variable is created.
-- If you make a folder under /boot/efi/EFI and populate it with an .efi executable, it will be detected by a boot manager like rEFInd; you can register it with the firmware using efibootmgr, then an NVRAM variable is created.
-- If you manually install a boot loader to a folder under /boot/efi/EFI, it will be detected by a boot manager like rEFInd; you can register it with the firmware using efibootmgr, then an NVRAM variable is created.


GPT -- GUID Partition Table

For a good graphic: https://en.wikipedia.org/wiki/GUID_Partition_Table ) .
Quick summary -- the structure of the GPT scheme is as follows:

Protective MBR -- the first 512 bytes (used for BIOS/CSM/legacy-MBR compatibility--See Note)
Partition Table Header -- the next 512 bytes
The Partition Table entries (128 of them 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 called the Secondary Partition Table Header
All GPT partitions are at the same level of a primary partition, though not called primary; GPT does away with the primary vs logical partition distinction. The only partition with a boot flag is the ESP (it doesn't mean bootable; it marks the partition as the ESP, type EF00).

Notes

The Protective MBR protects the GPT from partition utilities that are not GPT-aware. Such a utility will see the Protective MBR; the partition table of the Protective MBR indicates a full disk; thus, the utility will stop and give some informational message.

Sector analysis: You can do the math. Add the Protective MBR, the Partition Table Header, the Partition Table entries to get 17,408 bytes = 34 sectors (using logical sector size 512 B). LBA starts numbering at 0. There is this run of 34 sectors, thus making LBA 34 (the 35th sector) the first usable address. For optimal partition alignment, the first partition may start at the 1 MiB mark = sector 2048 (each 512 bytes). See this with sudo gdisk -l /dev/sda.

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. By default, GPT has 128 partitions, and does away with primary vs logical distinction. 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/


Two important, useful commands to memorize: sudo gdisk and sudo efibootmgr

gdisk (GPT fdisk, written by Rod Smith, the author of rEFInd boot manager)

(You may have to install gdisk: Muon Package Manager or sudo apt-get install gdisk.)
Use gdisk to confirm you have a GPT (and not an MBR); to check whether your GPT is in good shape; to list your partitions; to get the GUID of a partition; and to interactively work on (edit and fix) your GPT. See man gdisk. Walkthrough: http://www.rodsbooks.com/gdisk/walkthrough.html . Tutorial: http://www.rodsbooks.com/gdisk/ .
Run it on a disk for info: sudo gdisk -l /dev/sdx .
Run it interactively: sudo gdisk /dev/sda (with no options), press ? for help, press q for quit.

efibootmgr or the long version efibootmgr -v

efibootmgr is your main tool for interfacing with the computer's UEFI firmware. See man efibootmgr. efibootmgr shows the BootOrder (which is an NVRAM variable) and the NVRAM BootXXXX variables.

Example, partial output:

sudo efibootmgr -v
 BootCurrent: 0002  
 Timeout: 1 seconds  
 BootOrder: [B]000[/B][B]0[/B],0003,0002,0004,0001  
 Boot[B]0000[/B]* ubuntu        HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\ub
 untu\shimx64.efi)
 ...
 Boot0002* rEFInd Boot Manager   HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File
 (\EFI\REFIND\REFIND_X64.EFI)
 ... etc ...

On this boot-up, Boot0002 (rEFInd boot manager) was used to boot the computer. Normally, here, the first boot option (the default if you don't intervene) in BootOrder has been set (by you or by the firmware) to be Boot0000, your K(U)buntu; rEFInd (Boot0002) was set to be third in BootOrder.

For Boot0000* ubuntu: Asterisk * indicates Boot0000 is currently active and included in the Boot listing. "ubuntu" is a label set when you installed Kubuntu. HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884) is the device: 1 is partition 1; then an offset and a size; the GUID 0b3a3e36-b506-4f4a-9811-8549f1b5d884. If you were to look into this, that GUID corresponds to sda1 which is the ESP used by our Kubuntu in this example. Then File(\EFI\ubuntu\shimx64.efi): \EFI is the topmost directory of the ESP (in Linux, this is /EFI); then the ubuntu subdirectory; then the EFI-executable shimx64.efi file (which, as we said above simply calls the main GRUB executable grubx64.efi which (usually) then finds a grub.cfg file and then boots your Kubuntu).

Slashes, paths: Back slashes \ in path names are used in UEFI. Forward slashes / are used in Linux. UEFI will convert / to \ and then process it.

Note \EFI\ubuntu: The way it works now (9/2015), all Ubuntu derivatives (K(U)buntu, Mint, Lubuntu, Xubuntu, etc.) use the same EFI subdirectory \EFI\ubuntu (/EFI/ubuntu in Linux). Is this nice? No! Read below for some solutions to this.

UUIDs and GUIDs

efibootmgr identifies partitions by their GUIDs. GRUB uses UUIDs. To identify partitions:
To find GUIDs: ls -l /dev/disk/by-partuuid/
To find UUIDs: ls -l /dev/disk/by-uuid; or sudo blkid (which also shows your labels)
GUIDs: Also, use sudo gdisk /dev/sdx interactively to find the GUIDs of partitions ("i"; provide the partition number). Some versions of blkid also give GUIDs.

Changing the BootOrder in UEFI firmware

Two ways: use your UEFI firmware setup menu; or use efibootmgr: see man efibootmgr.
In the above example, BootOrder: 0000,0003,0002,0004,0001, to place Boot0003 first in boot order: sudo efibootmgr -o 0003,0000,0002,0004, or sudo efibootmgr -o 3,0,2,4 .

Removing Boot entries (NVRAM variables) from UEFI Boot list

In our example, to remove Boot0001 from firmware, issue: sudo efibootmgr -b 0001 -B . (man efibootmgr--examples at the end) CAUTION: Do not cause your PC not to start properly! Do not delete anything you don't fully understand.

Creating Boot entries, labels efibootmgr -L
See below: Changing labels on UEFI Boot entries: sudo efibootmgr -c -L


GRUB

We have seen three general versions of GRUB: GRUB Legacy, GRUB2, and now GRUB2 for EFI (GRUB2-EFI). See your GRUB version: sudo grub-install -V (or see installed grub files in Muon Package Manager; or look at /usr/lib/grub). When you install Kubuntu, the main GRUB files go in /usr/lib/grub; the boot configuration menu grub.cfg goes in /boot/grub, as do other GRUB files (modules); configuration files are set up in /etc/grub.d and /etc/default/grub.

In addition, for UEFI, GRUB places the executable file grubx64.efi in a subdirectory of the ESP, in /boot/efi/EFI (the ESP is mounted at /boot/efi). In a typical installation, you can find GRUB boot-loader files in /boot/efi/EFI/ubuntu (as of 9/2015, there is no subdirectory named kubuntu; ubuntu is used for all Ubuntu derivatives). Also, an NVRAM (BootXXXX) variable is created in firmware, it points at the GRUB executable in /EFI/ubuntu.

Re-installing GRUB while booted into Kubuntu

Use sudo grub-install to re-install GRUB when booted in Kubuntu; then use sudo update-grub to generate a new boot configuration file /boot/grub/grub.cfg. sudo grub-install will also (again) set up GRUB boot files in the ESP, in /boot/efi/EFI/ubuntu. (The ESP is always mounted at /boot/efi.) GRUB2-EFI does not take an install device (e.g., grub-install /dev/sdx makes no sense); instead, GRUB files automatically go into the ESP subfolder.

Technical note: grub-install defaults to the standard ESP subdirectory (e.g., boot/efi/EFI/ubuntu). If dual-booting more than one Ubuntu-based OS, and you used the section below called "Separate EFI directories for your OSs," then grub-install must be modified with --bootloader-id=some_name and --no-uefi-secure-boot.

man page, grub-install: man grub-install


Dual-Booting with Kubuntu and GRUB2-EFI
The summary is simple: Upon installing a second OS, GRUB from the second OS takes over the booting. You can still boot into all your OSs. The only thing that changes is which GRUB installation is controlling the main, first booting. You can fix things the way you want. Three things to know:

(1) Dual-booting, the GRUB from the last installed OS will take over the booting show.

(2) Each OS puts its boot-loader files in a subdirectory of /EFI: /EFI/fedora, /EFI/microsoft, /EFI/suse, /EFI/ubuntu. However, all Ubuntu-based distributions use the (same) directory, /boot/efi/EFI/ubuntu, making it difficult to install more than one OS based on Ubuntu (Kubuntu, Ubuntu, Mint, Xubuntu, Ubuntu Studio, etc.), or different versions of Kubuntu. You can install as many as you like; you just can't keep them in separate EFI folders. When you install one, it will over-write what is in /boot/efi/EFI/ubuntu with its own boot-loader files. There are workarounds for this default limitation (below).

(3) The last-installed OS or boot manager becomes first in UEFI BootOrder.

In analyzing dual-boot setups, it helps to keep a picture in mind of the Kubuntu-GRUB setup:
GRUB has its files in Kubuntu: /boot/grub, /boot/grub/grub.cfg (main boot config file), /usr/lib/grub, /etc/default/grub, etc. In the UEFI, GRUB's boot files are set up in the ESP subdirectory for K(U)buntu, /boot/efi/EFI/ubuntu, where you find the GRUB2-EFI executable grubx64.efi, and other boot files; it is set up to point to the main grub boot menu /boot/grub/grub.cfg in your Kubuntu OS: if there is a file in the ESP called /boot/efi/ubuntu/grub.cfg, as explained above (How UEFI booting works), that grub.cfg will point at the main GRUB boot menu /boot/grub/grub.cfg in your Kubuntu OS.


Fixing things

Kubuntu is installed, then you install a second Linux OS
Call the second OS Linux1, and assume that Linux1 is a non-K(U)buntu distribution. Linux1 will set up its GRUB2-EFI boot files in the ESP: /EFI/Linux1; it will (probably) become first in UEFI boot order; and, we hope, the GRUB-boot menu /boot/grub/grub.cfg in Linux1 will contain a boot entry for your Kubuntu.
-- However, for your Kubuntu GRUB-boot menu to include a boot entry for Linux 1, you must boot into your Kubuntu and run: sudo update-grub.
-- If you want the BootOrder changed (so Kubuntu is first in BootOrder), do one of two things: (1) Use sudo efibootmgr with the -o option to change the boot order (see above); or, (2) Simply boot into your Kubuntu and run the command: sudo grub-install (and then run sudo update-grub to update the boot menu /boot/grub/grub.cfg). Either (1) or (2) will place your Kubuntu first in UEFI BootOrder.

What if Linux1 is another K(U)buntu distribution (another Kubuntu OS, Mint, Ubuntu, Lubuntu, Xubuntu, etc.)?

As explained above, the ESP subdirectory /boot/efi/ubuntu is now populated not with your Kubuntu's GRUB files but with the GRUB files from Linux1; if there is a file /boot/efi/EFI/ubuntu/grub.cfg, it now points at the GRUB boot menu /boot/grub/grub.cfg in Linux1, which will contain an entry for booting your Kubuntu (BUT the GRUB-boot menu in your Kubuntu will not contain an entry for booting Linux1); and Linux1 becomes first in the UEFI BootOrder.

To fix this (if you want to): Boot into your Kubuntu, issue: sudo grub-install and sudo update-grub. Now the ESP directory /boot/efi/EFI/ubuntu is populated by GRUB-boot files from your Kubuntu; the /boot/efi/EFI/ubuntu/grub.cfg points at the main GRUB boot menu /boot/grub/grub.cfg in your Kubuntu system; Linux1 is included as a boot entry on that boot menu; and your Kubuntu becomes first in UEFI BootOrder.


rEFInd: Recommended

Between GRUB and rEFInd, you should never have a problem booting OSs. rEFInd will do it without GRUB. rEFInd is a boot manager; however, it can boot new Linux kernels (3.3 or later) directly using "EFI stub support" without the need for any boot-loader. rEFInd creates its own NVRAM variable and sets it first in BootOrder. Each time the computer is booted, rEFInd searches and displays bootable EFI apps and kernels. Find it in the ESP: boot/efi/EFI/refind/refind_x64.efi.

The rEFInd Boot Manager: Using rEFInd, by Rod Smith, author of rEFInd
http://www.rodsbooks.com/refind/using.html

My quick-and-easy install & setup of rEFInd
https://www.kubuntuforums.net/showth...l=1#post372221



Dual-booting Kubuntu: A summary of your options

The goal: Dual boot two Linux OSs, call them LinuxX and LinuxY.
Assumption: Both OSs come with GRUB2-EFI as their bootloader.


Solution #1: Do nothing special. Use rEFInd
The focus here is on passing control from the UEFI firmware boot manager to the rEFInd boot manager and boot-loader (it uses the "stub-loader" method of booting kernels directly).

Procedure:

Install LinuxX, re-boot and install LinuxY, boot into LinuxY, install rEFInd. You're done. You will now rely on rEFInd to boot your OSs.
Default: Boot your computer, you will see the rEFInd boot menu and choose an OS or kernel to boot.
(If you installed rEFInd immediately after installing LinuxX, then after installing LinuxY, you would have to boot into one of them and use efibootmgr -o to change the boot order so rEFInd is first in firmware BootOrder.)


Solution #2: Do nothing special. Use GRUB2-EFI
The focus here is on GRUB: We let the UEFI boot manager select the first OS listed in its boot menu to boot, control is passed to the GRUB boot-loader of that OS, which then boots the OS or presents you with a GRUB boot menu of other OSs.

Procedure:
Install LinuxX, re-boot, install LinuxY. You're done.
Default: When you boot your computer, LinuxY will boot by default. (And from the GRUB boot menu of LinuxY, you have a chance to select LinuxX to boot.)

Modification: Changing which OS controls the booting. If you prefer that (the GRUB from) LinuxX controls the booting: re-boot into LinuxX and issue: sudo grub-install and sudo update-grub.
Default: When you boot your computer, LinuxX will boot by default. (And from the GRUB boot menu of LinuxX, you will have a chance to select LinuxY to boot to.)


Solution #3: Try to use your UEFI firmware
The focus here is on using the UEFI firmware as a boot manager by pressing a special key to enter UEFI firmware boot menu(s) when your computer boots up, and selecting an OS to boot.

How well your firmware performs depends on the firmware design. The UEFI firmware boot manager is not a boot-loader. It can't boot an OS directly, but it can boot to the GRUB boot-loader of that OS. The firmware can also start another boot manager, rEFInd, which is also a boot-loader.

Procedure:
Install LinuxX, re-boot and install LinuxY.
Default: When you boot your computer, LinuxY will boot by default.
You're done, unless you wish to look at this more closely ...
If both OSs are Ubuntu derivatives, then do 3a. Otherwise skip to 3b.

3a: Both OSs are Ubuntu derivatives
The boot menu of your UEFI firmware will show just one entry labeled "ubuntu." Since LinuxY was installed after LinuxX, the "ubuntu" entry in your UEFI boot menu will refer to LinuxY and LinuxY will be first in firmware BootOrder.
Default: When you boot your computer, LinuxY will boot by default. Its GRUB boot menu will show LinuxX as a boot option.

Adjusting GRUB boot menus: If you prefer to see the GRUB boot menu of LinuxX rather than that of LinuxY, do this: Boot into LinuxX and issue: sudo grub-install and sudo update-grub. (Now, /boot/efi/EFI/ubuntu will contain the GRUB boot files from LinuxX, rather than LinuxY.)
Default: When you boot your computer, LinuxX will boot by default. Its GRUB boot menu will show LinuxY as a boot option.

3b: At least one OS is a non-Ubuntu OS

If both OSs are non-Ubuntu derivatives, the firmware boot menu will contain separate entries for both OSs, and in the ESP it looks like this: /boot/efi/EFI/LinuxX and /boot/efi/EFI/LinuxY.
Default: When you boot your computer, LinuxY will boot by default (since it was installed after LinuxX), unless you enter UEFI setup and select LinuxX.

If one OS is an Ubuntu-derivative and the other OS is not, the boot menu of your UEFI firmware will show just one entry labeled "ubuntu" and one entry corresponding to the other (non-Ubuntu) OS you installed (e.g., "debian" or "suse").
Default: When you boot your computer, LinuxY will boot by default (since it was installed after LinuxX), unless you enter UEFI setup and select LinuxX.

More?
If LinuxY (which you installed secondly) uses GRUB, when you select LinuxY, it should show you its GRUB boot menu, and LinuxX should be an option on it. If LinuxX also uses GRUB, and if you want the GRUB boot menu of LinuxX to contain a boot entry for LinuxY, then boot into LinuxX and issue: sudo update-grub.

Unless ... you want LinuxX to boot by default. In that case, boot into LinuxX and issue: sudo grub-install and sudo update-grub. Or, you could use efibootmgr -o to change BootOrder, placing LinuxX first and LinuxY second.
Now you are done with Solution #3.


Solution #4:For dual-booting two or more Ubuntu-based OSs: set up separate subdirectories of EFI: /boot/efi/EFI/<some_ubuntu_distribution>
The focus here is on forcing the UEFI firmware to treat multiple Ubuntu derivatives individually.

If LinuxX and LinuxY are not Ubuntu derivatives, there is no problem because there will already be separate subdirectories: /boot/efi/EFI/<some_name for LinuxX> and /boot/efi/EFI/<some_name for LinuxY>.

Set up the dual-boot:
Assume both LinuxX and LinuxY are Ubuntu derivatives. Disable Secure Boot in firmware setup.
We also assume that they will use the same ESP. (If different ESPs, see Solution #5.)

--> Install LinuxX (or, perhaps it is already installed). Boot into it and issue:

sudo grub-install --bootloader-id=<some_name_for_LinuxX> --no-uefi-secure-boot

That sets up the EFI boot directory for LinuxX: /boot/efi/EFI/<some_name_for_LinuxX>.
--> Install LinuxY. Boot into it and issue:

sudo grub-install --bootloader-id=<some_name_for_LinuxY> --no-uefi-secure-boot

That sets up the EFI boot directory for LinuxY: /boot/efi/EFI/<some_name_for_LinuxY>.

LinuxY will be first in BootOrder since it was installed after LinuxX. If you want LinuxX to be first in BootOrder, boot into LinuxX and issue sudo grub-install --bootloader-id=<some_name_for_LinuxX> --no-uefi-secure-boot. If you want LinuxY to be listed on the GRUB boot menu of LinuxX, issue: sudo update-grub. To change the BootOrder, you may also use sudo efibootmgr -o (see man efibootmgr).

Technical note: If you use --no-uefi-secure-boot, /boot/efi/EFI/<some_name for LinuxX[Y]> may only contain one file: grubx64.efi, and no grub.cfg. Reason: The pointer to the target (/boot/grub/grub.cfg in LinuxX[Y]) will be hard-coded in the executable grubx64.efi. (Also you won't see shimx64.efi or MokManager.efi because Secure Boot is OFF; there is no need for them.)

Whatever labels you choose, you will be able to recognize them in the UEFI firmware boot menu(s) and in the rEFInd menu (if rEFInd is installed).

If you want to use rEFInd: Boot into LinuxX or LinuxY, install rEFInd. Since rEFInd was installed last--after LinuxX and after LinuxY--it will appear first in UEFI boot order. Re-boot. You should then see the boot menu from rEFInd, from which you will recognize the entries you created for the separate /EFI subdirectories for LinuxX and LinuxY.


The general GRUB2-EFI command

sudo grub-install --target=x86_64-efi  --efi-directory=[U]DIR[/U]  --bootloader-id=some_name [--no-uefi-secure-boot]

This command creates an NVRAM boot variable in UEFI firmware (if you did not use --no-nvram).
DIR is the mount point of the ESP. The default is /boot/efi. You can mount any of the ESPs on your system and give its path as the DIR. some_name is a name you made up for /boot/efi/EFI/<some_name> (where this GRUB goes). --target tells GRUB what system-version of GRUB to install. If you use UEFI, it is x86_64-efi, and you can omit --target; installing GRUB to an older PC, use --target=i386-efi.

--no-uefi-secure-boot Somewhat technical but most useful if you are dual-booting more than one Ubuntu-based OS.
--no-uefi-secure-boot: do not install an image usable with UEFI Secure Boot, even if the system was currently started using it. This option is only available on EFI.
--uefi-secure-boot: install an image usable with UEFI Secure Boot. This option is only available on EFI and if the grub-efi-amd64-signed package is installed.
man page, grub-install: http://manpages.ubuntu.com/manpages/...install.8.html


Technical note Briefly: There is just one EFI subdirectory for Ubuntu-based OSs, /boot/efi/EFI/ubuntu. You can get around this by creating separate, clearly named subdirectories for Ubuntu-based OSs using -bootloader-id=some_name. Suppose you do this for Ubuntu-based LinuxX; thus, /boot/efi/EFI/<some_name_for_LinuxX> contains the GRUB files for LinuxX. Now boot from <some_name_for_LinuxX>. Instead of using the location of LinuxX's GRUB files pointed to by /boot/efi/EFI/<some_name_for_LinuxX>, the system may use the location pointed to by the default directory /boot/efi/EFI/ubuntu (by /boot/efi/EFI/ubuntu/grub.cfg). This happens because the location /boot/efi/EFI/ubuntu/grub.cfg is hard-coded into the GRUB executable grubx64.efi. (The location /boot/efi/EFI/ubuntu is populated by the MOST RECENT (K)Ubuntu-based OS installed (or from which grub-install (with no options) was run). To fix this, you must (1) disable secure booting in UEFI firmware, and (2) use --no-uefi-secure-boot in your grub-install command when setting up a dual-boot with Ubuntu-based OSs using separate EFI directories.

See lxgr's blog Booting multiple Ubuntu versions with EFI
http://blog.lxgr.net/posts/2015/04/3...efi-multiboot/


Solution #5: Use separate ESPs for LinuxX and LinuxY
The focus here is on using more than one ESP on your computer system. You don't have to do this, ever. But you might want to do it for design, for convenience, for your own reasons, experimenting, or if you have two or more HDDs (even then, you only really need one ESP for the entire system). Creating separate ESPs would be useful if you are installing more than one Ubuntu derivative. In that case, you want to label each ESP with a name you'll recognize, and use a boot manager--like rEFInd--that will also use the ESP labels. Your UEFI boot manager may not use the ESP labels--it may only recognize within each ESP a subdirectory of /EFI. And for Ubuntu-based OSs, they may each, in their separate ESPs, be named /EFI/ubuntu in the UEFI menus, and then you'd have a bunch of indistinguishable "ubuntu" choices in the UEFI boot menu, but this is fixable with re-labeling (below).

In general terms, Solution #5 is (1) Set up the ESPs and the OS partitions you need, using your partition editor; give each ESP a label that you will recognize. (2) Install each of the two (or more) new OSs, in sequence, with this procedure:
Turn off all ESPs (by turning off their boot flags) except for the ESP you wish to make a dedicated ESP for the OS you are about to install now. Then do the OS installation using the Manual installation method. Repeat for each OS. After you have finished installing all the OSs, using GParted live CD/USB, or booting into your last-installed OS and installing and using gparted, turn on all ESPs (by re-setting their boot flags in GParted), and re-boot to test everything. When booted into one of your OSs, to see the ESP it is using, run the command: df /boot/efi (which shows the ESP partition mounted at /boot/efi for THAT OS).

(Recall the ESP Details: Use GParted. ESP specs: 200-512 MB, FAT32, set the boot flag (in GParted: Partition > Manage Flags > boot; indicates partition type EF00), set a label on the ESP (Partition > Label). Run sudo gdisk -l /dev/sdx to see the ESP(s), type EF00.)

After this is set up, how does the booting work?

Default: When you boot the computer, the last OS you installed will be selected and booted by your UEFI firmware. This is also true: Let's say you installed the OSs, say LinuxX first, then LinuxY second, each into its own ESP. So LinuxY will have an entry in UEFI firmware BootOrder that is listed first. Now you boot into LinuxX and you issue the command sudo grub-install. That action will place LinuxX first in the firmware BootOrder (and it re-installs GRUB to the ESP for LinuxX in /boot/efi/EFI/<subdirectory_for_LinuxX>). (With this method, as in previous solutions above, you may not see nice, complete GRUB boot menus unless you have made certain of it by booting into each of your OSs and issuing: sudo update-grub).

When you run a final "efibootmgr -v," check everything, inspecting that all ESPs are listed (you will have to identify them using GUIDs, with ls -l /dev/disk/by-partuuid). Check the ESP mounting with df /boot/efi (issued from within each OS). You can also run sudo gdisk -l /dev/sdx on your HDDs to see the ESPs, Type EF00.

Using the boot manager rEFInd: a real good idea
If you have rEFInd installed, test it, too. If you don't have it installed, consider doing so. It will work with GRUB; it will also show and boot your kernels (labeled vmlinuz-) without GRUB by the stub-loader method. rEFInd may show more and better detail than UEFI firmware boot menus. It may show the ESPs nicely labeled (e.g., for the ESP labeled MintTest, you may see "/EFI/ubuntu/grubx64.efi from MintTest").

Using your UEFI firmware. It depends on your firmware: Multiple "ubuntu" entries?
My ASUS (H97-Plus) UEFI firmware handles EFI booting very well, nice menus, but for the "ubuntu's," it can be confusing. Remember that an Ubuntu OS's GRUB boot files are stored in the ESP subdirectory /boot/efi/EFI/ubuntu. So if you have four Ubuntu's on your system (Kubuntu, Mint, Ubuntu, etc.), each in its own ESP, you'll see four boot entries called "ubuntu." Sometimes, you just have to try them by trial-and-error, set their boot order using efibootmgr -o and then remember their order. Or, fix this using the next topic on setting labels.


Labels: Setting labels for UEFI Boot variables--useful for "ubuntu" OSs

Example
Kubuntu 15.04 is installed on sda12, uses an ESP on sda10, and has an "ubuntu" UEFI label. With sudo efibootmgr -v, we see:

 Boot000C* ubuntu        HD(a,2e054800,fa000,48318e7e-c8b2-4621-9887-4a2dac8ee62d)File(\EFI\UBUNTU\GRUBX64.EFI)..BO

Its UEFI boot variable is Boot000C with label "ubuntu." You'd like to change it to "K1504-sda12."

Fact: You can't edit or modify the existing boot entry "Boot000C ubuntu". That is, you can't change the current "ubuntu" label. Instead, you must CREATE a new boot variable labeled whatever you wish. Then, if you wish, you can delete the old boot variable "Boot000C ubuntu."
To create a boot variable for Kubuntu 15.04 labeled "K1504-sda12" (without quotes), issue:

sudo efibootmgr -c -d /dev/sda -p 10 -L K1504-sda12 -l \\EFI\\ubuntu\\grubx64.efi
 (you'll get automatic output -->)
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: [B]0007[/B],0000,0003,0001,0004,000A,0005,0006,0002,000C,000D
...
Boot000C* ubuntu <-- the old (but still active) boot variable for Kubuntu 15.04
...
[B]Boot0007* K1504-sda12[/B] [COLOR=#000000]<-- the [/COLOR][COLOR=#000000][U]new boot variable[/U][/COLOR][COLOR=#000000] for Kubuntu 15.04[/COLOR]

It's that simple.
The old boot entry "Boot000C ubuntu" is still present, and it also works to boot into this Kubuntu 15.04 on sda12. You may keep Boot000C ; or delete it:

sudo efibootmgr -b 000C -B

If you delete it, it will be gone from the listing efibootmgr -v, and gone from UEFI firmware. However, if you look in the ESP for this Kubuntu 15.04 OS, you will see the same as before: /boot/efi/EFI/ubuntu containing the same files grub.cfg, grubx64.efi, MokManager.efi, and shimx64.efi.
--> "000C ubuntu" is deleted ONLY from the firmware boot list; nothing is deleted from the ESP or from the Linux OS filesystem.
--> In fact, the new firmware boot variable (Boot0007 K1504-sda12) will point at the same four bootloader files in the same subdirectory of the same ESP (sda10): /boot/efi/EFI/ubuntu. (The GUIDs and the FILE string in the long version efibootmgr -v are useful for seeing this: the output of efibootmgr -v is identical for both Boot0007 and Boot000C.)

Labels: The general case

The setup
You have a UEFI boot variable, BootXXXX (in the BootOrder), and you'd like to create a new label for it (as seen in the UEFI firmware boot menu(s) and output of sudo efibootmgr). Assume this boot variable uses the following boot-loader file in its ESP (assume the ESP is sdxn): /EFI/<directory_current>/<boot_loader>; the current label (in UEFI lists) would be "directory_current".
Goal: Change the label to NewLabel.
Solution
You can't change the label; instead, create a new boot variable having the label NewLabel and pointing at the same ESP sdxn and same /EFI/<directory_current>/<boot_loader>.
So, boot (in UEFI mode) the OS (represented by BootXXXX). Issue:

sudo efibootmgr -c -d /dev/sdx -p n -L NewLabel -l \\EFI\\<directory_current>\\<boot_loader>

If you wish, you can delete the old boot variable (having the old label) using

sudo efibootmgr -b XXXX -B

--> This deletes only the listing of the variable in UEFI firmware. It does not delete anything in the ESP or in the Linux filesystem. The output of efibootmgr -v is identical for both the old and the new boot variables: they point at the same /EFI/<directory_current>/<boot_loader>.
Updating GRUB2-EFI: Getting an update to GRUB or running sudo grub-install (which updates <boot_loader>) in this OS will not break either the new or the old boot variable.

Discussion
See: man efibootmgr. See my full, detailed tutorial:
Labels on UEFI Boot Entries -- using efibootmgr -L, How to "change" an "ubuntu" label (/EFI/ubuntu)
https://www.kubuntuforums.net/showth...229#post378229

Briefly: -c create a new boot variable; -d The disk containing the boot-loader = the disk containing the ESP; -p The ESP partition containing the boot-loader; -L Label, UEFI firmware boot manager display label; -l The loader, the boot-loader (full path name) written in UEFI notation with double back slashes (required).

Fixing things in your UEFI+GPT

Repairing the GPT
If you delete a partition, use TestDisk to recover it. If you damage the GPT Partition Table Header or the Partition Table, use the interactive gdisk to recover. See my:
https://www.kubuntuforums.net/showth...417#post372417

Fix boot problems from a live Kubuntu DVD/USB
In a live Kubuntu session, you can make a live rEFInd CD or flash drive (and re-boot into your broken OS); install Boot Repair and run it; re-install GRUB manually using chroot. You can also rescue data, do partitioning, and edit system files. See my how-to:
https://www.kubuntuforums.net/showth...l=1#post379485

Boot Repair (to fix GRUB): https://help.ubuntu.com/community/Boot-Repair



[[[[[[[[[[]]]]]]]]]] [[[[[[[[[[]]]]]]]]]] [[[[[[[[[[]]]]]]]]]]

Cheat Sheet UEFI+GPT

Installing the OS in UEFI mode
Use 64-bit Kubuntu -- Configure UEFI firmware -- Partitioning: include ESP
Boot Kubuntu installer in UEFI mode and install Kubuntu.

How will you know you are booting your OS in UEFI mode?
Run: sudo efibootmgr [-v]; /etc/fstab file contains an ESP; Open /boot/efi to see the EFI subdirectories; /usr/lib/grub: x86_64.efi[-signed]? GRUB: grub-efi (not grub-pc); for either installed or live system: /sys/firmware/efi present? GPT present?: sudo gdisk -l /dev/sdx (look for ESP EF00) .

Important, useful commands

sudo efibootmgr [-v] (To check the UEFI firmware boot order)
sudo gdisk -l /dev/sdx (To check or fix the GPT)
df /boot/efi (To see the ESP sdxn, mounted as /boot/efi, used by the OS you are in now)
lsblk (To see sdxn: disks, partitions, mount points)

GUIDs: ls -l /dev/disk/by-partuuid/
UUIDs: ls -l /dev/disk/by-uuid/ ; or sudo blkid

To see ESP /boot/efi contents: tree /boot/efi; or Dolphin: open /boot/efi; or ls /boot/efi; then cd /boot/efi/EFI; then ls.
gdisk: sudo gdisk -l /dev/sdx lists GPT partitions and ESPs with Code EF00
gdisk: interactively: sudo gdisk /dev/sdx, then ?, i, then partition #

inxi -Fxxx (Kubuntu, KDE versions; system information)
sudo dmidecode (BIOS/motherboard/system information)

Specialized commands

Change UEFI BootOrder: sudo efibootmgr -o 0003,0000,0002,0004, or sudo efibootmgr -o 3,0,2,4
Remove UEFI Boot variable BootXXXX: sudo efibootmgr -b XXXX -B
Creating UEFI Boot entries, labels efibootmgr -c -L -l:
sudo efibootmgr -c -d /dev/sdx -p n -L NewLabel -l \\EFI\\<directory_current>\\<boot_loader>
(This registers in UEFI firmware a NVRAM variable with Label L.)

grub-install: Separate /EFI subdirectories, /boot/efi/EFI/<some_name_for_LinuxX> :
(First turn off Secure Boot in UEFI firmware setup menu; boot into the OS LinuxX you are making an EFI subdirectory for.)
sudo grub-install --bootloader-id=<some_name_for_LinuxX> --no-uefi-secure-boot
(This creates /boot/efi/EFI/some_name_for_LinuxX)

Making a bootable Kubuntu flash drive, using dd. If the flash drive is seen as /dev/sdX:
sudo dd if=/path/to/kubuntu_filename.iso of=/dev/sdX bs=16M
sync

ESP -- EFI System Partition
Specs: 100-512 MiB (prefer: 200 MiB-512 MiB); FAT32; GParted/libparted-based tools: set "boot" flag on ESP; CLI: partition type EF00
-- Mount point: /boot/efi. df /boot/efi shows the ESP of the OS you are in now is using;
-- /etc/fstab:
# /boot/efi was on /dev/sda1 during installation
UUID=74D7-02F2 /boot/efi vfat defaults 0 1
-- Top-level directory of ESP is EFI: /boot/efi/EFI
-- Default boot-loader: /EFI/BOOT/bootx64.efi, mounted: /boot/efi/EFI/BOOT/bootx64.efi
-- See what's in your ESP: (1) Dolphin: /boot/efi. (2) CLI: cd /boot/efi, ls -l (3) tree /boot/efi
-- sudo gdisk -l /dev/sdx lists GPT partitions and ESP with Code EF00

GPT -- GUID Partition Table layout:
Protective MBR -- first 512 bytes (for BIOS/CSM/legacy-MBR compatibility)
Partition Table Header -- the next 512 bytes
The Partition Table entries (128 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 called the Secondary Partition Table Header
All GPT partitions are at level of a primary partition, though not called primary; only partition with a boot flag is the ESP (it doesn't mean bootable; marks it as the ESP, type EF00).
[Optional: Bios Boot partition, 1 MiB, no filesystem, flag: bios_grub; type EF02]

GRUB
Version: sudo grub-install -V; /usr/lib/grub; /boot/grub/grub.cfg; /etc/grub.d , /etc/default/grub;
UEFI: in ESP /boot/efi/EFI/ubuntu/grubx64.efi (also shimx64.efi, grub.cfg, MokManager.efi)
Re-install GRUB while booted into Kubuntu: sudo grub-install; make a new boot menu: sudo update-grub
man page, grub-install: man grub-install
Boot managers: GRUB is a boot manager and boot-loader; so is rEFInd; UEFI is only a boot manager.

Technical note: grub-install defaults to the standard ESP subdirectory (e.g., boot/efi/EFI/ubuntu). If dual-booting more than one Ubuntu-based OS, and you used the method "Separate EFI directories," then grub-install must be modified with --bootloader-id=some_name and --no-uefi-secure-boot.


Dual-booting Kubuntu: A summary of 5 options
3 facts:
(1) GRUB from the last installed OS will take over the booting show.
(2) All Ubuntu-based distributions use the (same) directory name ubuntu in the ESP: /boot/efi/EFI/ubuntu; the last installed OS will overwrite previous /EFI/ubuntu contents. Other non-Ubuntu OSs have their own /EFI subdirectory.
(3) The last-installed OS or installed boot manager becomes first in UEFI BootOrder.
--> Fix this using either efibootmgr -o; or if GRUB, using sudo grub-install (and sudo update-grub).

5 methods for dual booting:
#1, #2, #3, do nothing special:
(1) Use rEFInd. (2) Use GRUB2-EFI. (3) Use the UEFI firmware.
Or, try #4 or #5:

(4) Ubuntu-based OSs: set up separate subdirectories of EFI: /boot/efi/EFI/<some_ubuntu_distribution>
Set up the dual-boot: Both LinuxX and LinuxY are Ubuntu derivatives, using the same ESP.
Disable Secure Boot in firmware. Install LinuxX, boot into it, then:

sudo grub-install --bootloader-id=<some_name_for_LinuxX> --no-uefi-secure-boot

Repeat with LinuxY. Optional: adjust BootOrder and generate new boot menus.

(5) Separate ESPs:
GParted: set up the ESPs and the OS partitions you need, give each ESP a label you will recognize. Install each OS, in sequence, with this procedure: Turn off all ESPs (turn off their boot flags) except for the ESP you wish to be used by the OS you are about to install now. Install the OS using the Manual installation method. Repeat for each OS. Then turn on all ESPs (re-set their boot flags in GParted).

Labels: Setting (and "changing") labels for UEFI Boot variables--useful for multiple "ubuntu" OSs

Fact: You can't edit or modify an existing boot entry. Instead, you must CREATE a new boot variable labeled whatever you wish. Then, if you wish, you can delete the old boot variable.
The setup: The UEFI boot variable BootXXXX uses ESP sdxn and the boot-loader file /EFI/<directory_current>/<boot_loader>. Goal: Change the label to NewLabel.
Solution
To create a new boot variable having the label NewLabel and pointing at the same ESP sdxn and same bootloader: /EFI/<directory_current>/<boot_loader>, boot (in UEFI mode) the OS (represented by BootXXXX). Issue the command:

sudo efibootmgr -c -d /dev/sdx -p n -L NewLabel -l \\EFI\\<directory_current>\\<boot_loader>

(This registers in UEFI firmware a NVRAM variable with Label L = NewLabel.)

To delete the old boot variable (having the old label):

sudo efibootmgr -b XXXX -B

--> This deletes only the listing of the variable in UEFI firmware. It does not delete anything in the ESP or in the Linux filesystem. The output of efibootmgr -v is identical for both the old and the new boot variables: they point at the same /EFI/<directory_current>/<boot_loader>.
Updating GRUB2-EFI: Getting an update to GRUB or running sudo grub-install (which updates <boot_loader>) in this OS will not break either the new or the old boot variable.

[Qqmike]

Boot Kubuntu Using UEFI Only -- no GRUB, no bootloader, no rEFInd, no other boot manager/loader


If you have a newer computer, say 2010 or later, and the computer's firmware is the newer UEFI (not the older BIOS), and your kernel is 3.3.0 or later, your EFI firmware may be able to boot the kernel directly using the stub-loader method. For background on this see Rod Smith's,
Managing EFI Boot Loaders for Linux:
Using the Kernel's EFI Stub Loader
http://www.rodsbooks.com/efi-bootloaders/efistub.html

We illustrate this using Kubuntu's kernel vmlinuz-3.13.0-100-generic (or vmlinuz-3.13.0-100-generic.efi.signed). We turn off Secure Boot in the computer's firmware. Thus, you may use either the -generic or the -generic.efi.signed kernel. We'll use the former, vmlinuz-3.13.0-100-generic.

You'll have to access and edit your ESP; i.e., your /boot/efi/EFI directory; and so you must do so as "root." Do this in any way you feel comfortable. Here, we will simply open the file manager Dolphin as root and work from there.

Finally, we assume your kernel files are in the /boot directory of your Kubuntu / partition.


Make a subdirectory of EFI and copy your kernel and initrd files into it.

So we open Dolphin as root,
kdesudo dolphin
and we make a subdirectory of EFI that we'll call StubL, and so we have /boot/efi/EFI/StubL.
Then we copy (do NOT move) the kernel files from /boot to /boot/efi/EFI/StubL.
So, in that StubL subdirectory, we now have:
vmlinuz-3.13.0-100-generic, intird-3.13.0-100-generic, and perhaps you will copy the related files you find in /boot (config-3.13.0-100-generic, System.map-3.13.0-100-generic, and abi-3.13.0-100-generic)--I'm not sure these additional files are needed.


Change the name of the kernel file you copied into the EFI subdirectory

(In /boot/efi/EFI/StubL) we'll shorten its name and append .efi to it:
vmlinuz-3.13.0-100-generic --> vmlinuz-3.13.0-100-gen.efi
(more on this later)


Create a boot entry in your computer's UEFI firmware for your kernel.

We assume that the ESP is /dev/sda1 and your Kubuntu root filesystem (where /boot is) is /dev/sda2.
The statement to create this boot entry in your computer's UEFI firmware (or to "register" this boot entry in your UEFI firmware) is the following:

sudo efibootmgr -c -d /dev/sda -p 1 -l  '\EFI\StubL\vmlinuz-3.13.0-100-gen.efi' -L 'vmlinuz3130-100' -u 'ro  root=/dev/sda2  quiet splash  initrd=\EFI\StubL\initrd.img-3.13.0-100-generic'

NOTES


(1) You could also use the UUID for sda2; e.g., root=UUID=127fc14b-aa8a-4c00-b781-0a70a88cf07c, where the UUID for sda2 is found by the command blkid or the command ls -l /dev/disk/by-uuid/ .


(2) For this UEFI boot entry, we created the label vmlinuz3130-100 that we will recognize in UEFI firmware boot menus (and elsewhere, like rEFInd's boot menu, if we were using rEFInd).


(3) After running that efibootmgr -c command, you'll get output from efibootmgr, showing the resulting, current boot order; e.g.,

  BootCurrent: 0003
  Timeout: 1 seconds
  BootOrder: [B]0006[/B],0000,0003,0007,0001,000A,0005,0002,0004,000B
  Boot0000* ubuntu
  Boot0001* debian
  Boot0002* grub_sda5K1504
  Boot0003* rEFInd Boot Manager
  Boot0004* Mint_2
  Boot0005* Hard Drive  
  Boot0007* TestMint_sda8
  Boot000A* Mint_1
  Boot000B* ubuntu
  Boot[B]0006[/B]* [B]vmlinuz3130-100[/B]

You'll note that the newly created boot entry (Boot0006, for vmlinuz3130-100) is placed first in BootOrder. Thus, when you re-boot, your UEFI firmware will attempt to boot that entry first; of course, that entry corresponds to the kernel vmlinuz-3.13.0-100-generic that you wish to boot.


(4) If, for some reason, you want to delete this new boot entry, do so using efibootmgr; using our example, the command would be

sudo efibootmgr -b 0006 -B

(5) If you want to change the boot order, do so using efibootmgr -o. Using our example, if we wanted to switch 0006 and 0000, the command would be

sudo efibootmgr -o 0000,0006,0003,0007,0001,000A,0005,0002,0004,000B

(6) Renaming the kernel file from vmlinuz-3.13.0-100-generic to vmlinuz-3.13.0-100-gen.efi


(All this is in /boot/efi/EFI/StubL) So that your UEFI firmware recognizes the kernel as an efi application, we want to append .efi to the kernel name. We also want to shorten the kernel name for this reason: apparently, the total length of the string \EFI\<subdirectory>\<kernel_name> must be 39 characters or less (counting slashes and periods and hyphens, etc.). In our case, that string is \EFI\StubL\vmlinuz-3.13.0-100-gen.efi . I have seen truncation of longer strings in the output of efibootmgr -v. Steve Riley encountered this in his thread "Going GRUB-less" (cited below).


(7) For the efibootmgr command, see man efibootmgr.

-c to create an UEFI entry (NVRAM variable) in firmware; -d and -p the disk and partition of the ESP; -l the pathname of the bootloader file; and following the important -u switch, the kernel options and path to the initrd.


(8) For other discussions and treatments of this, see the following:


Rod Smith's Stub Loader page,
http://www.rodsbooks.com/efi-bootloaders/efistub.html
His EFI Boot Loader Installation page (for registering a bootloader using efibootmgr),
http://www.rodsbooks.com/efi-bootloa....html#register
His page, Methods of Booting Linux,
http://www.rodsbooks.com/refind/linux.html


Steve Riley's Going GRUB-less with UEFI,
https://www.kubuntuforums.net/showth...l=1#post309652
and his comment about the 39-character limit:
https://www.kubuntuforums.net/showth...l=1#post309923
and
Kano's post,
https://www.phoronix.com/forums/foru...ge2#post377791


How to boot load the kernel using EFI stub (efistub) loader?
http://askubuntu.com/questions/51085...efistub-loader


Arch Linux has this page:
https://wiki.archlinux.org/index.php..._UEFI_directly


For more on the efibootmgr command (-c, using labels, etc.), see my
UEFI Simplified, a quicker version
https://www.kubuntuforums.net/showth...l=1#post379977


(9) What can go wrong?

Typos!
It's conceivable that you might need certain kernel options in some cases.
Don't forget the -u switch in the efibootmgr -c command (has to do with reading text as unicode).
A lot depends on your computer's UEFI firmware, what mood it might be in today.
And who knows what else! For example, at the time of this writing, in the example used above, the -100 kernel boots OK, but we can't get the newer kernels -103 and -105 to boot yet.


Some sources indicate you need to use the initrd path in the EFI subdirectory (as we did); some indicate that it is not necessary. You can experiment with this. SteveRiley on initrd:
"One question remained: how do I know whether the two kernels installed will pick their correct initrd? I've opted to stop placing the initrd in the EFI partition. So now I have two initrds in /boot, one for each kernel. One last time to the reboot, this time selecting the prior entry that pointed to the older kernel. Sure enough, it booted without problem. It appears that the kernel knows which initrd to choose."