UEFI for Kubuntu--simplified. And ... some dual-booting tips for Kubuntu
Reviewed, edited for improvements, additions:
7-14-15; 8-23-15, 9-25-15, 9-27-15
UEFI Simplified -- a quicker version
This is intended to be a quicker version (more to-the-point) of the present tutorial (where you are at now): "UEFI for Kubuntu--simplified. And ... some dual-booting tips for Kubuntu."
If you prefer this more-to-the-point version, see:
https://www.kubuntuforums.net/showth...l=1#post379977
///////////////////////////////////////
The Simplified Formula ;-)
Accept the new technology of firmware/partition table: UEFI+GPT replaces BIOS+MBR.
Fix in your mind a picture of the GPT and UEFI setup.
Install your Kubuntu properly in UEFI mode.
(To prepare for that, optionally, you can do the partitioning of your HDD first.)
Accept, for now, that most users will use GRUB 2 (for EFI) as a boot loader.
Use rEFInd alongside GRUB.
Know a few basic things about how your UEFI firmware works to boot your computer.
Know what to expect when you set up dual/multi-booting, and how to fix it.
Have some tools, facts, tips, and references handy: a Cheat Sheet.
That's it. What follows is an expanded version of this simple formula, along with all the details you'll probably ever need to manage your UEFI booting in K(U)buntu.
- - - - - - - - - -
Starting again from the top ...Oops, I left out something from that title. Toss is one or two of these emoticons: ;-) and a sense of humor to boot (pun intended). This is a work-in-progress, and it is based on only my experience experimenting, only with Kubuntu on ASUS firmware, and a lot of reading. I even broke my machine once (had to reset the CMOS and lost all my firmware settings); also encountered the dreadful "failed: sdxy does not look like an ESP" (yep, it was accidentally an ext4 instead of FAT32--not thinking).
This should apply to Kubuntu, Ubuntu derivatives, and probably is in line with general Debian.
Bear in mind, with the new-ish UEFI+GPT, three things determine your experience: the firmware from the computer manufacturer (which may be quirky or buggy), how GRUB2-EFI handles UEFI, and the K(U)buntu installer.
Terms: The new way: (U)EFI+GPT. The old way: BIOS/CSM/legacy-mode+MBR.
**************************************************
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
References, if you had to pick just a few, and let's put them up front:
GPT, UEFI -- Study Guide, with many references, post #109 in this thread:
https://www.kubuntuforums.net/showth...l=1#post346604
GPT: http://en.wikipedia.org/wiki/GUID_Partition_Table
UEFI, ESP: Managing EFI Boot Loaders for Linux: Basic Principles:
http://www.rodsbooks.com/efi-bootloa...rinciples.html
ESP: http://en.wikipedia.org/wiki/EFI_System_partition#Linux
Using rEFInd: http://www.rodsbooks.com/efi-bootloaders/refind.html
Brief how-to on installing rEFInd:
https://www.kubuntuforums.net/showth...l=1#post372221
UEFI: https://help.ubuntu.com/community/UEFI
UEFI: https://wiki.archlinux.org/index.php/UEFI
GRUB: https://wiki.archlinux.org/index.php/GRUB
Boot Repair (to fix GRUB): https://help.ubuntu.com/community/Boot-Repair
Debian wiki: https://wiki.debian.org/GrubEFIReins...otProcess\b%29
The shimx64.efi loader: http://askubuntu.com/questions/34236...64-and-shimx64
--> Advanced: You really should read the next three articles, for facts and for some perspective:
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/
lxgr's blog
Booting multiple Ubuntu versions with EFI
http://blog.lxgr.net/posts/2015/04/3...efi-multiboot/
Rod Smith web pages: Very important, perhaps at this time THE source. Look over the topics at rodsbooks.com, he's covered just about everything with added references. He's the creator of rEFInd and gdisk, and a good author.
gdisk tutorial: http://www.rodsbooks.com/gdisk/
rEFInd: http://www.rodsbooks.com/efi-bootloaders/refind.html
To search Kubuntu forums and rodsbooks using google, write your search this way, for example:
site:kubuntuforums.net dual-booting +UEFI +Windows
site: gives you results from only the site you type; "quotes" gives you exactly what you put in quotes; + will make sure that word is there; - (minus sign) will omit the word.
To search the rodsbooks.com using google, e.g., search for GPT on his pages:
site:rodsbooks.com GPT
Post #132
Re-install GRUB2 from Live DVD/USB flash drive
https://www.kubuntuforums.net/showth...l=1#post374017
**************************************************
**************************************************
TABLE of CONTENTS
(sort of: to give you an idea what's in here; you may also want to skip to the cheat sheet in Section 7 to get an overview of things; it is a suggested cheat sheet--you may wish to modify it)
SECTION 1: UEFI+GPT to replace BIOS+MBR
UEFI+GPT to replace BIOS+MBR; the ESP is important for UEFI implementation
GPT layout
ESP -- EFI System Partition, specifications
BIOS Boot partition
SECTION 2: Install your Kubuntu properly in UEFI mode
Install your Kubuntu properly in UEFI mode: Use the 64-bit version of Kubuntu
(Optional: Do the partitioning of your HDD first.)
How to access your firmware setup
How to run the Kubuntu installer
Partitioning
Are you booted in EFI mode? Do you have a GPT?
SECTION 3: GRUB 2 (for EFI)
Find your GRUB files, executable, and version
Main GRUB configuration file
Installing GRUB, re-installing GRUB
grub-install, update-grub
An important GRUB-EFI command:
sudo grub-install --efi-directory=DIR --bootloader-id=some_name
The parameter --no-uefi-secure-boot
Re-install GRUB2-EFI from Live DVD/USB
SECTION 4: Use rEFInd alongside GRUB (Rod Smith is the rEFInd author/maintainer)
A brief how-to on installing rEFInd
rEFInd creates its own NVRAM variable and sets it to boot priority #1
Why you should use rEFInd
SECTION 5: A few basic things about how your UEFI firmware works to boot your computer
efibootmgr, gdisk
UEFI boot process
For example, /boot/efi/EFI/ubuntu may contain these files ...
gdisk is one of your main tools; sudo gdisk -l /dev/sdXY
Use gdisk to get GUIDs for your partitions: sudo gdisk /dev/sdX; UUIDs vs GUID--how to find both
Use ls -l /dev/disk/by-partuuid/ to get GUIDs for your partitions
UUID versus GUID: how to keep it straight so you can identify your partitions
efibootmgr is your main tool for interfacing with the computer's UEFI firmware boot manager
efibootmgr -- reading the output, BootOrder, Boot####
BootOrder is a NVRAM variable. Each Boot#### is a NVRAM variable
\Backward slashes (UEFI), /forward slashes (Linux)
See your ESP -- 3 methods; the tree command
How do NVRAM variables get created?
Boot managers
Changing the boot order, BootOrder, in UEFI firmware
Removing Boot entries (NVRAM variables) from your UEFI Boot list
Default boot loader, boot/efi/EFI/BOOT/BOOTX64.EFI
SECTION 6: Dual/multi-booting: Know what to expect ... and how to deal with GRUB
Dual-booting Kubuntu -- Two things you should know
Install Kubuntu, then install another OS. What can happen--what will probably happen?
Installing Kubuntu sets up GRUB and populates an ESP in a certain way
How to "fix" your dual-boot setup
Re-install GRUB to fix your boot setup
Use Boot Repair
To help make dual-booting easier -->
Create separate EFI subdirectories for your (K)Ubuntu (derivative) OSs
ESPs, the "default" ESP at sda1, and creating and using more ESPs
Changing the boot order in firmware: you may have to do this quite often
If you get a grub prompt, grub>, don't panic
Dual-booting: How to Use Multiple ESPs
Dual-booting Kubuntu: A summary of your options
NEW, 9-27-15:
SECTION 7: Cheat Sheet
Tools, facts, tips, summary
**************************************************
**************************************************
SECTION 1: UEFI+GPT to replace BIOS+MBR
UEFI+GPT to replace BIOS+MBR; the ESP is important for UEFI implementation
GPT layout
ESP -- EFI System Partition, specifications
BIOS Boot partition
UEFI = Unified Extensible Firmware Interface, a software interface between an operating system and platform firmware. UEFI is intended to replace BIOS. GPT is a subset of the UEFI specifications, poised to replace the MBR setup. UEFI+GPT is intended to replace BIOS+MBR.
A UEFI implementation uses a special partition called the EFI System Partition, or ESP.
GPT -- GUID Partition Table
Get a good start on this, get a good picture in your mind. In quick summary, the structure of the GPT setup is as follows (and for a graphic, see https://en.wikipedia.org/wiki/GUID_Partition_Table ) :
Protective MBR -- 512 bytes (used for BIOS/CSM/legacy-mode+MBR compatibility)
Partition Table Header -- 512 bytes
The Partition Table entries (128 of them are available in this setup, each has 128 bytes).
The actual partitions (those listed in the Partition Table entries)
The end-of-disk backup to the Partition Table
The end-of-disk backup to the Partition Table Header called the Secondary Partition Table Header
All GPT partitions are at same the level of a primary partition, though not called primary; GPT does away with the primary vs logical partition distinction.
-- and see what follows below for the ESP and the Bios Boot Partition --
ESP -- EFI System Partition
A UEFI implementation uses a special partition of GPT called the EFI System Partition, or ESP.
Specs of the ESP and what you need to know about it: try to make it sda1
The ESP contains all EFI bootloaders for all the OSs installed. 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).
-- Size: 100-512 MiB (recommended: 200 MiB minimum; preferred: 512 MiB).
-- FAT32 file system format
-- "boot flag": In GParted or libparted-based tools, set the "boot" flag on the ESP (although in UEFI that does not mean bootable, per se.) 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 filesystem).
-- /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.
-- Default bootloader is /EFI/BOOT/bootx64.efi, mounted as: /boot/efi/EFI/BOOT/bootx64.efi
-- Example of a directory made up to hold the rEFInd boot manager: /boot/efi/EFI/refind/
-- Filename extension to indicate an EFI boot loader (an EFI executable, a binary file): .efi
Notes
-- sda1-ESP may be automatically mounted in your Kubuntu.
When you boot into a Kubuntu (or maybe any Linux OS), the sda1-ESP will (probably) be automatically, already mounted at /boot/efi -- You can see it using Dolphin. It should also be listed in /etc/fstab. Note that 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 that specific OS (or, unlikely, to support a command you may have issued with sudo grub-install --efi-directory=DIR). For more on this technical point, see Section 6, Dual/Multi-booting, the topics toward the end of that section titled Dual-booting: How to Use Multiple ESPs and Dual-booting Kubuntu: Options, Summary.
-- Backup of your ESP
You can make a backup of your ESP any way you want. But one thing I do that's quick and easy is to simply back up the contents of /boot/efi/EFI/ubuntu that was created for the Kubuntu OS I just installed. You can do this at the command line. Or do it in Dolphin:
Open Dolphin as root: kdesudo dolphin; Click on root (at the left; or enter / in the location window). Click on /boot, then /efi, then EFI; Make a new directory (folder) by right-clicking, and call it what ever you wish, like my_backup_ubuntu_files; Open the ubuntu folder /boot/efi/EFI/ubuntu. Then copy-paste or drag-and-drop (as a COPY only--do NOT MOVE them!) the contents (usually four files like grub.cfg.grubx64.efi, shimx64.efi, MokManager.efi) into the new backup directory you just created.
BIOS Boot Partition: Booting in Legacy-CSM mode
--> It is probably desirable NOT to have to mess with this! Stick with straight UEFI+GPT, not with a legacy boot setup. You can skip this topic if you wish.
When using GPT with BIOS, Stage 1 of GRUB, called boot.img will fit into the first 446 bytes of the protective MBR, but you need room for the second stage of GRUB, the core.img. With the GPT layout, there is no gap, no room, for core.img (in GPT, the Partition Table Header starts immediately after the 512-byte MBR). Thus, if you wish to boot GPT using BIOS or you wish to boot UEFI in BIOS/CSM/legacy-mode, you need a BIOS Boot Partition for the core.img of GRUB 2.
Flag: Using the graphical GParted, create the BIOS Boot Partition, and set the flag on it as: bios_grub; using gdisk, it is of type EF02.
Size: Minimum size is 32 KiB, but most people are using 1 MiB (which also serves certain optimum partition-alignment goals--which, btw, these goals are also served by modern partitioning tools since about 2010).
Filesystem: The BIOS Boot Partition does not have a filesystem on it; it only holds raw binary code (the core.img stage of GRUB).
How-to: See the references (Ubuntu and Rod Smith).
**************************************************
**************************************************
SECTION 2: Install your Kubuntu properly in UEFI mode
Install your Kubuntu properly in UEFI mode: Use the 64-bit version of Kubuntu
(Optional: Do the partitioning of your HDD first)
How to access your firmware setup
How to run the Kubuntu installer
Partitioning: Do you want to do this beforehand?
Are you booted in EFI mode? Do you have a GPT?
How to access your firmware setup, boot menus: Most modern computers after about 2011 have UEFI firmware. Check your PC manual to find out how to access your computer's UEFI setup menus (by pressing a special key at the POST (Power-On-Self-Test) screen). Explore the UEFI setup menus, find where the boot menu is. If there is a setting to choose the boot mode (UEFI or BIOS), choose UEFI; also, you do not want CSM (disable it or set to "Auto"); disable Fast Boot; either disable Secure Boot or set it to "Other operating system" (not Windows--unless you have Windows and want to enable it).
Boot menus: You may have a main (permanent (until you change it)) boot menu and a second boot menu, often called the "boot override" menu, that allows you to select an OS (or other UEFI application) to boot for this one time. The UEFI firmware acts as a boot manager.
How to run the Kubuntu installer: You want to boot your Kubuntu install medium in UEFI mode (not in legacy BIOS/CSM mode). You must have the 64-bit version of Kubuntu (not 32-bit). Then, put your Kubuntu install medium in the PC (the CD/DVD drive, or USB port). Re-boot. At the proper POST time press the correct key to enter your computer's UEFI setup menus. From a boot menu (like the boot override menu), select the entry corresponding to the UEFI mode of your install medium. In that boot menu, you may see more than one entry for your install device, like two or three entries for your DVD, or multiple entries for your USB flash drive. Select an entry that has UEFI or EFI in its description. And proceed as you normally do, installing Kubuntu.
Partitioning: It may be good practice to partition your HDD before installing OSs. If you are not comfortable with that, skip this. For GUI, use GParted live media (CD or USB flash drive). Doing so is safer, more reliable, maybe faster, than allowing the Kubuntu installer to do the partitioning during the installation of Kubuntu. Also, this makes it a separate, controllable step, thus easier to troubleshoot if there's a problem. Format the HDD for UEFI+GPT, and for Kubuntu OS /, /home, and swap.
Example: Use the 64-bit version of GParted (live media or installed in Kubuntu). Boot your computer with GParted. First select Device: Create partition table: GPT. Then partition the GPT as follows.
sda1: to be the ESP: Starting at "the 1 megabyte" (at 1 MiB), create a FAT32 partition, 512 MB, with flag "boot." Then create the OS partitions: sda2 = /, sda3 = /home (using ext4 for sda2 & sda3), and sda4 = swap. Exit GParted. Then run the Kubuntu installer DVD, selecting the Manual method when prompted. No need to let the installer reformat any partitions except for the swap (if it so indicates).
Are you booted in EFI mode?
Check that you have /sys/firmware/efi/. You can see the boot variables in /sys/firmware/efi/vars/
https://wiki.archlinux.org/index.php...ess_under_UEFI
Do you have a GPT or MBR? At Konsole, run sudo fdisk -l . Did you get errors? Does it say you have a GPT? Run sudo gdisk -l /dev/sda: does it say you have a GPT?
**************************************************
**************************************************
SECTION 3: GRUB 2 (for EFI)
Find your GRUB files, executable, and version
Main GRUB configuration file
Installing GRUB, re-installing GRUB
grub-install, update-grub
An important GRUB-EFI command:
sudo grub-install --efi-directory=DIR --bootloader-id=some_name
The parameter --no-uefi-secure-boot
Re-install GRUB2-EFI from Live DVD/USB
Most users will use GRUB 2 (for EFI) as a boot loader. See Rod Smith's site for your options. See next topic for rEFInd (highly recommended). Importantly, see the section below on dual/multi-booting. My point here is that although GRUB is not ideal, it does work, you can work with it, it is a mainstream choice, and we are trying here to keep things simple (although most experts would say that GRUB is anything but simple). Most people will use it, so we need to talk about it. The Kubuntu installer will install GRUB for you, GRUB scripts will set it up and configure it.
Find your GRUB files, executable, and version
Example:The version of grub I'm using (as of 5/15) is Version 2, 2.02~beta-9ubuntu1.1;and it is called grub-efi-amd64;the executable is grubx64.efi; in the Kubuntu OS root partition, GRUB files are located at /boot/grub including its main configuration file grub.cfg.
You can get this information from:
-- Muon Package Manager (enter grub in search and you will see the installed packages for GRUB, highlight one then click the Technical Details tab at the bottom);
-- grub-install -V (run this command at Konsole);
-- see your main GRUB system files at /usr/lib/grub and the text at /usr/lib/grub/x86_64-efi-signed. Versions x86_64-efi are for UEFI; i386-pc are for BIOS.
Main GRUB configuration file
-- Upon booting, you will see a GRUB boot menu of choices to boot to. This menu comes from the main GRUB configuration file grub.cfg in the directory /boot/grub.
-- If you have just one OS installed, you may not see a boot menu when you boot you computer; to see it, hold down the Shift key immediately after the POST until it appears.
Installing GRUB, re-installing GRUB
When you install Kubuntu, the main GRUB system files are installed in /usr/lib/grub. GRUB uses those files to set up and configure itself for your OS. In addition, for UEFI, GRUB places the executable file grubx64.efi in a subdirectory of the ESP, in the directory /boot/efi/EFI (you recall that the ESP, usually sda1, is mounted in Kubuntu at /boot/efi). Thus, in a typical installation, you can find the GRUB boot loader files in the subdirectory /boot/efi/EFI/ubuntu (note, as of May 2015, there is no subdirectory named kubuntu; ubuntu is used for Ubuntu and its derivatives). For example, a typical installation might contain a brief configuration file /EFI/ubuntu/grub.cfg (this is not the main configuration file discussed above at /boot/grub/grub.cfg) and the executable file /EFI/ubuntu/grubx64.efi. Also, for a UEFI installation, a NVRAM (Boot) variable is created for the firmware, and it points at the GRUB executable in the /EFI/ubuntu. And, as part of your Kubuntu installation, GRUB writes its main Kubuntu configuration file grub.cfg and places it in the /boot/grub directory; it also sets up configuration files /etc/grub.d and settings from /etc/default/grub, both of these are used to generate the main /boot/grub/grub.cfg file.
--> For understanding UEFI, the NVRAM boot variable called ubuntu (pointing at the ESP directory /boot/efi/EFI/ubuntu) is important.
If you need to purge and re-install the main grub system files in /usr/lib/grub, you can do that using the Boot Repair utility, or by using Muon Package Manager, or by using the command line (e.g., Konsole). We will not talk about that here; however, I just told you all you need to know to do it yourself. It is rare that you would have to do so.
If the main GRUB system files are OK, and the installation of Kubuntu went OK, you may still want to re-install GRUB to /boot/grub and to /EFI/ubuntu on the ESP. You may want to do this to fix things or to adjust how your computer dual-boots your Kubuntu OS along with other OSs.
--> This is a key point for the section below titled "Dual/multi-booting: Know what to expect ... and how to deal with GRUB."
Case 1 A simple, "default" re-installation of GRUB: grub-install command
The command is simply
sudo grub-install
(For our purposes in dual-booting below, the grub-install command is issued at, say, Konsole, while you are booted into a Kubuntu OS. However, the grub-install command can also be issued from a live rescue CD or USB flash drive, perhaps by chroot-ing into your OS on the HDD/SSD. You must issue the command as root, using sudo or some other way, perhaps using sudo su to get a root prompt.)
This command will use the main GRUB system files to install or re-install GRUB files and its executable grubx64.efi to /boot/efi/EFI/ubuntu; and to place GRUB files (e.g., modules) in /boot/grub/x86_64-efi.
--> It will also place a NVRAM variable in the computer's UEFI firmware boot manager.
Note, however, that grub-install does not re-build a new main configuration boot file in your Kubuntu OS, the /boot/grub/grub.cfg. You must do that after running sudo grub-install by the command:
sudo update-grub
--> Two key points about the simple grub-install command:
-- In UEFI, it assumes (by default) that your ESP is the partition sda1 mounted at /boot/efi; thus it will modify the contents of the /boot/efi/EFI/ubuntu directory in the mounted sda1 partition.
-- Also, unlike the older GRUB Legacy or the GRUB 2 for BIOS, the GRUB 2 for EFI does not take an [install device] as an argument. For example, in UEFI, the command
sudo grub-install /dev/sda
makes no sense; it will run, but the device /dev/sda will be ignored. The installation is not done to any disk MBR or to any partition boot sector (like the MBR of /dev/sda or the partition boot sector of /dev/sda1). Instead, it is always made to a directory in the mounted ESP; i.e., to /boot/efi/EFI/ubuntu.
NOTE: Updating /boot/grub/grub.cfg
Ubuntu and Debian systems use sudo update-grub.
Other systems may use grub2-mkconfig -o /boot/grub/grub.cfg, or grub-mkconfig -o /boot/grub/grub.cfg
Case 2 A more general--and useful--grub-install command (see Technical Notes below)
DIR is the mount point of the partition ESP. The default (and the usual mount point for the sda1 ESP) is /boot/efi.
some_name is, well, some name you made up that you will recognize later if you see it listed in a GRUB boot menu or in the UEFI firmware BootOrder listing.
Example:
sudo grub-install --efi-directory=/boot/efi --bootloader-id=grubsda2
This command would install GRUB files to your sda1-ESP (mounted at /boot/efi) under the topmost directory /EFI to a subdirectory you named grubsda2; thus to: /boot/efi/EFI/grubsda2. The --efi-directory=/boot/efi tells GRUB that your ESP is mounted in your Kubuntu filesystem at /boot/efi.
Example:
sudo grub-install --efi-directory=/mnt/sdb2Test1 --bootloader-id=grubsdb2Test1
Example of how this might be used: Let's say you installed another instance of (K)Ubuntu in sdb2. And you created an ESP (or another ESP) at sdb1--you mounted it in your sdb2 Kubuntu OS at /mnt/sdb2Test1, and you wish to install GRUB (EFI) files to the subdirectory grubsdb2Test1, thus to the directory: /mnt/sdb2Test1/EFI/grubsdb2Test1. "Test1" may distinguish this installation from other testing installations you are doing. You can make up any name you wish for some_name as long as it makes sense to you when you see it listed again in a boot listing.
--> This will be most useful in Section 6 below "Dual/multi-booting: Know what to expect ... and how to deal with GRUB."
the parameter --no-uefi-secure-boot
--> If you are installing multiple Ubuntu-derivative OSs (versions of K(U)buntu, Mint, Xubuntu, etc.), you also may need the parameter --no-uefi-secure-boot in your grub-install command. See Create separate EFI subdirectories for your (K)Ubuntu (derivative) OSs in Section 6 below "Dual/multi-booting: Know what to expect ... and how to deal with GRUB."
Technical Notes
-- "--target=" The full command should read
where target tells GRUB what system-version of GRUB to install. Since most of us use x86_64-efi, we can omit the --target option on an EFI system. If you were installing GRUB to an older PC, you might use --target=i386-efi. http://www.pcmag.com/encyclopedia/term/54979/x86 , http://en.wikipedia.org/wiki/X86 .
-- /EFI reminder: You'll notice you see the directory /EFI in the paths. Recall that /EFI is the top-most directory of the mounted ESP (the EFI System Partition). GRUB knows this, and assumes it to be so.
-- /boot/grub/grub.cfg: Remember to update the main GRUB configuration file /boot/grub/grub.cfg using sudo update-grub.
-- Firmware: The grub-install command will also, automatically, place a NVRAM variable in the computer's UEFI firmware boot manager (if you did not use the option --no-nvram) The program efibootmgr can also be used to create such boot variables to be placed in the UEFI firmware. We will talk about this later. See man efibootmgr.
Here's a sample of what a boot listing would look like for this example. We'll discuss this subject later in more detail. This is a printout of a Boot NVRAM variable from the system's UEFI firmware boot manager corresponding to the result of the above grub-install command:
--> See also the section below titled, "Dual/multi-booting: Know what to expect ... and how to deal with GRUB."
Re-install GRUB2-EFI from Live DVD/USB flash drive
https://www.kubuntuforums.net/showth...l=1#post374017
**************************************************
**************************************************
SECTION 4: Use rEFInd alongside GRUB (Rod Smith is the rEFInd author/maintainer.)
A brief how-to on installing rEFInd
rEFInd creates its own NVRAM variable and sets it to boot priority #1
Why you should use rEFInd
Between GRUB and rEFInd, you should never have any problem booting your OSs. In fact, rEFInd will do that for you. rEFInd is a boot manager, not a boot loader; however, it can boot new Linux kernels (3.3 or later) directly using "EFI stub support" without the need for any other boot loader. rEFInd is easy and quick to set up. Do this after you install Kubuntu and get re-booted.
--> Here's a brief how-to on installing rEFInd:
https://www.kubuntuforums.net/showth...l=1#post372221
Rod Smith:
rEFInd: http://www.rodsbooks.com/efi-bootloaders/refind.html
rEFInd creates its own NVRAM variable and sets it to boot priority #1. Each time the computer is booted, rEFInd searches and displays bootable EFI apps and kernels, Windows, and GRUB EFI executables (files having the extension .efi). You will probably see it in the ESP like this: /boot/efi/EFI/refind/refind_x64.efi.
True, rEFInd duplicates some things that GRUB 2 does. But, I feel you are safer having rEFInd installed and working for you. Once installed, you can boot just about anything on any of your drives from the boot menu in rEFInd. It can even locate and boot your kernels stored all over the place in your OSs /boot directories and elsewhere. rEFInd is really handy if you change anything on your system, if you install any new OSs, or if you like to experiment. Even when GRUB is temporarily messed up, you can rely on rEFInd to get you booted into your target OS, almost always. Some advanced users at Kubuntu and elsewhere are using rEFInd and have completely purged GRUB from their system. As of 5/2015, I have both GRUB and rEFInd installed on my PC and use them both.
**************************************************
**************************************************
SECTION 5: A few basic things about how your UEFI firmware works to boot your computer
efibootmgr, gdisk
UEFI boot process
/boot/efi/EFI/ubuntu may contain these files ...
Technical NOTE about Secure Boot and the shim loader
gdisk is one of your main tools; sudo gdisk -l /dev/sdXY
Use gdisk to get GUIDs for your partitions: sudo gdisk /dev/sdX; UUIDs vs GUID--how to find both
Use ls -l /dev/disk/by-partuuid/ to get GUIDs for your partitions
efibootmgr is your main tool for interfacing with the computer's UEFI firmware boot manager
efibootmgr -- reading the output, BootOrder, Boot####
BootOrder is a NVRAM variable. Each Boot### is a NVRAM variable
\Backward slashes (UEFI), /forward slashes (Linux)
UUID versus GUID: how to keep it straight so you can identify your partitions
See your ESP -- 3 methods
How do NVRAM variables get created?
Boot managers
Changing the boot order BootOrder in UEFI firmware
Removing Boot entries (NVRAM variables) from your UEFI Boot list
Default boot loader, boot/efi/EFI/BOOT/BOOTX64.EFI
The UEFI boot process your computer uses in UEFI mode is this:
You turn on your computer, you then see the Power-On-Self-Test screen, called the POST screen. The UEFI firmware is started and initializes hardware and processes required 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 like a boot loader or another boot manager (e.g., rEFInd). It holds a BootOrder list of NVRAM variables, telling it in what order to try loading the UEFI boot loaders and applications that it stores. The UEFI firmware then tries to load the first UEFI application or boot loader listed in BootOrder. If that fails, it tries to load the second UEFI application or boot loader listed in BootOrder. It continues through the BootOrder list until it successfully launches a UEFI application or boot loader.
When you install Kubuntu, it calls setup scripts for GRUB (EFI), which call a key UEFI program efibootmgr which creates an NVRAM variable for your Kubuntu OS. This NVRAM variable is then stored in the UEFI firmware. GRUB also sets itself up in your OS under /boot/grub where it also stores its main configuration file grub.cfg. After installation finishes, The ESP (usually at sda1) will contain a folder for your Kubuntu called /EFI/ubuntu (mounted in your OS at /boot/efi).
For example, /boot/efi/EFI/ubuntu may contain these boot files for your Kubuntu: grub.cfg, grubx64.efi, shimx64.efi, and MokManager.efi.
--> This grub.cfg (in /boot/efi/EFI/ubuntu) is not the main configuration file for GRUB for your Kubuntu OS. It is brief and used only in the /EFI/ubuntu directory to point at another boot menu, like your main configuration GRUB file (in your Kubuntu OS root partition) at /boot/grub/grub.cfg. Here's an example of the /EFI/ubuntu/grub.cfg file:
This is written in GRUB-language. The UUID is that of the partition hd1,gpt2, which corresponds to the second hard drive, the second partition--partition 2; or 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).
--> grubx64.efi This is the main GRUB EFI executable--it is an 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
Technical NOTE about shim loader and Secure Boot:
For Secure Boot, the GRUB bootloader must be signed by a trusted source. This is where you'll see the shim loader come into play. The shimx64.efi is signed, and when it is properly called (in a Secure Boot setting), it will simply pass control to the regular GRUB executable, the grubx64.efi. When you turn Secure Boot off (in your computer's UEFI firmware setup menu), and you use commands such as grub-install with the option --no-uefi-secure-boot, you probably will not see this shim loader in your ESP EFI subdirectory.
- - - - - - - - - -
gdisk
gdisk is one of your main tools See: man gdisk; see the references cited above.
gdisk is a disk and partition utility for GUID Partition Table (GPT); it replaced fdisk which was used on MBR partition tables (EDIT: but newer versions of fdisk now also handle GPT). The author-maintainer of gdisk is Rod Smith. You can even use it to repair GPT structure. Run it on a disk or a partition as follows:
For example, sdXY may be sda, sdb, sda1, sdb2, etc.
It will tell you all about the disk/partitions and its GPT structure or if it detects a Legacy MBR, or if there's a problem.
GUIDs: Use gdisk to get GUIDs for your partitions: sudo gdisk /dev/sdX
https://en.wikipedia.org/wiki/GUID
Example: To find the GUIDs of partitions 1 and 2 on disk sda. (I'm replacing some of the irrelevant output with "..." to focus attention only on what we need for the GUIDs.) Press Enter after each entry you type:
GUIDs You can also use
ls -l /dev/disk/by-partuuid/
to get GUIDs for your partitions. Some versions of blkid also give the GUIDs.
UUIDs To get UUIDs use one of these commands:
sudo blkid
ls -l /dev/disk/by-uuid/
Some versions of blkid also give the GUIDs.
UUID versus GUID
Your GRUB configuration files show UUIDs. Your efibootmgr shows GUIDs. gdisk shows GUIDs, as does ls -l /dev/disk/by-partuuid. blkid shows UUIDs (though some versions of blkid also show GUIDs); or, ls -l /dev/disk/by-uuid.
As you mess with things, often you need to know which disk is being used for what, and maybe all you have to go on is a long string of hyphenated numbers. Just to be clear about this, the output of sudo efibootmgr -v shows some hard drive partitions with their GUIDs. Often you want to know which disk it is, so you can track down what's going on. To find the GUIDs, use sudo gdisk /dev/sdX or use ls -l /dev/disk/by-partuuid/ as explained above. To find UUIDs, use sudo blkid.
Think: GUID --> GPT only --> partition, and UUID --> filesystem; or the distinction offered by SteveRiley:
/dev/disk/by-partuuid shows the UUID assigned to the partition when it was created by a partitioning tool.
/dev/disk/by-uuid shows the UUID assigned to the file system when it was formatted.
UUID, GUID:
https://en.wikipedia.org/wiki/GUID, and https://en.wikipedia.org/wiki/UUID
https://wiki.archlinux.org/index.php..._device_naming
https://bbs.archlinux.org/viewtopic.php?id=165051
- - - - - - - - - -
- - - - - - - - - -
efibootmgr See man efibootmgr.
efibootmgr is your main tool for interfacing with the computer's UEFI firmware boot manager
Run it like this:
Understanding this output:
-- This is a printout of the NVRAM Boot variables stored in your computer's firmware. You can see why efibootmgr provides an interface to your firmware.
-- BootOrder shows the order in which the firmware will look for a bootable or EFI-executable file.
The UEFI boot manager will first try Boot0003 to see if it will boot something; if it fails, it tries Boot0000; then it tries Boot0002; and so on down the list until it gets something that will boot something. Boot0002 is BootCurrent, which means your computer is currently booting from Boot0002--the rEFInd boot manager.
-- Each entry in the BootOrder corresponds to a variable Boot####, like 0003 -> Boot0003. The asterisks, like Boot0004*, indicate which Boot variables are included in the booting list BootOrder (there may be Boot#### variables that are not included.)
-- The Boot#### variables are listed, along with information about each one.
-- Note the labels or names after each Boot####; e.g., ubuntu, Hard Drive, rEFInd Boot Manager, grub, CD/DVD, BIOS. Labels can be set by the user. In the section above, "GRUB 2 (for EFI)," we discussed the command:
sudo grub-install --efi-directory=DIR --bootloader-id=some_name
The some_name (that you can make up) is what appears as a label or name in the efibootmgr output.
-- Then there is a device; e.g., HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884) . HD is a drive (Hard Drive), 1 is partition 1, then an offset, a size, and finally a long GUID. Note that this is a GUID, not UUID. See the note above for keeping these straight.
-- Then there is path to a file, which we hope that file is a good EFI executable (like a boot loader or another boot manager). E.g., \EFI\ubuntu\shimx64.efi : UEFI uses backward slashes, that's just how it is, the convention here; when you use forward slashes, your UEFI firmware will translate them to backward slashes. You can see the topmost directory of the ESP /EFI, then the ubuntu subdirectory, then the EFI-executable shim 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 an OS for you).
-- \Backward slashes (in path names) are used in UEFI. /Forward slashes are used in Linux.
-- Note that Boot0002 is the rEFInd boot manager. It is listed 3rd in order, but you could boot to it directly, bypassing the BootOrder, if upon POST you enter your UEFI firmware setup menus, find a "boot override" menu, and select rEFInd to boot to (for just this one booting session). In turn, rEFInd will display a menu of EFI-executable choices for you to select from--boot loader(s), operating systems, kernels, GRUB, etc. Using efibootmgr, you can also change the BootOrder and put rEFInd wherever you want it.
-- BootOrder is a NVRAM variable. Each Boot#### is a NVRAM variable.
Seeing what's in your ESP -- Three methods
Command: tree
--> Use your file manager in Kubuntu, Dolphin
To see the contents of the sda1-ESP, from your Kubuntu OS, simple open Dolphin and look in /boot/efi/ (which is the directory where sda1 is mounted); then click EFI; then look in the subdirectories of EFI by clicking them.
--> Use the command line, listing files
... and you could continue this; e.g., cd ubuntu, then issue ls -l again to see what's in ubuntu.
--> Use the command: tree
tree will recursively expand directories as it lists them. See man tree. Example output:
Notes about the output
-- EFI is the topmost directory of the ESP (i.e., of the mounted ESP: /boot/efi/EFI)
-- grub (i.e., /boot/efi/EFI/grub) is a GRUB subdirectory put there by GRUB after issuing this grub-install command:
sudo grub-install --efi-directory=/boot/efi --bootloader-id=grub
-- grubTESTNOW is another GRUB subdirectory put there by GRUB after issuing this grub-install command:
sudo grub-install --efi-directory=/boot/efi --bootloader-id= grubTESTNOW
-- my_Backups_5-5-15 is a subdirectory I put there simply by using Dolphin to create it, then copying (by copy-paste or by drag-and-drop) the four files it contains from /boot/efi/EFI/ubuntu into /boot/efi/EFI/my_Backups_5-5-15.
-- refind is a subdirectory of EFI put there when rEFInd was installed.
-- ubuntu is a subdirectory of EFI put there when the Kubuntu OS was installed.
-- NOTE that there may be many grub.cfg's; each one may point to a different target, though.
(For more about the command
sudo grub-install --efi-directory=DIR --bootloader-id=some_name
see SECTION 3: GRUB 2 (for EFI), and see SECTION 6: Dual/multi-booting: Know what to expect ... and how to deal with GRUB.)
How do NVRAM variables get created?
NVRAM variables are created in many ways:
-- When you install an OS, the boot loader files get installed and then a new NVRAM gets created for the firmware.
-- When you install a boot manager, like rEFInd, an NVRAM variable will be created for it.
-- You can use the command sudo efibootmgr to create NVRAM variables (see man efibootmgr).
-- When you issue the grub-install command using the --bootloader-id=some_name option, an NVRAM variable is created.
-- If you make a back-up 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 having the same name as the name of the backup folder.
-- If you manually install a boot loader to a folder you create 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 having the same name as the name of the folder.
Boot managers The boot managers you have on your computer--like the UEFI firmware boot manager and rEFInd--will detect the NVRAM variables and list them as bootable options in their boot menus.
Changing the boot order BootOrder in UEFI firmware
When you issue ANY grub-install, it may change BootOrder!
You will have to adjust it. The BootOrder will change if you install an OS (it may be placed as #1). When you install rEFInd, it puts itself #1 in the boot order.
You can change the boot order in the firmware, the BootOrder NVRAM variable, in two ways:
--> Use your UEFI firmware setup menu to change the boot order.
Re-boot the PC, at the POST hit the correct key that opens your UEFI firmware setup, and find the boot menu where you can adjust the order of the Boot NVRAM variables (probably by dragging and dropping or some such way that will be clear to you when you see it).
--> Use efibootmgr to change the boot order.
Boot into any OS, open Konsole, run the command
man efibootmgr
and you'll see how to change the boot order (see the examples at the end). It is easy.
Suppose you run the command
sudo efibootmgr -v
to see your current boot order, and you get
BootOrder: 0000,0004,0002,0007
To change it to 0004,0000,0007,0002, run the command
sudo efibootmgr -o 4,0,7,2
Removing Boot entries (NVRAM variables) from your UEFI Boot list
(and from rEFInd)
To remove a Boot#### entry (i.e., a boot NVRAM variable) from the firmware memory, issue the efibootmgr command with the proper options--see man efibootmgr (see the examples at the end).
CAUTION: Be careful; do not cause your PC not to start properly! Do not delete anything you don't fully understand. If you DO render your PC unbootable (for example, it freezes at the POST screen), you may have to "clear CMOS" to fix it (and you will lose your NVRAM variable settings, as well as your other UEFI-BIOS configuration settings). See your motherboard manual.
Notes:
If you manually delete a subdirectory of /EFI, you may find that the UEFI firmware no longer displays a NVRAM variable for it.
If you manually delete a partition, you may find that the UEFI firmware no longer displays a NVRAM variable(s) for the bootable contents that were on the partition.
Your firmware may offer a delete or a disable option in its boot menu.
When you make any of these changes, you will find that rEFInd, when re-booting and rescanning your system, will no longer present as boot options the items you deleted manually.
Default boot loader
The default boot loader the UEFI firmware may look for is kept at
boot/efi/EFI/BOOT/BOOTX64.EFI
(for a 64-bit x86 system)
For example, if you want a boot loader to be the default, place it in boot/efi/EFI/BOOT/ and rename it BOOTX64.EFI. Some computers use EFI/Microsoft/BOOT/bootmgfw.efi as the default, and you would use it the same way you'd use EFI/BOOT/BOOTX64.EFI for making your boot loader the default. (See Rod Smith's website for more on this.)
**************************************************
**************************************************
SECTION 6: Dual/multi-booting: Know what to expect ... and how to deal with GRUB
Dual-booting Kubuntu -- Two things you should know
Install Kubuntu, then install another OS. What can happen--what will probably happen?
Installing Kubuntu sets up GRUB and populates an ESP in a certain way
How to "fix" your dual-boot setup
Re-install GRUB to fix your boot setup
Use Boot Repair
To help make dual-booting easier -->
Create separate EFI subdirectories for your (K)Ubuntu (derivative) OSs
ESPs, the "default" ESP at sda1, and creating and using more ESPs
Changing the boot order in firmware: you may have to do this quite often
If you get a grub prompt, grub>, don't panic
Dual-booting: How to Use Multiple ESPs
Dual-booting Kubuntu: A summary of your options
Windows? If you are dual-booting with Windows, I don't cover it. You need to consult the many posts on dual-booting Windows with Linux, including the Ubuntu guides. You can start here with SteveRiley's posts:
Dual-booting Kubuntu on a Windows machine
https://www.kubuntuforums.net/showthread.php?65253
Dual-boot with windows 8 - Not able to start Kubuntu (study this thread and SteveRiley's posts)
https://www.kubuntuforums.net/showth...-start-kubuntu
and search Kubuntu forums using the search tip (site:kubuntuforums.net) given at the start of this how-to following the list of references. Search Rod Smith's pages.
http://askubuntu.com/questions/22183...uefi-supported
https://wiki.archlinux.org/index.php...Arch_dual_boot
If you are dual-booting two or more Kubuntu versions or Kubuntu with other Linux OSs, continue reading.
Dual-booting Kubuntu
Two things you should know:
(1) If you're dual-booting, the GRUB from the last installed OS will take over the booting show. After installing the second OS, you may have to fix things the way you like them to be.
(2) The ESP: EFI subdirectories for various OSs.
All Ubuntu based distributions use the (same) directory name ubuntu in the ESP (/boot/efi/EFI/ubuntu), making it difficult to install more than one distribution based on Ubuntu (Kubuntu, Ubuntu, Mint, Xubuntu, Ubuntu Studio, etc.), or even different versions of Kubuntu on the same machine. You can install as many as you like; you just can't keep their boot files in separate folders on the ESP (like /boot/efi/EFI/ubuntu, /boot/efi/EFI/kubuntu, /boot/efi/EFI/mint, etc.). When you install one, it will over-write what is in /boot/efi/EFI/ubuntu with its own boot-loader files. However, other non-Ubuntu OSs WILL have their own subdirectory of /EFI/: /boot/efi/EFI/fedora, /boot/efi/EFI/microsoft, /boot/efi/EFI/suse, and so on. When you install a non-Ubuntu OS, it will only write its boot-loader files to its own subdirectory of the ESP, to /boot/efi/EFI/<its directory name>. It is not supposed to change any other OS's EFI subdirectory.
However ... You actually can make your own separate EFI subdirectories /boot/efi/EFI/<an_OS_name>. See the topic below titled Create separate EFI subdirectories for your (K)Ubuntu (derivative) OSs.
- - - - - - - - - -
Install Kubuntu, then install another OS. What can happen--what will probably happen?
Installing Kubuntu sets up GRUB and populates an ESP in a certain way
While installing Kubuntu, the Kubuntu installer installs the boot-loader GRUB to your computer. It will (very probably) simply go into the main ubuntu subdirectory of the mounted ESP (the ESP being partition sda1), namely to /boot/efi/EFI/ubuntu. To appreciate what can happen--what can go wrong--when you dual-boot, get a good picture of what one instance of an installed Kubuntu looks like on the computer:
-- Kubuntu is on a partition.
-- GRUB's main configuration file is /boot/grub/grub.cfg, located on the Kubuntu (root) partition.
-- You have an ESP on the HDD, it is mounted at /boot/efi (in your Kubuntu OS root directory), the top-level directory of the mounted ESP is EFI, and under that you have a special directory called ubuntu for the GRUB boot files for Kubuntu: /boot/efi/EFI/ubuntu. In that directory you may find booting and other files such as grub.cfg, grubx64.efi, shimx64.efi, and MokManager.efi. The grub.cfg here may be brief; it may simply point at your Kubuntu's GRUB's main configuration file /boot/grub/grub.cfg.
-- While all this has been going on, a new NVRAM variable for the ubuntu subdirectory (on the ESP) has been created and added to the firmware's boot files; and the UEFI firmware BootOrder shows "ubuntu" as Boot0000--first in boot order.
OK, that's the simple picture of having one Kubuntu OS and nothing else installed.
What can change if a second OS is installed?
If the second OS is an Ubuntu derivative (Kubuntu, Ubuntu, Mint, Xubuntu, Ubuntu Studio, etc.), its GRUB--in my experience--will over-write the contents of the existing ESP, the contents of the /boot/efi/EFI/ubuntu directory! The second OS will take over the booting. It will put its own executable grubx64.efi in there, and it will write its own brief grub.cfg file to point at its own partition's main GRUB boot file /boot/grub.grub.cfg. That main grub.cfg file (from the second OS) may include an entry for your existing Kubuntu OS; so if the computer boots, it will use the brief /EFI/ubuntu/grub.cfg file in the mounted ESP, to point at the boot menu from the second OS (its /boot/grub/grub.cfg), and that boot menu (in the second OS) may contain an option to boot into your original Kubuntu. Furthermore, as the second OS was installed, a new NVRAM variable for it (called, again, ubuntu) was created, placed in the firmware, and became part of the BootOrder; in fact, it probably became #1 in the BootOrder, called Boot0000. Your existing Kubuntu would get bumped down to second place in the BootOrder to Boot000x, where x >0 (hard telling how the exact numbering would go, but it would not be first).
If the second Linux OS, call it Linux1, is a non-Ubuntu derivative, hard telling what might happen, but probably you could expect the following: Linux1 will set up its own subdirectory in the same mounted ESP, say /boot/efi/EFI/linux1, and put its boot loader files in there, along with, possibly, some boot loader configuration file. If it uses a non-GRUB boot loader, I don't know what could happen. But if it is GRUB, there's a good possibility that it will take over the booting: A NVRAM Boot variable will be created for Linux1 (pointing at /boot/efi/EFI/linux1) and added to the firmware BootOrder, it will place itself first in BootOrder, your Kubuntu will be bumped to second. If you're lucky, the GRUB from Linux1 will add your Kubuntu to its GRUB boot file. So when the computer boots, it will boot to /boot/efi/EFI/linux1, then the file /boot/efi/EFI/linux1/grub.cfg will point at the main GRUB boot file for Linux1, i.e., /boot/grub/grub.cfg in Linux1, and it will be displayed, and there will be an entry in it for your Kubuntu, and then you can select that entry to boot into your Kubuntu.
Conclusion of these two scenarios
Upon installing a second OS, the GRUB from the second OS took over the booting.
Fact is, you can still boot into all your OSs. The only thing that changed is which GRUB installation is controlling the main, first booting. If you were to delete the second OS (write over it or re-format that partition, or delete the whole partition), then your ability to boot you first-installed OS would be affected: you probably could not boot into it (unless you also had rEFInd installed or if you install it now).
If this is OK with you, there's no problem.
If this is not OK with you, keep reading.
- - - - - - - - - -
How to "fix" your dual-boot setup.
--> Re-install GRUB to fix your boot setup.
If you have Kubuntu installed. Then you installed a second OS, Linux1 (especially where Linux1 is an Ubuntu-derivative), whose GRUB "took over" the booting (as described above in the two scenarios), then to fix this:
Simply boot into Kubuntu (where you want the GRUB to control the booting).
From there, at Konsole, re-install GRUB:
sudo grub-install
sudo update-grub # to regenerate a new boot/grub/grub.cfg file in Kubuntu
Afterwards, in the ESP, the /boot/efi/EFI/ubuntu/grub.cfg file will point at Kubuntu, where the final boot choices will be displayed from the /boot/grub/grub.cfg in Kubuntu. That's it, you're done. The NVRAM variable for ubuntu (your Kubuntu GRUB) will (probably) be set as #1 in UEFI BootOrder (if not, then change the order using efibootmgr).
--> Use efibootmgr to change the BootOrder if Linux1 is non-Ubuntu.
If Linux1 (that you installed after installing Kubuntu) is a non-Ubuntu OS, then it did not overwrite the contents of /boot/efi/EFI/ubuntu. But it did change the UEFI BootOrder and placed itself as #1. Thus, you can use efibootmgr to simple change the BootOrder--see Section 5 above; or see man efibootmgr, the examples at the end. HOWEVER, this method will not put Linux1 in your Kubuntu's GRUB's main configuration boot menu, the /boot/grub/grubcfg. To fix that, simply boot into Kubuntu and issue the command sudo update-grub.
And there's another way to handle things.
You may want to read the next topic -->
- - - - - - - - - -
To help make dual-booting easier -->
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
For now (May 2015), we are stuck with having just one ESP directory dedicated to Ubuntu and its derivatives: /boot/efi/EFI/ubuntu. But you can do this another way, you can have subdirectories for separate installations of GRUB for your different OSs. For example, you could set up /boot/efi/EFI/grubKubuntu1404, /boot/efi/EFI/grubKubuntu1504, /boot/efi/EFI/grubMintxy, and so on. Do this using the more general grub-install command.
If you want an entry in your ESP for the GRUB for a Linux OS called LinuxZ, boot into LinuxZ, make up a name you will recognize for the GRUB from LinuxZ, say grubLinuxZsdxy, and issue this command:
sudo grub-install --efi-directory=/boot/efi --bootloader-id=grubLinuxZsdxy
This will create, in the ESP, the subdirectory
/boot/efi/EFI/grubLinuxZsdxy
populated with GRUB boot-loader files from LinuxZ,
and it will create a new NVRAM variable in the firmware for it under the name grubLinuxZsdxy, which the firmware will recognize, efibootmgr will recognize, and rEFInd will recognize.
But ... keep reading before you try this -->
An easy fix for a problem dual-booting Ubuntu-based OSs (Kubuntu, Mint, etc.)
The method I just talked about, using
sudo grub-install --efi-directory=DIR --bootloader-id=some_name
will work to create and populate /boot/efi/EFI/some_name
for a Linux OS.
However, if the Linux OS is a (K)Ubuntu derivative (including, for example, Mint, Xubuntu, Lubuntu, another Kubuntu version or Ubuntu version, etc.), then there is another issue you must fix, and the fix is easy.
Here's the fix:
If LinuxZ is an Ubuntu OS derivative, first disable secure boot in your computer's UEFI firmware setup; boot into LinuxZ, then use this command to create /boot/efi/EFI/grubLinuxZsdxy:
More than one HDD: This will also work if you have more than one HDD and install LinuxZ to a partition on a HDD different from the HDD where you main Kubuntu OS is installed.
The reason for this:
The standard directory for (K)Ubuntu GRUB boot files is /boot/efi/EFI/ubuntu.
It contains grub.cfg, grubx64.efi, shimx64.efi, and maybe other files.
That grub.cfg contains a pointer to the "real" GRUB boot files that will do the booting; and they are the GRUB files located at /boot/grub/grub.cfg of the MOST RECENT (K)Ubuntu OS installed (or from which grub-install (with no options) was run).
The problem is that the pointer (referred to in the previous sentence) is hard-coded in the grubx64.efi file that is being called--EVEN if it is being called from /boot/efi/EFI/grubLinuxZsdxy. Again, note that the pointer in /boot/efi/EFI/ubuntu/grub.cfg corresponds to the MOST RECENT (K)Ubuntu OS installed (or from which grub-install (with no options) was run).
I know, it doesn't make sense, but that's the way it is.
What does this mean? Say you re-boot the computer, enter UEFI firmware setup menus, choose to boot from grubLinuxZsdxy, the GRUB boot menu you will see is the GRUB boot menu pointed to by this file: /boot/efi/EFI/ubuntu/grub.cfg, NOT from the GRUB boot menu in the OS LinuxZ (which would be the file in LinuxZ called /boot/grub/grub.cfg).
To fix this, you must create the EFI entry using the code given above with the --no-uefi-secure-boot option. Then, in UEFI firmware setup, when you select to boot grubLinuxZsdxy, you will see the GRUB boot menu from the root directory of LinuxZ (/boot/grub/grub.cfg).
This has to do with secure booting, and what the Ubuntu devs had to do to deal with secure booting (they, basically, had a choice to risk breaking secure booting or risk breaking multi-booting Ubuntu OSs; they chose the latter risk).
IMPORTANT: link, credit, and disclaimer:
The credit for the use of the option --no-uefi-secure-boot in the grub-install command goes to the author and article here, an article for advanced users:
lxgr's blog
Booting multiple Ubuntu versions with EFI
http://blog.lxgr.net/posts/2015/04/3...efi-multiboot/
My disclaimer is simply that this is all I know about it.
Along with that link, keep this one also in mind (answered by Rod Smith):
What is the difference between grubx64.efi and shimx64.efi?
http://askubuntu.com/questions/34236...64-and-shimx64
Technical Note (Advanced)
Illustrated by an example:
Suppose you have Kubuntu installed, it is your main OS, the file /boot/efi/EFI/ubuntu/grub.cfg points at the GRUB files in your Kubuntu root directory, /boot/grub/grub/cfg.
Then you install Mint. Mint's GRUB will over-write and take over /boot/efi/EFI/ubuntu that was populated by your Kubuntu's GRUB files. To fix that, you boot into Kubuntu and issue the basic command sudo grub-install, so, again, /boot/efi/EFI/ubuntu/ is populated by Kubuntu's GRUB files and /boot/efi/EFI/ubuntu/grub.cfg points at the GRUB files in your Kubuntu root directory.
Then to build a separate /EFI/ directory (and boot option) for your newly-installed Mint, using the special option --no-uefi-secure-boot, you boot into Mint and you issue the command:
Now you have created /boot/efi/EFI/Mint, and a new NVRAM variable is created for it in UEFI firmware (which a boot manager like rEFInd will also detect).
Look inside /EFI/Mint and you may (probably) find only one file, the GRUB executable grubx64.efi, and you will not see any grub.cfg that points at the Mint partition. However, the pointer to the Mint will be hard-coded in to the grubx64.efi file. So when you boot Mint, you will see the GRUB boot menu from Mint's root file system: /boot/grub/grub.cfg.
There's more! -->
If you want or need or think you have a creative use for more than one ESP, continue reading -->
- - - - - - - - - -
ESPs
The "default" ESP at sda1
and creating more ESPs
For many Kubuntu OS installations, sda1 will probably be the ESP, and it will be mounted at /boot/efi in the Kubuntu root filesystem. When you boot into your Kubuntu, you will (probably) notice that sda1 will be automatically mounted at /boot/efi. You can see an entry for it in /etc/fstab.
Technical note: df /boot/efi will show you the ESP your OS is using.
Most users will have just one ESP and it will usually be sda1 or sda2 (in some Windows systems). If you have more than one ESP, it is not necessarily true that "your ESP is sda1, mounted at /boot/efi." In fact, your ESP may be sda2 in some Windows systems. If you have multiple ESPs, they could be anywhere on your HDD, at any sdxy. That's where df /boot/efi comes in handy. When you boot into an OS, the ESP you are using for that OS will be mounted at /boot/efi. While you are booted into that OS, issue the command at Konsole df /boot/efi, to see what ESP partition is mounted for that OS.
ESPs -- how many?
You can have as many ESPs as you wish. But there is no guarantee that GRUB or the firmware will use them. Also, you can use just one ESP for your entire system (even with more than one HDD, even if dual-booting with Windows). If Windows is present, it was probably installed first, and thus it already set up an ESP, and that ESP can be shared by all the boot-loaders on your system (the GRUB2-EFI installer scripts will find that ESP and use it).
In fact, in my experiments:
-- upon installing Kubuntu, GRUB ignores all ESPs except for the sda1-ESP; even if it installs Kubuntu on a second hard drive sdb that is set up with an ESP as its first partition sdb1--GRUB will use the sda1-ESP; the Kubuntu installer will ignore a second ESP even if you specify the ESP as a target for GRUB installation (there is a drop-down list for you to use during the installation), even when the installer recognizes and labels that partition as an "esp" partition.
and about using a second ESP ...
-- even though GRUB might ignore a second or third ESP, after installing Kubuntu (or a Linux OS) on your PC, you can boot into it and issue the command
sudo grub-install --efi-directory=DIR --bootloader-id=some_name,
directing GRUB to be installed to DIR that is NOT the sda1-ESP, but instead is your second or third (mounted) ESP. The GRUB installed there will point to the OS you were in when you issued the grub-install command.
--> If you do this (install GRUB to an ESP that is not the sda1-ESP), when you re-boot your PC, GRUB menus may not display the option to boot using the GRUB you installed to the other ESP. BUT, the firmware does recognize it, it creates a NVRAM variable for it called some_name (the name you made up in the grub-install command), and you could enter your UEFI firmware setup and select that option to boot from; OR ... you could install and use the boot manager rEFInd and it would recognize and boot from this new boot option. If you do this sort of thing, remember to make up a name you will recognize for the some_name option; e.g., if you installed a Kubuntu OS in sdb2, you might use something like grubKubuntu1504sdb2 as the some_name in the command.
--> See also the section above titled, "GRUB 2 (for EFI)."
--> NEW: See the guide a few lines below titled "Dual-booting: How to Use Multiple ESPs" for a step-by-step sequence for installing two Linux OS, each using its own separate ESP.
Advanced:
Read Peter Jones, http://blog.uncooperative.org/blog/2...tem-partition/
- - - - - - - - - -
Changing the boot order in firmware: you may have to do this quite often
If you are dual-booting, or making any changes to your boot setups (installing or re-installing GRUB, creating ESPs, using the grub-install option --efi-directory=DIR), you may have to adjust the boot order. As explained in Section 5 above ("A few basic things about how your UEFI firmware works to boot your computer"), you can change the boot order in the firmware, the BootOrder NVRAM variable, in two ways:
Use your UEFI firmware setup menu to change the boot order; or
Use efibootmgr to change the boot order. See Section 5 or see man efibootmgr for an example.
- - - - - - - - - -
If you get a grub prompt, grub>, don't panic:
you can type halt to shut down the PC or type reboot to reboot and try again, trying something else, or entering your UEFI firmware setup.
- - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - -
Dual-booting: How to Use Multiple ESPs
To Do:
Install two Linux OSs, dual or multi-booting, where each of the two OSs has its GRUB2-EFI boot files in its own, separate ESP.
Solution:
Set up the ESPs and the OS partitions you need, using your partition editor.
Install each of the two new OSs, in sequence, with this procedure:
Turn off all ESPs except for the ESP you wish to make a dedicated ESP for the OS you are about to install now. Then do the installation using the Manual installation method. Turn on all ESPs and re-boot to test everything.
What you'll find here
Some tips, should-do's, and an example.
Partitioning, set boot flags, set labels
You can do this at the CLI or a GUI. I used GParted installed in my main Kubuntu (Muon: gparted).
To make an ESP in GParted, you can make it 512 MB, FAT32, and set the boot flag on it--that will set the partition type code for an ESP (which is EF00). (GParted: Partition > Manage flags) By "turn on" the ESP, I mean make sure the boot flag is set; by "turn off" the ESP, I mean to remove the boot flag (temporarily).
Tip: Set labels on the ESPs.
I set one label as Mintsda11 and the other label as K1504sda12. (The labels show up nicely in rEFInd and tell you where you are.) My existing ESP (before this experiment) is labeled ESP_sda1 and is my "main" ESP. (GParted: Partition > Label)
Example
Here's my setup after I did all the partitioning for this test; partitions 1-9 were existing; my main OS is Kubuntu 14.04 on sda2, and it uses the ESP on sda1; so I created 10-12 for this test (the ESP codes are in red):
Sequencing, tips, should-do's, using the above example
First we install Mint to sda11
Boot into you favorite OS, open Partition Editor gparted, remove the boot flags from the two ESPs sda1 and sda10 (for each one, highlight it, Partition > Manage Flags, remove the check mark for boot). It's a good idea to see how things are before the experiment, so run sudo efibootmgr -v and copy the output to a file and/or flash drive. Re-boot using the Mint installer DVD/USB. Select Manual for Installation type. Then on the Prepare Partition screen, check that the ESP-sda7 is listed. and check that sda1 and sda10 are NOT marked as ESP's. Install Mint to sda11 (highlight sda11, Change, use for ext4, mount /; where to put bootloader GRUB? Anywhere--doesn't matter, since for UEFI it will go into an ESP and there is only one ESP visible to the installer). Then, when installation is complete ...
Re-boot, you should be greeted by the GRUB boot menu from the newly installed Mint, and it should show all your other OSs. Select the new Mint to boot to. In Mint, use Partition Editor gparted to place boot flags on ESP's at sda1 and sda10, and confirm the boot flag is also on the ESP-sda7. (You may have to use the CLI or Synaptic to install gparted.) Then re-boot and check everything this way:
-- Upon re-booting, press the proper key to enter your computer's UEFI firmware setup and inspect the boot menu(s), try to make sense of it, locate what looks like your newly installed Mint OS. Exit your UEFI setup without changing or selecting anything. It will re-boot, and you will be greeted by the GRUB boot menu from the newly installed Mint OS, select that Mint and boot into it.
-- Examine and copy the UEFI BootOrder entries using "sudo efibootmgr -v." This is part of my output:
The "HD(7" indicates partition 7 contains the file \EFI\UBUNTU\SHIMX64.EFI. The string e0211180-3fb4-4014-8af9-a8112840a308 is the GUID for ESP sda7. You can find GUID's using this command: ls -l /dev/disk/by-partuuid .
-- Confirm the ESP-sda7 is mounted at /boot/efi of your Mint filesystem by issuing this command:
df /boot/efi. Example output:
-- Use Dolphin to access and look in /boot/efi/EFI/ubuntu to see the EFI GRUB files placed there. (You may have to open Dolphin as root by issuing this command: kdesudo dolphin). You may then see any of these: grub.cfg, grubx64.efi, shimx64.efi., MokManager64.efi .
Next, install Kubuntu 15.04 in sda12.
While you are in Mint (from previous re-boot), open Partition editor gparted and turn off boot flags for ESPs sda1 and sda7; leave the boot flag for the ESP-sda10 on. Now re-boot, repeating the sequences and tips used above for installing and checking Mint. Then Kubuntu 15.04 is installed. When you have the boot flags turned on for all three ESPs, sda1, sda7, and sda10, re-boot to Kubuntu 15.04, checking everything as you go, just as we did above. When you run a final "efibootmgr -v," check everything, inspecting that all three ESPs are listed (you will have to identify them using GUIDs, as above, using ls -l /dev/disk/by-partuuid), and checking the ESP-sda10 mounting in Kubuntu 15.04 with df /boot/efi.
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 boot your kernels without GRUB by the stub-loader method. In my example, rEFInd shows more and better detail than my UEFI firmware boot menus. It showed the three ESPs: sda1, sda7, and sda10 nicely labeled: ESP_sda1, Mintsda11, and K1504sda12. rEFInd was perfectly cool: all three ESPs clearly labeled; plus stub-loader boot options for all my kernels, the vmlinuz's; everything well organized and easy to read.
Using your UEFI firmware: It depends on your firmware
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 entires called "ubuntu." Sometimes, you just have to try them by trial-and-error, then remember or set their boot order using efibootmgr (see man efibootmgr) and then remember their order. You can fix this using labels, see:
Labels on UEFI boot entries: using efibootmgr -L
https://www.kubuntuforums.net/showth...229#post378229
I have previously tried some experiments dual-booting with more than one ESP, and it may not go so well, it can become complicated. You can NOT count on the K(U)buntu installer to get things right, to identify and use your ESPs the way you intend; and you can't count on GRUB2-EFI to get the way you want it. The solution above is clean, simple, and relatively speaking, somewhat elegant.
Thanks to Rod Smith for some tips (by email) to make this go smoothly.
Technical Note: df /boot/efi will show you the ESP your OS is using.
Most users will have just one ESP and it will usually be sda1 or sda2 (in some Windows systems). If you have more than one ESP, it is not necessarily true that "your ESP is sda1, mounted at /boot/efi." In fact, your ESP may be sda2 in some Windows systems. If you have multiple ESPs, they could be anywhere on your HDD, at any sdxy. That's where df /boot/efi comes in handy. When you boot into an OS, the ESP you are using for that OS will be mounted at /boot/efi. While you are booted into that OS, issue the command at Konsole
to see what ESP partition is mounted for that OS.
- - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - -
Dual-booting Kubuntu: A summary of your options
To Do: Dual boot two Linux OSs, call them LinuxX and LinuxY.
Assumption: Both OSs come with GRUB2-EFI as their bootloader.
You have many options for configuring your multi-booting setup, one disk or two, one ESP or multiple ESPs, using subdirectories of the EFI directory, and, perhaps, combinations of techniques. Most systems are simple: One HDD, one ESP (at sda1 or sda2). I've listed five techniques, "Solutions," you may consider, some simple, some advanced; and perhaps you can think of other tricks, as well.
A general principle
When you install an OS, a NVRAM variable gets created for it in the computer's UEFI firmware, and that OS is placed first in the UEFI boot order (i.e., BootOrder as shown by the short listing: sudo efibootmgr, or the detailed listing: sudo efibootmgr -v). The other existing OSs are bumped down in the BootOrder; and so, for example, the OS in the #1 position will now be #2, or second, in the BootOrder. Thus, if you do nothing special, when you re-boot your computer, by default the firmware will select to boot to the last OS you installed. What can you do "special" to make it work differently? Two things: (1) When you re-boot, press the magic key to access your computer's UEFI firmware boot menu(s) and select an OS to boot. Or, (2) Change the default boot behavior of the firmware by configuring it differently (and using efibootmgr -o).
Keep the Cheat Sheet handy--Section 7.
In particular, the following commands are very useful when doing this work:
To check the UEFI firmware boot order: sudo efibootmgr -v (or brief: sudo efibootmgr)
To see your GUIDs (listed in the efibootmgr output): ls -l /dev/disk/by-partuuid/
To see what your ESP is (the partition mounted at /boot/efi): df /boot/efi
To check your GPT: sudo gdisk -l /dev/sda
To see your ESP: tree /boot/efi
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 (which will then do the actual booting of your OSs).
Procedure:
rEFInd is a boot manager and a bootloader (using the stub-loader method of booting kernels directly).
It should (and it seems to) work every time.
Install LinuxX, re-boot and install LinuxY, boot into LinuxY and install rEFInd.
You're done.
You will now rely on rEFInd to get you booted into your OSs.
Default: When you boot your computer, you will see the rEFInd boot menu and choose which OS or which kernel you wish to boot (as well as other choices presented in the rEFInd menu).
(Note: If for some reason you installed rEFInd immediately after installing LinuxX, then after installing LinuxY, you would have to boot into one of them and change the boot order so rEFInd is first in the firmware BootOrder. To do this, see Section 5, Changing the boot order, BootOrder, in UEFI firmware: simply use "sudo efibootmgr -o" as explained in "man efibootmgr" (see the examples at the end of that man page).)
Solution #2: Do nothing special. Use GRUB2-EFI.
The focus here is on GRUB: We are letting the UEFI boot manager select the first OS listed in its boot menu to boot, then control is passed to the GRUB bootloader of that OS, which then boots the OS.
Procedure:
Install LinuxX, re-boot, install LinuxY. You're done if you want to be done.
Default: When you boot your computer, LinuxY will boot by default. (And from the GRUB boot menu of LinuxY, you will have a chance to select LinuxX to boot to.)
Modification: Changing which OS controls the booting.
At first, (the GRUB from) LinuxX controlled the booting; after installing LinuxY, the GRUB from LinuxY controlled the booting. If you prefer that (the GRUB from) LinuxX control the booting then:
re-boot into LinuxX and issue two commands:
sudo grub-install
sudo update-grub
Now you are done.
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 your UEFI firmware by pressing a special key to enter UEFI firmware boot menu(s) when your computer boots up, and then selecting an OS to boot.
Your computer's UEFI firmware is also a boot manager, and you can try to use it. How well it performs depends on the firmware design. Find out what key to press when you re-boot to enter your computer's UEFI firmware setup and boot menus. Technical note: The UEFI firmware boot manager is not a bootloader. Thus, it can't boot your Linux OS directly, but it can boot your Linux OS by booting to the GRUB bootloader of that OS. The firmware boot manager can also start another boot manager, like rEFInd, that you select from the UEFI firmware boot menu. Thus, this solution #3--Try to use your UEFI firmware--is similar to Solution #2--booting by GRUB. But solution #3 also includes the option of you manually entering UEFI firmware (each time your computer boots) to select an OS or a boot manager to boot to, rather than simply letting it default to a GRUB boot of the first entry listed in BootOrder.
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. When you re-boot, enter your UEFI setup, access its boot menu(s), see the "ubuntu" entry, select it, you will then boot LinuxY, and its GRUB boot menu should show LinuxX as a boot option, and so you can choose which to boot. If you do nothing, just let the computer boot up, your UEFI firmware will boot LinuxY (which then will show you its GRUB boot menu with LinuxX listed.). And so you are done. (Technical note: Now, /boot/efi/EFI/ubuntu will contain the GRUB boot files from LinuxY.)
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, then do this: Boot into LinuxX and issue two commands: sudo grub-install and sudo update-grub. And you are done. (Technical note: Now, /boot/efi/EFI/ubuntu will contain the GRUB boot files from LinuxX.)
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 a 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").
Re-boot, enter your UEFI firmware boot menu(s), and select the OS you want to boot to.
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.
You're done ...
Unless you don't wish to be done -->
Note: 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 the command: sudo update-grub. And so, then, you are done here ...
Unless ... you want LinuxX to boot by default. In that case, boot into LinuxX and issue two commands: 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: Set up separate subdirectories of EFI for LinuxX and LinuxY
The focus here is on forcing the UEFI firmware to treat multiple Ubuntu derivatives individually; this is done by creating separate EFI subdirectories /boot/efi/EFI/<some_ubuntu_distribution>.
Note: If LinuxX and LinuxY are not both Ubuntu derivatives, there is no problem, no need to set up separate EFI subdirectories (because there will already be separate subdirectories: /boot/efi/EFI/<some_name for LinuxX> and /boot/efi/EFI/<some_name for LinuxY>).
This is discussed above (in this Section 6), under the heading "Create separate EFI subdirectories for your (K)Ubuntu (derivative) OSs."
If both LinuxX and LinuxY are Ubuntu derivatives, proceed as explained there; that is:
Boot into each of them. In each, issue the command
sudo grub-install --efi-directory=/boot/efi --bootloader-id=<some_name> --no-uefi-secure-boot
Secure boot must be disabled in your firmware for this to work.
For LinuxX, you might choose LinuxX for <some_name>; or LinuxXsdxy, where sdxy is the root partition of LinuxX. For LinuxY, choose a name you'll recognize.
Note: Whatever labels you choose, you will be able to recognize them in the UEFI firmware boot menu(s) and in the boot menu shown to you by rEFInd (if rEFInd is installed).
You have now created two EFI subdirectories: /boot/efi/EFI/<some_name for LinuxX> and /boot/efi/EFI/<some_name for LinuxY>. (Recall that your ESP is mounted at /boot/efi, and we assume the same ESP contains the boot files for both LinuxX and LinuxY).
Let's assume you did this for LinuxX first, then for LinuxY.
To make sure that each is listed on the other's GRUB boot menu (if that is what you want), boot into each and issue the command sudo update-grub. (This is not required, it is optional: you can always use your firmware menus to choose either LinuxX or LinuxY to boot into.)
Default:
When you boot your computer, the GRUB boot menu from LinuxY should appear (since LinuxY was installed last), giving you a GRUB menu and the chance to boot LinuxY or LinuxX.
Or,
When you boot your computer, you may choose to press the magic key to enter the UEFI firmware boot menu(s), where you can choose <some_name you set for LinuxX> or <some_name you set for LinuxY>. (And then, you should be shown a GRUB boot menu from that choice.)
You're done ...
Unless ... you want to change the BootOrder so LinuxX boots first:
Do this as we always do it: use efibootmgr -o as explained in the "man efibootmgr" (see the examples at the end of that man page).
You're done ...
Unless ... you want to use rEFInd:
Boot into LinuxX (or LinuxY), install rEFInd. (And so rEFInd was installed last--after LinuxX and after LinuxY, and thus, will appear first in UEFI boot order BootOrder.)
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.
And so then, you are done.
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 wish to do it for design, or for convenience, or for your own reasons or 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 then 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 named /EFI/ubuntu, and then give you a bunch of indistinguishable "ubuntu" choices in its UEFI boot menu.
This was discussed in detail, above in this Section 6 under the heading "Dual-booting: How to Use Multiple ESPs." In general terms, the solution 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 new OSs, in sequence, with this procedure:
Turn off all ESPs except for the ESP you wish to make a dedicated ESP for the OS you are about to install now. Then do the installation using the Manual installation method. Turn on all ESPs and re-boot to test everything.
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 or may not see nice, complete GRUB boot menus unless you have made certain of it by booting into each of your OSs and issuing the command sudo update-grub).
In UEFI firmware: Each OS will be set up in its own ESP under a subdirectory that is clearly named, like /boot/efi/EFI/<some_name that you'll recognize>. And you will see that name (<some_name that you'll recognize>) in the UEFI firmware boot menu; for example, it may be ubuntu, debian, suse, etc. However, for an Ubuntu OS, it is set up in its ESP in a subdirectory called /boot/efi/EFI/ubuntu, and in the UEFI firmware boot menu, you will only see it as "ubuntu." If you have a bunch of Ubuntu OSs installed like this on your computer, you may see a bunch of UEFI firmware boot entries each named "ubuntu," which can be confusing: by trial and error, you can see which entries boot which of your Ubuntu OSs.
You can fix this using labels:
NEW: See Labels on UEFI Boot Entries -- using efibootmgr -L
https://www.kubuntuforums.net/showthread.php?43221-GRUB-2-A-Guide-for-Users&p=378229#post378229
--> rEFInd: If, however, you have rEFInd installed, and you place it first in firmware BootOrder (using sudo efibootmgr -o as described in man efibootmgr), then upon booting, it will show you a boot menu on which the ESPs you created will be clearly identified by their labels (i.e., the labels you made up when you created the ESPs). For example, rEFInd may list as a boot option "/EFI/ubuntu/grubx64.efi from MintTest" and you would recognize that ESP that is labeled MintTest (for Mint, obviously). You can use more descriptive labels for your ESPs, like MintTestsdxy to indicate the partition that instance of Mint is on. Also note that rEFInd will detect and list all the kernels on your computer for you to see and boot.
**************************************************
**************************************************
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, is /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 use CLI: 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 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;
-- /etc/fstab:
-- 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 (also shimx64.efi, grub.cfg, MokManager.efi)
Re-install 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 will overwrite previous /EFI/ubuntu contents. Other non-Ubuntu OSs have their own /EFI subdirectory.
(3) The last-installed OS or 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:
#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:
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:
(This registers in UEFI firmware a NVRAM variable with Label L.)
To delete the old boot variable (having the old label):
--> 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.
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[
Reviewed, edited for improvements, additions:
7-14-15; 8-23-15, 9-25-15, 9-27-15
UEFI Simplified -- a quicker version
This is intended to be a quicker version (more to-the-point) of the present tutorial (where you are at now): "UEFI for Kubuntu--simplified. And ... some dual-booting tips for Kubuntu."
If you prefer this more-to-the-point version, see:
https://www.kubuntuforums.net/showth...l=1#post379977
///////////////////////////////////////
The Simplified Formula ;-)
Accept the new technology of firmware/partition table: UEFI+GPT replaces BIOS+MBR.
Fix in your mind a picture of the GPT and UEFI setup.
Install your Kubuntu properly in UEFI mode.
(To prepare for that, optionally, you can do the partitioning of your HDD first.)
Accept, for now, that most users will use GRUB 2 (for EFI) as a boot loader.
Use rEFInd alongside GRUB.
Know a few basic things about how your UEFI firmware works to boot your computer.
Know what to expect when you set up dual/multi-booting, and how to fix it.
Have some tools, facts, tips, and references handy: a Cheat Sheet.
That's it. What follows is an expanded version of this simple formula, along with all the details you'll probably ever need to manage your UEFI booting in K(U)buntu.
- - - - - - - - - -
Starting again from the top ...Oops, I left out something from that title. Toss is one or two of these emoticons: ;-) and a sense of humor to boot (pun intended). This is a work-in-progress, and it is based on only my experience experimenting, only with Kubuntu on ASUS firmware, and a lot of reading. I even broke my machine once (had to reset the CMOS and lost all my firmware settings); also encountered the dreadful "failed: sdxy does not look like an ESP" (yep, it was accidentally an ext4 instead of FAT32--not thinking).
This should apply to Kubuntu, Ubuntu derivatives, and probably is in line with general Debian.
Bear in mind, with the new-ish UEFI+GPT, three things determine your experience: the firmware from the computer manufacturer (which may be quirky or buggy), how GRUB2-EFI handles UEFI, and the K(U)buntu installer.
Terms: The new way: (U)EFI+GPT. The old way: BIOS/CSM/legacy-mode+MBR.
**************************************************
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
References, if you had to pick just a few, and let's put them up front:
GPT, UEFI -- Study Guide, with many references, post #109 in this thread:
https://www.kubuntuforums.net/showth...l=1#post346604
GPT: http://en.wikipedia.org/wiki/GUID_Partition_Table
UEFI, ESP: Managing EFI Boot Loaders for Linux: Basic Principles:
http://www.rodsbooks.com/efi-bootloa...rinciples.html
ESP: http://en.wikipedia.org/wiki/EFI_System_partition#Linux
Using rEFInd: http://www.rodsbooks.com/efi-bootloaders/refind.html
Brief how-to on installing rEFInd:
https://www.kubuntuforums.net/showth...l=1#post372221
UEFI: https://help.ubuntu.com/community/UEFI
UEFI: https://wiki.archlinux.org/index.php/UEFI
GRUB: https://wiki.archlinux.org/index.php/GRUB
Boot Repair (to fix GRUB): https://help.ubuntu.com/community/Boot-Repair
Debian wiki: https://wiki.debian.org/GrubEFIReins...otProcess\b%29
The shimx64.efi loader: http://askubuntu.com/questions/34236...64-and-shimx64
--> Advanced: You really should read the next three articles, for facts and for some perspective:
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/
lxgr's blog
Booting multiple Ubuntu versions with EFI
http://blog.lxgr.net/posts/2015/04/3...efi-multiboot/
Rod Smith web pages: Very important, perhaps at this time THE source. Look over the topics at rodsbooks.com, he's covered just about everything with added references. He's the creator of rEFInd and gdisk, and a good author.
gdisk tutorial: http://www.rodsbooks.com/gdisk/
rEFInd: http://www.rodsbooks.com/efi-bootloaders/refind.html
To search Kubuntu forums and rodsbooks using google, write your search this way, for example:
site:kubuntuforums.net dual-booting +UEFI +Windows
site: gives you results from only the site you type; "quotes" gives you exactly what you put in quotes; + will make sure that word is there; - (minus sign) will omit the word.
To search the rodsbooks.com using google, e.g., search for GPT on his pages:
site:rodsbooks.com GPT
Post #132
Re-install GRUB2 from Live DVD/USB flash drive
https://www.kubuntuforums.net/showth...l=1#post374017
**************************************************
**************************************************
TABLE of CONTENTS
(sort of: to give you an idea what's in here; you may also want to skip to the cheat sheet in Section 7 to get an overview of things; it is a suggested cheat sheet--you may wish to modify it)
SECTION 1: UEFI+GPT to replace BIOS+MBR
UEFI+GPT to replace BIOS+MBR; the ESP is important for UEFI implementation
GPT layout
ESP -- EFI System Partition, specifications
BIOS Boot partition
SECTION 2: Install your Kubuntu properly in UEFI mode
Install your Kubuntu properly in UEFI mode: Use the 64-bit version of Kubuntu
(Optional: Do the partitioning of your HDD first.)
How to access your firmware setup
How to run the Kubuntu installer
Partitioning
Are you booted in EFI mode? Do you have a GPT?
SECTION 3: GRUB 2 (for EFI)
Find your GRUB files, executable, and version
Main GRUB configuration file
Installing GRUB, re-installing GRUB
grub-install, update-grub
An important GRUB-EFI command:
sudo grub-install --efi-directory=DIR --bootloader-id=some_name
The parameter --no-uefi-secure-boot
Re-install GRUB2-EFI from Live DVD/USB
SECTION 4: Use rEFInd alongside GRUB (Rod Smith is the rEFInd author/maintainer)
A brief how-to on installing rEFInd
rEFInd creates its own NVRAM variable and sets it to boot priority #1
Why you should use rEFInd
SECTION 5: A few basic things about how your UEFI firmware works to boot your computer
efibootmgr, gdisk
UEFI boot process
For example, /boot/efi/EFI/ubuntu may contain these files ...
gdisk is one of your main tools; sudo gdisk -l /dev/sdXY
Use gdisk to get GUIDs for your partitions: sudo gdisk /dev/sdX; UUIDs vs GUID--how to find both
Use ls -l /dev/disk/by-partuuid/ to get GUIDs for your partitions
UUID versus GUID: how to keep it straight so you can identify your partitions
efibootmgr is your main tool for interfacing with the computer's UEFI firmware boot manager
efibootmgr -- reading the output, BootOrder, Boot####
BootOrder is a NVRAM variable. Each Boot#### is a NVRAM variable
\Backward slashes (UEFI), /forward slashes (Linux)
See your ESP -- 3 methods; the tree command
How do NVRAM variables get created?
Boot managers
Changing the boot order, BootOrder, in UEFI firmware
Removing Boot entries (NVRAM variables) from your UEFI Boot list
Default boot loader, boot/efi/EFI/BOOT/BOOTX64.EFI
SECTION 6: Dual/multi-booting: Know what to expect ... and how to deal with GRUB
Dual-booting Kubuntu -- Two things you should know
Install Kubuntu, then install another OS. What can happen--what will probably happen?
Installing Kubuntu sets up GRUB and populates an ESP in a certain way
How to "fix" your dual-boot setup
Re-install GRUB to fix your boot setup
Use Boot Repair
To help make dual-booting easier -->
Create separate EFI subdirectories for your (K)Ubuntu (derivative) OSs
ESPs, the "default" ESP at sda1, and creating and using more ESPs
Changing the boot order in firmware: you may have to do this quite often
If you get a grub prompt, grub>, don't panic
Dual-booting: How to Use Multiple ESPs
Dual-booting Kubuntu: A summary of your options
NEW, 9-27-15:
SECTION 7: Cheat Sheet
Tools, facts, tips, summary
**************************************************
**************************************************
SECTION 1: UEFI+GPT to replace BIOS+MBR
UEFI+GPT to replace BIOS+MBR; the ESP is important for UEFI implementation
GPT layout
ESP -- EFI System Partition, specifications
BIOS Boot partition
UEFI = Unified Extensible Firmware Interface, a software interface between an operating system and platform firmware. UEFI is intended to replace BIOS. GPT is a subset of the UEFI specifications, poised to replace the MBR setup. UEFI+GPT is intended to replace BIOS+MBR.
A UEFI implementation uses a special partition called the EFI System Partition, or ESP.
GPT -- GUID Partition Table
Get a good start on this, get a good picture in your mind. In quick summary, the structure of the GPT setup is as follows (and for a graphic, see https://en.wikipedia.org/wiki/GUID_Partition_Table ) :
Protective MBR -- 512 bytes (used for BIOS/CSM/legacy-mode+MBR compatibility)
Partition Table Header -- 512 bytes
The Partition Table entries (128 of them are available in this setup, each has 128 bytes).
The actual partitions (those listed in the Partition Table entries)
The end-of-disk backup to the Partition Table
The end-of-disk backup to the Partition Table Header called the Secondary Partition Table Header
All GPT partitions are at same the level of a primary partition, though not called primary; GPT does away with the primary vs logical partition distinction.
-- and see what follows below for the ESP and the Bios Boot Partition --
ESP -- EFI System Partition
A UEFI implementation uses a special partition of GPT called the EFI System Partition, or ESP.
Specs of the ESP and what you need to know about it: try to make it sda1
The ESP contains all EFI bootloaders for all the OSs installed. 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).
-- Size: 100-512 MiB (recommended: 200 MiB minimum; preferred: 512 MiB).
-- FAT32 file system format
-- "boot flag": In GParted or libparted-based tools, set the "boot" flag on the ESP (although in UEFI that does not mean bootable, per se.) 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 filesystem).
-- /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.
-- Default bootloader is /EFI/BOOT/bootx64.efi, mounted as: /boot/efi/EFI/BOOT/bootx64.efi
-- Example of a directory made up to hold the rEFInd boot manager: /boot/efi/EFI/refind/
-- Filename extension to indicate an EFI boot loader (an EFI executable, a binary file): .efi
Notes
-- sda1-ESP may be automatically mounted in your Kubuntu.
When you boot into a Kubuntu (or maybe any Linux OS), the sda1-ESP will (probably) be automatically, already mounted at /boot/efi -- You can see it using Dolphin. It should also be listed in /etc/fstab. Note that 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 that specific OS (or, unlikely, to support a command you may have issued with sudo grub-install --efi-directory=DIR). For more on this technical point, see Section 6, Dual/Multi-booting, the topics toward the end of that section titled Dual-booting: How to Use Multiple ESPs and Dual-booting Kubuntu: Options, Summary.
-- Backup of your ESP
You can make a backup of your ESP any way you want. But one thing I do that's quick and easy is to simply back up the contents of /boot/efi/EFI/ubuntu that was created for the Kubuntu OS I just installed. You can do this at the command line. Or do it in Dolphin:
Open Dolphin as root: kdesudo dolphin; Click on root (at the left; or enter / in the location window). Click on /boot, then /efi, then EFI; Make a new directory (folder) by right-clicking, and call it what ever you wish, like my_backup_ubuntu_files; Open the ubuntu folder /boot/efi/EFI/ubuntu. Then copy-paste or drag-and-drop (as a COPY only--do NOT MOVE them!) the contents (usually four files like grub.cfg.grubx64.efi, shimx64.efi, MokManager.efi) into the new backup directory you just created.
BIOS Boot Partition: Booting in Legacy-CSM mode
--> It is probably desirable NOT to have to mess with this! Stick with straight UEFI+GPT, not with a legacy boot setup. You can skip this topic if you wish.
When using GPT with BIOS, Stage 1 of GRUB, called boot.img will fit into the first 446 bytes of the protective MBR, but you need room for the second stage of GRUB, the core.img. With the GPT layout, there is no gap, no room, for core.img (in GPT, the Partition Table Header starts immediately after the 512-byte MBR). Thus, if you wish to boot GPT using BIOS or you wish to boot UEFI in BIOS/CSM/legacy-mode, you need a BIOS Boot Partition for the core.img of GRUB 2.
Flag: Using the graphical GParted, create the BIOS Boot Partition, and set the flag on it as: bios_grub; using gdisk, it is of type EF02.
Size: Minimum size is 32 KiB, but most people are using 1 MiB (which also serves certain optimum partition-alignment goals--which, btw, these goals are also served by modern partitioning tools since about 2010).
Filesystem: The BIOS Boot Partition does not have a filesystem on it; it only holds raw binary code (the core.img stage of GRUB).
How-to: See the references (Ubuntu and Rod Smith).
**************************************************
**************************************************
SECTION 2: Install your Kubuntu properly in UEFI mode
Install your Kubuntu properly in UEFI mode: Use the 64-bit version of Kubuntu
(Optional: Do the partitioning of your HDD first)
How to access your firmware setup
How to run the Kubuntu installer
Partitioning: Do you want to do this beforehand?
Are you booted in EFI mode? Do you have a GPT?
How to access your firmware setup, boot menus: Most modern computers after about 2011 have UEFI firmware. Check your PC manual to find out how to access your computer's UEFI setup menus (by pressing a special key at the POST (Power-On-Self-Test) screen). Explore the UEFI setup menus, find where the boot menu is. If there is a setting to choose the boot mode (UEFI or BIOS), choose UEFI; also, you do not want CSM (disable it or set to "Auto"); disable Fast Boot; either disable Secure Boot or set it to "Other operating system" (not Windows--unless you have Windows and want to enable it).
Boot menus: You may have a main (permanent (until you change it)) boot menu and a second boot menu, often called the "boot override" menu, that allows you to select an OS (or other UEFI application) to boot for this one time. The UEFI firmware acts as a boot manager.
How to run the Kubuntu installer: You want to boot your Kubuntu install medium in UEFI mode (not in legacy BIOS/CSM mode). You must have the 64-bit version of Kubuntu (not 32-bit). Then, put your Kubuntu install medium in the PC (the CD/DVD drive, or USB port). Re-boot. At the proper POST time press the correct key to enter your computer's UEFI setup menus. From a boot menu (like the boot override menu), select the entry corresponding to the UEFI mode of your install medium. In that boot menu, you may see more than one entry for your install device, like two or three entries for your DVD, or multiple entries for your USB flash drive. Select an entry that has UEFI or EFI in its description. And proceed as you normally do, installing Kubuntu.
Partitioning: It may be good practice to partition your HDD before installing OSs. If you are not comfortable with that, skip this. For GUI, use GParted live media (CD or USB flash drive). Doing so is safer, more reliable, maybe faster, than allowing the Kubuntu installer to do the partitioning during the installation of Kubuntu. Also, this makes it a separate, controllable step, thus easier to troubleshoot if there's a problem. Format the HDD for UEFI+GPT, and for Kubuntu OS /, /home, and swap.
Example: Use the 64-bit version of GParted (live media or installed in Kubuntu). Boot your computer with GParted. First select Device: Create partition table: GPT. Then partition the GPT as follows.
sda1: to be the ESP: Starting at "the 1 megabyte" (at 1 MiB), create a FAT32 partition, 512 MB, with flag "boot." Then create the OS partitions: sda2 = /, sda3 = /home (using ext4 for sda2 & sda3), and sda4 = swap. Exit GParted. Then run the Kubuntu installer DVD, selecting the Manual method when prompted. No need to let the installer reformat any partitions except for the swap (if it so indicates).
Are you booted in EFI mode?
Check that you have /sys/firmware/efi/. You can see the boot variables in /sys/firmware/efi/vars/
https://wiki.archlinux.org/index.php...ess_under_UEFI
Do you have a GPT or MBR? At Konsole, run sudo fdisk -l . Did you get errors? Does it say you have a GPT? Run sudo gdisk -l /dev/sda: does it say you have a GPT?
**************************************************
**************************************************
SECTION 3: GRUB 2 (for EFI)
Find your GRUB files, executable, and version
Main GRUB configuration file
Installing GRUB, re-installing GRUB
grub-install, update-grub
An important GRUB-EFI command:
sudo grub-install --efi-directory=DIR --bootloader-id=some_name
The parameter --no-uefi-secure-boot
Re-install GRUB2-EFI from Live DVD/USB
Most users will use GRUB 2 (for EFI) as a boot loader. See Rod Smith's site for your options. See next topic for rEFInd (highly recommended). Importantly, see the section below on dual/multi-booting. My point here is that although GRUB is not ideal, it does work, you can work with it, it is a mainstream choice, and we are trying here to keep things simple (although most experts would say that GRUB is anything but simple). Most people will use it, so we need to talk about it. The Kubuntu installer will install GRUB for you, GRUB scripts will set it up and configure it.
Find your GRUB files, executable, and version
Example:The version of grub I'm using (as of 5/15) is Version 2, 2.02~beta-9ubuntu1.1;and it is called grub-efi-amd64;the executable is grubx64.efi; in the Kubuntu OS root partition, GRUB files are located at /boot/grub including its main configuration file grub.cfg.
You can get this information from:
-- Muon Package Manager (enter grub in search and you will see the installed packages for GRUB, highlight one then click the Technical Details tab at the bottom);
-- grub-install -V (run this command at Konsole);
-- see your main GRUB system files at /usr/lib/grub and the text at /usr/lib/grub/x86_64-efi-signed. Versions x86_64-efi are for UEFI; i386-pc are for BIOS.
Main GRUB configuration file
-- Upon booting, you will see a GRUB boot menu of choices to boot to. This menu comes from the main GRUB configuration file grub.cfg in the directory /boot/grub.
-- If you have just one OS installed, you may not see a boot menu when you boot you computer; to see it, hold down the Shift key immediately after the POST until it appears.
Installing GRUB, re-installing GRUB
When you install Kubuntu, the main GRUB system files are installed in /usr/lib/grub. GRUB uses those files to set up and configure itself for your OS. In addition, for UEFI, GRUB places the executable file grubx64.efi in a subdirectory of the ESP, in the directory /boot/efi/EFI (you recall that the ESP, usually sda1, is mounted in Kubuntu at /boot/efi). Thus, in a typical installation, you can find the GRUB boot loader files in the subdirectory /boot/efi/EFI/ubuntu (note, as of May 2015, there is no subdirectory named kubuntu; ubuntu is used for Ubuntu and its derivatives). For example, a typical installation might contain a brief configuration file /EFI/ubuntu/grub.cfg (this is not the main configuration file discussed above at /boot/grub/grub.cfg) and the executable file /EFI/ubuntu/grubx64.efi. Also, for a UEFI installation, a NVRAM (Boot) variable is created for the firmware, and it points at the GRUB executable in the /EFI/ubuntu. And, as part of your Kubuntu installation, GRUB writes its main Kubuntu configuration file grub.cfg and places it in the /boot/grub directory; it also sets up configuration files /etc/grub.d and settings from /etc/default/grub, both of these are used to generate the main /boot/grub/grub.cfg file.
--> For understanding UEFI, the NVRAM boot variable called ubuntu (pointing at the ESP directory /boot/efi/EFI/ubuntu) is important.
If you need to purge and re-install the main grub system files in /usr/lib/grub, you can do that using the Boot Repair utility, or by using Muon Package Manager, or by using the command line (e.g., Konsole). We will not talk about that here; however, I just told you all you need to know to do it yourself. It is rare that you would have to do so.
If the main GRUB system files are OK, and the installation of Kubuntu went OK, you may still want to re-install GRUB to /boot/grub and to /EFI/ubuntu on the ESP. You may want to do this to fix things or to adjust how your computer dual-boots your Kubuntu OS along with other OSs.
--> This is a key point for the section below titled "Dual/multi-booting: Know what to expect ... and how to deal with GRUB."
Case 1 A simple, "default" re-installation of GRUB: grub-install command
The command is simply
sudo grub-install
(For our purposes in dual-booting below, the grub-install command is issued at, say, Konsole, while you are booted into a Kubuntu OS. However, the grub-install command can also be issued from a live rescue CD or USB flash drive, perhaps by chroot-ing into your OS on the HDD/SSD. You must issue the command as root, using sudo or some other way, perhaps using sudo su to get a root prompt.)
This command will use the main GRUB system files to install or re-install GRUB files and its executable grubx64.efi to /boot/efi/EFI/ubuntu; and to place GRUB files (e.g., modules) in /boot/grub/x86_64-efi.
--> It will also place a NVRAM variable in the computer's UEFI firmware boot manager.
Note, however, that grub-install does not re-build a new main configuration boot file in your Kubuntu OS, the /boot/grub/grub.cfg. You must do that after running sudo grub-install by the command:
sudo update-grub
--> Two key points about the simple grub-install command:
-- In UEFI, it assumes (by default) that your ESP is the partition sda1 mounted at /boot/efi; thus it will modify the contents of the /boot/efi/EFI/ubuntu directory in the mounted sda1 partition.
-- Also, unlike the older GRUB Legacy or the GRUB 2 for BIOS, the GRUB 2 for EFI does not take an [install device] as an argument. For example, in UEFI, the command
sudo grub-install /dev/sda
makes no sense; it will run, but the device /dev/sda will be ignored. The installation is not done to any disk MBR or to any partition boot sector (like the MBR of /dev/sda or the partition boot sector of /dev/sda1). Instead, it is always made to a directory in the mounted ESP; i.e., to /boot/efi/EFI/ubuntu.
NOTE: Updating /boot/grub/grub.cfg
Ubuntu and Debian systems use sudo update-grub.
Other systems may use grub2-mkconfig -o /boot/grub/grub.cfg, or grub-mkconfig -o /boot/grub/grub.cfg
Case 2 A more general--and useful--grub-install command (see Technical Notes below)
Code:
sudo grub-install --efi-directory=[U]DIR[/U] --bootloader-id=some_name [--no-uefi-secure-boot]
some_name is, well, some name you made up that you will recognize later if you see it listed in a GRUB boot menu or in the UEFI firmware BootOrder listing.
Example:
sudo grub-install --efi-directory=/boot/efi --bootloader-id=grubsda2
This command would install GRUB files to your sda1-ESP (mounted at /boot/efi) under the topmost directory /EFI to a subdirectory you named grubsda2; thus to: /boot/efi/EFI/grubsda2. The --efi-directory=/boot/efi tells GRUB that your ESP is mounted in your Kubuntu filesystem at /boot/efi.
Example:
sudo grub-install --efi-directory=/mnt/sdb2Test1 --bootloader-id=grubsdb2Test1
Example of how this might be used: Let's say you installed another instance of (K)Ubuntu in sdb2. And you created an ESP (or another ESP) at sdb1--you mounted it in your sdb2 Kubuntu OS at /mnt/sdb2Test1, and you wish to install GRUB (EFI) files to the subdirectory grubsdb2Test1, thus to the directory: /mnt/sdb2Test1/EFI/grubsdb2Test1. "Test1" may distinguish this installation from other testing installations you are doing. You can make up any name you wish for some_name as long as it makes sense to you when you see it listed again in a boot listing.
--> This will be most useful in Section 6 below "Dual/multi-booting: Know what to expect ... and how to deal with GRUB."
the parameter --no-uefi-secure-boot
--> If you are installing multiple Ubuntu-derivative OSs (versions of K(U)buntu, Mint, Xubuntu, etc.), you also may need the parameter --no-uefi-secure-boot in your grub-install command. See Create separate EFI subdirectories for your (K)Ubuntu (derivative) OSs in Section 6 below "Dual/multi-booting: Know what to expect ... and how to deal with GRUB."
Technical Notes
-- "--target=" The full command should read
Code:
sudo grub-install --target=x86_64-efi --efi-directory=[U]DIR[/U] --bootloader-id=some_name [--no-uefi-secure-boot]
-- /EFI reminder: You'll notice you see the directory /EFI in the paths. Recall that /EFI is the top-most directory of the mounted ESP (the EFI System Partition). GRUB knows this, and assumes it to be so.
-- /boot/grub/grub.cfg: Remember to update the main GRUB configuration file /boot/grub/grub.cfg using sudo update-grub.
-- Firmware: The grub-install command will also, automatically, place a NVRAM variable in the computer's UEFI firmware boot manager (if you did not use the option --no-nvram) The program efibootmgr can also be used to create such boot variables to be placed in the UEFI firmware. We will talk about this later. See man efibootmgr.
Here's a sample of what a boot listing would look like for this example. We'll discuss this subject later in more detail. This is a printout of a Boot NVRAM variable from the system's UEFI firmware boot manager corresponding to the result of the above grub-install command:
Code:
[FONT=monospace]Boot0006* grubsdb2Test1 HD(1,800,fa000,153f8a04-f24e-4275-b33c-b316343ad613)File(\EFI\grubsdb2\shimx64.efi)[/FONT]
Re-install GRUB2-EFI from Live DVD/USB flash drive
https://www.kubuntuforums.net/showth...l=1#post374017
**************************************************
**************************************************
SECTION 4: Use rEFInd alongside GRUB (Rod Smith is the rEFInd author/maintainer.)
A brief how-to on installing rEFInd
rEFInd creates its own NVRAM variable and sets it to boot priority #1
Why you should use rEFInd
Between GRUB and rEFInd, you should never have any problem booting your OSs. In fact, rEFInd will do that for you. rEFInd is a boot manager, not a boot loader; however, it can boot new Linux kernels (3.3 or later) directly using "EFI stub support" without the need for any other boot loader. rEFInd is easy and quick to set up. Do this after you install Kubuntu and get re-booted.
--> Here's a brief how-to on installing rEFInd:
https://www.kubuntuforums.net/showth...l=1#post372221
Rod Smith:
rEFInd: http://www.rodsbooks.com/efi-bootloaders/refind.html
rEFInd creates its own NVRAM variable and sets it to boot priority #1. Each time the computer is booted, rEFInd searches and displays bootable EFI apps and kernels, Windows, and GRUB EFI executables (files having the extension .efi). You will probably see it in the ESP like this: /boot/efi/EFI/refind/refind_x64.efi.
True, rEFInd duplicates some things that GRUB 2 does. But, I feel you are safer having rEFInd installed and working for you. Once installed, you can boot just about anything on any of your drives from the boot menu in rEFInd. It can even locate and boot your kernels stored all over the place in your OSs /boot directories and elsewhere. rEFInd is really handy if you change anything on your system, if you install any new OSs, or if you like to experiment. Even when GRUB is temporarily messed up, you can rely on rEFInd to get you booted into your target OS, almost always. Some advanced users at Kubuntu and elsewhere are using rEFInd and have completely purged GRUB from their system. As of 5/2015, I have both GRUB and rEFInd installed on my PC and use them both.
**************************************************
**************************************************
SECTION 5: A few basic things about how your UEFI firmware works to boot your computer
efibootmgr, gdisk
UEFI boot process
/boot/efi/EFI/ubuntu may contain these files ...
Technical NOTE about Secure Boot and the shim loader
gdisk is one of your main tools; sudo gdisk -l /dev/sdXY
Use gdisk to get GUIDs for your partitions: sudo gdisk /dev/sdX; UUIDs vs GUID--how to find both
Use ls -l /dev/disk/by-partuuid/ to get GUIDs for your partitions
efibootmgr is your main tool for interfacing with the computer's UEFI firmware boot manager
efibootmgr -- reading the output, BootOrder, Boot####
BootOrder is a NVRAM variable. Each Boot### is a NVRAM variable
\Backward slashes (UEFI), /forward slashes (Linux)
UUID versus GUID: how to keep it straight so you can identify your partitions
See your ESP -- 3 methods
How do NVRAM variables get created?
Boot managers
Changing the boot order BootOrder in UEFI firmware
Removing Boot entries (NVRAM variables) from your UEFI Boot list
Default boot loader, boot/efi/EFI/BOOT/BOOTX64.EFI
The UEFI boot process your computer uses in UEFI mode is this:
You turn on your computer, you then see the Power-On-Self-Test screen, called the POST screen. The UEFI firmware is started and initializes hardware and processes required 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 like a boot loader or another boot manager (e.g., rEFInd). It holds a BootOrder list of NVRAM variables, telling it in what order to try loading the UEFI boot loaders and applications that it stores. The UEFI firmware then tries to load the first UEFI application or boot loader listed in BootOrder. If that fails, it tries to load the second UEFI application or boot loader listed in BootOrder. It continues through the BootOrder list until it successfully launches a UEFI application or boot loader.
When you install Kubuntu, it calls setup scripts for GRUB (EFI), which call a key UEFI program efibootmgr which creates an NVRAM variable for your Kubuntu OS. This NVRAM variable is then stored in the UEFI firmware. GRUB also sets itself up in your OS under /boot/grub where it also stores its main configuration file grub.cfg. After installation finishes, The ESP (usually at sda1) will contain a folder for your Kubuntu called /EFI/ubuntu (mounted in your OS at /boot/efi).
For example, /boot/efi/EFI/ubuntu may contain these boot files for your Kubuntu: grub.cfg, grubx64.efi, shimx64.efi, and MokManager.efi.
--> This grub.cfg (in /boot/efi/EFI/ubuntu) is not the main configuration file for GRUB for your Kubuntu OS. It is brief and used only in the /EFI/ubuntu directory to point at another boot menu, like your main configuration GRUB file (in your Kubuntu OS root partition) at /boot/grub/grub.cfg. Here's an example of the /EFI/ubuntu/grub.cfg file:
Code:
search.fs_uuid b65ee9d2-6dd4-4e66-bfe5-16bf0a551bd4 root hd1,gpt2 set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg
--> grubx64.efi This is the main GRUB EFI executable--it is an 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
Technical NOTE about shim loader and Secure Boot:
For Secure Boot, the GRUB bootloader must be signed by a trusted source. This is where you'll see the shim loader come into play. The shimx64.efi is signed, and when it is properly called (in a Secure Boot setting), it will simply pass control to the regular GRUB executable, the grubx64.efi. When you turn Secure Boot off (in your computer's UEFI firmware setup menu), and you use commands such as grub-install with the option --no-uefi-secure-boot, you probably will not see this shim loader in your ESP EFI subdirectory.
- - - - - - - - - -
gdisk
gdisk is one of your main tools See: man gdisk; see the references cited above.
gdisk is a disk and partition utility for GUID Partition Table (GPT); it replaced fdisk which was used on MBR partition tables (EDIT: but newer versions of fdisk now also handle GPT). The author-maintainer of gdisk is Rod Smith. You can even use it to repair GPT structure. Run it on a disk or a partition as follows:
Code:
[B]sudo gdisk -l /dev/sdXY[/B]
It will tell you all about the disk/partitions and its GPT structure or if it detects a Legacy MBR, or if there's a problem.
GUIDs: Use gdisk to get GUIDs for your partitions: sudo gdisk /dev/sdX
https://en.wikipedia.org/wiki/GUID
Example: To find the GUIDs of partitions 1 and 2 on disk sda. (I'm replacing some of the irrelevant output with "..." to focus attention only on what we need for the GUIDs.) Press Enter after each entry you type:
Code:
[B]sudo gdisk /dev/sda[/B] [COLOR=#ff3333]<-- This is your command[/COLOR][COLOR=#ff3333], [/COLOR][COLOR=#ff3333]press Enter, [/COLOR][COLOR=#ff3333]the output follows:[/COLOR]
GPT fdisk (gdisk) version 0.8.8
Partition table scan:
...
Found valid GPT with protective MBR; using GPT.
Command (? for help): i [COLOR=#ff3333]<--[/COLOR] [COLOR=#ff3333]type "i" for information[/COLOR]
Partition number (1-7): 1 [COLOR=#ff3333]<--[/COLOR] [COLOR=#ff3333]type 1 for partition 1[/COLOR]
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
Partition unique GUID: 0B3A3E36-B506-4F4A-9811-8549F1B5D884 [COLOR=#ff3333]<--This is [/COLOR][COLOR=#ff3333]the GUID[/COLOR][COLOR=#ff3333].[/COLOR]
...
Command (? for help): i [COLOR=#ff3333]<--[/COLOR] [COLOR=#ff3333]type "i" for information[/COLOR]
Partition number (1-7): 2 [COLOR=#ff3333]<--[/COLOR] [COLOR=#ff3333]type [/COLOR][COLOR=#ff3333]2[/COLOR][COLOR=#ff3333] for partition [/COLOR][COLOR=#ff3333]2[/COLOR]
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 300DBC2C-E8A7-41E7-8F55-86490EFA4347 [COLOR=#ff3333]<--This is [/COLOR][COLOR=#ff3333]the GUID[/COLOR][COLOR=#ff3333].[/COLOR]
...
Command (? for help): q [COLOR=#ff3333]<-- type q for quit, press Enter[/COLOR]
GUIDs You can also use
ls -l /dev/disk/by-partuuid/
to get GUIDs for your partitions. Some versions of blkid also give the GUIDs.
UUIDs To get UUIDs use one of these commands:
sudo blkid
ls -l /dev/disk/by-uuid/
Some versions of blkid also give the GUIDs.
UUID versus GUID
Your GRUB configuration files show UUIDs. Your efibootmgr shows GUIDs. gdisk shows GUIDs, as does ls -l /dev/disk/by-partuuid. blkid shows UUIDs (though some versions of blkid also show GUIDs); or, ls -l /dev/disk/by-uuid.
As you mess with things, often you need to know which disk is being used for what, and maybe all you have to go on is a long string of hyphenated numbers. Just to be clear about this, the output of sudo efibootmgr -v shows some hard drive partitions with their GUIDs. Often you want to know which disk it is, so you can track down what's going on. To find the GUIDs, use sudo gdisk /dev/sdX or use ls -l /dev/disk/by-partuuid/ as explained above. To find UUIDs, use sudo blkid.
Think: GUID --> GPT only --> partition, and UUID --> filesystem; or the distinction offered by SteveRiley:
/dev/disk/by-partuuid shows the UUID assigned to the partition when it was created by a partitioning tool.
/dev/disk/by-uuid shows the UUID assigned to the file system when it was formatted.
UUID, GUID:
https://en.wikipedia.org/wiki/GUID, and https://en.wikipedia.org/wiki/UUID
https://wiki.archlinux.org/index.php..._device_naming
https://bbs.archlinux.org/viewtopic.php?id=165051
- - - - - - - - - -
- - - - - - - - - -
efibootmgr See man efibootmgr.
efibootmgr is your main tool for interfacing with the computer's UEFI firmware boot manager
efibootmgr is a userspace application used to modify the Intel Extensible Firmware Interface (EFI) Boot Manager. This application can create and destroy boot entries, change the boot order, change the next running boot option, and more.
Code:
[COLOR=#000000][FONT=monospace][B]sudo efibootmgr -v [/B][/FONT][/COLOR][COLOR=#ff3333][FONT=monospace]<-- This is your main command[/FONT][/COLOR][FONT=monospace] [/FONT] [FONT=monospace]BootCurrent: 0002 Timeout: 1 seconds BootOrder: [/FONT][FONT=Courier 10 Pitch][B]0003,[/B][/FONT][FONT=Courier 10 Pitch][B]0000,0002,0004,0001[/B][/FONT][FONT=monospace] Boot0000* ubuntu HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File(\EFI\ub untu\shimx64.efi) Boot0001* Hard Drive BIOS(2,0,00)..GO..NO........O.W.D.C. .W.D.5.0.0.3.A.Z.E.X.-.0.0. M.K.2.A.0.................>..Gd-.;.A..MQ..L. . . . .W. .-.D.C.W.3.C.5.F.F.X.2.6.F.K..... ...BO [/FONT][FONT=monospace]Boot0002*[/FONT][FONT=monospace] rEFInd Boot Manager HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884)File (\EFI\REFIND\REFIND_X64.EFI) Boot0003* grub HD(7,21c0a800,fa000,e0211180-3fb4-4014-8af9-a8112840a308)File(\EFI\grub\ shimx64.efi) Boot0004* 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[/FONT]
-- This is a printout of the NVRAM Boot variables stored in your computer's firmware. You can see why efibootmgr provides an interface to your firmware.
-- BootOrder shows the order in which the firmware will look for a bootable or EFI-executable file.
The UEFI boot manager will first try Boot0003 to see if it will boot something; if it fails, it tries Boot0000; then it tries Boot0002; and so on down the list until it gets something that will boot something. Boot0002 is BootCurrent, which means your computer is currently booting from Boot0002--the rEFInd boot manager.
-- Each entry in the BootOrder corresponds to a variable Boot####, like 0003 -> Boot0003. The asterisks, like Boot0004*, indicate which Boot variables are included in the booting list BootOrder (there may be Boot#### variables that are not included.)
-- The Boot#### variables are listed, along with information about each one.
-- Note the labels or names after each Boot####; e.g., ubuntu, Hard Drive, rEFInd Boot Manager, grub, CD/DVD, BIOS. Labels can be set by the user. In the section above, "GRUB 2 (for EFI)," we discussed the command:
sudo grub-install --efi-directory=DIR --bootloader-id=some_name
The some_name (that you can make up) is what appears as a label or name in the efibootmgr output.
-- Then there is a device; e.g., HD(1,800,fa000,0b3a3e36-b506-4f4a-9811-8549f1b5d884) . HD is a drive (Hard Drive), 1 is partition 1, then an offset, a size, and finally a long GUID. Note that this is a GUID, not UUID. See the note above for keeping these straight.
-- Then there is path to a file, which we hope that file is a good EFI executable (like a boot loader or another boot manager). E.g., \EFI\ubuntu\shimx64.efi : UEFI uses backward slashes, that's just how it is, the convention here; when you use forward slashes, your UEFI firmware will translate them to backward slashes. You can see the topmost directory of the ESP /EFI, then the ubuntu subdirectory, then the EFI-executable shim 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 an OS for you).
-- \Backward slashes (in path names) are used in UEFI. /Forward slashes are used in Linux.
-- Note that Boot0002 is the rEFInd boot manager. It is listed 3rd in order, but you could boot to it directly, bypassing the BootOrder, if upon POST you enter your UEFI firmware setup menus, find a "boot override" menu, and select rEFInd to boot to (for just this one booting session). In turn, rEFInd will display a menu of EFI-executable choices for you to select from--boot loader(s), operating systems, kernels, GRUB, etc. Using efibootmgr, you can also change the BootOrder and put rEFInd wherever you want it.
-- BootOrder is a NVRAM variable. Each Boot#### is a NVRAM variable.
Seeing what's in your ESP -- Three methods
Command: tree
--> Use your file manager in Kubuntu, Dolphin
To see the contents of the sda1-ESP, from your Kubuntu OS, simple open Dolphin and look in /boot/efi/ (which is the directory where sda1 is mounted); then click EFI; then look in the subdirectories of EFI by clicking them.
--> Use the command line, listing files
Code:
mike@mike-desktop:/$cd /boot/efi [B]<-- change directory into the /boot/efi directory[/B] mike@mike-desktop:/boot/efi$ ls -l [B]<-- list files there[/B] total 4 drwxr-xr-x 8 root root 4096 May 24 06:53 [COLOR=#ff3333]EFI[/COLOR] mike@mike-desktop:/boot/efi$ cd EFI [B]<-- change directory into EFI[/B] mike@mike-desktop:/boot/efi/EFI$ ls -l [B]<-- list files there[/B] total 24 drwxr-xr-x 2 root root 4096 May 20 02:06 grub drwxr-xr-x 2 root root 4096 May 24 06:53 grubTESTNOW drwxr-xr-x 2 root root 4096 May 5 05:07 my_Backups_5-5-15 drwxr-xr-x 6 root root 4096 May 13 13:46 refind drwxr-xr-x 2 root root 4096 May 9 17:32 tools drwxr-xr-x 2 root root 4096 May 21 12:12 ubuntu
--> Use the command: tree
tree will recursively expand directories as it lists them. See man tree. Example output:
Code:
mike@mike-desktop:~$ [B]cd /boot/efi[/B] [COLOR=#ff3333]<-- You must first change directories to the ESP mount point directory[/COLOR][COLOR=#ff3333];
--> or, [/COLOR][COLOR=#ff3333][B]you could simply issue the command as tree /boot/efi[/B][/COLOR][COLOR=#ff3333].[/COLOR]
mike@mike-desktop:/boot/efi$ tree [B]<-- To shorten the output, several entries have been deleted:[/B]
.
└── EFI
├── grub
│ ├── grub.cfg
│ ├── grubx64.efi
│ ├── MokManager.efi
│ └── shimx64.efi
├── grubTESTNOW
│ ├── grub.cfg
│ ├── grubx64.efi
│ ├── MokManager.efi
│ └── shimx64.efi
├── my_Backups_5-5-15
│ ├── grub.cfg
│ ├── grubx64.efi
│ ├── MokManager.efi
│ └── shimx64.efi
├── refind
│ ├── drivers_x64
│ │ └── ext4_x64.efi
│ ├── icons
│ │ ├── arrow_left.png
│ │ ├── arrow_right.png
│ │ ├── boot_linux.png
│ │ ├── boot_win.png
│ │ ├── func_about.png
│ │ ├
│ │ ├── os_kubuntu.png
│ │ ├
│ │ ├── os_linuxmint.png
│ │ ├
│ │ ├── os_opensuse.png
│ │ ├
│ │ ├── os_refind.png
│ │ ├
│ │ ├── os_ubuntu.png
│ │ ├
│ │ ├── os_win8.png
│ │ ├── os_win.png
│ │ ├── os_xubuntu.png
│ │ ├
│ │ └── vol_optical.png
│ ├── icons-backup
│ │ ├── arrow_left.png
│ │ ├── arrow_right.png
│ │ ├── boot_linux.png
│ │ ├
│ │ └── vol_optical.png
│ ├── keys
│ │ ├── altlinux.cer
│ │ ├─
│ │ └── SLES-UEFI-CA-Certificate.cer
│ ├── refind.conf
│ ├── refind.conf-sample
│ └── refind_x64.efi
├── tools
└── ubuntu
├── grub.cfg
├── grubx64.efi
├── MokManager.efi
└── shimx64.efi
11 directories, 153 files
Notes about the output
-- EFI is the topmost directory of the ESP (i.e., of the mounted ESP: /boot/efi/EFI)
-- grub (i.e., /boot/efi/EFI/grub) is a GRUB subdirectory put there by GRUB after issuing this grub-install command:
sudo grub-install --efi-directory=/boot/efi --bootloader-id=grub
-- grubTESTNOW is another GRUB subdirectory put there by GRUB after issuing this grub-install command:
sudo grub-install --efi-directory=/boot/efi --bootloader-id= grubTESTNOW
-- my_Backups_5-5-15 is a subdirectory I put there simply by using Dolphin to create it, then copying (by copy-paste or by drag-and-drop) the four files it contains from /boot/efi/EFI/ubuntu into /boot/efi/EFI/my_Backups_5-5-15.
-- refind is a subdirectory of EFI put there when rEFInd was installed.
-- ubuntu is a subdirectory of EFI put there when the Kubuntu OS was installed.
-- NOTE that there may be many grub.cfg's; each one may point to a different target, though.
(For more about the command
sudo grub-install --efi-directory=DIR --bootloader-id=some_name
see SECTION 3: GRUB 2 (for EFI), and see SECTION 6: Dual/multi-booting: Know what to expect ... and how to deal with GRUB.)
How do NVRAM variables get created?
NVRAM variables are created in many ways:
-- When you install an OS, the boot loader files get installed and then a new NVRAM gets created for the firmware.
-- When you install a boot manager, like rEFInd, an NVRAM variable will be created for it.
-- You can use the command sudo efibootmgr to create NVRAM variables (see man efibootmgr).
-- When you issue the grub-install command using the --bootloader-id=some_name option, an NVRAM variable is created.
-- If you make a back-up 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 having the same name as the name of the backup folder.
-- If you manually install a boot loader to a folder you create 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 having the same name as the name of the folder.
Boot managers The boot managers you have on your computer--like the UEFI firmware boot manager and rEFInd--will detect the NVRAM variables and list them as bootable options in their boot menus.
Changing the boot order BootOrder in UEFI firmware
When you issue ANY grub-install, it may change BootOrder!
You will have to adjust it. The BootOrder will change if you install an OS (it may be placed as #1). When you install rEFInd, it puts itself #1 in the boot order.
You can change the boot order in the firmware, the BootOrder NVRAM variable, in two ways:
--> Use your UEFI firmware setup menu to change the boot order.
Re-boot the PC, at the POST hit the correct key that opens your UEFI firmware setup, and find the boot menu where you can adjust the order of the Boot NVRAM variables (probably by dragging and dropping or some such way that will be clear to you when you see it).
--> Use efibootmgr to change the boot order.
Boot into any OS, open Konsole, run the command
man efibootmgr
and you'll see how to change the boot order (see the examples at the end). It is easy.
Suppose you run the command
sudo efibootmgr -v
to see your current boot order, and you get
BootOrder: 0000,0004,0002,0007
To change it to 0004,0000,0007,0002, run the command
sudo efibootmgr -o 4,0,7,2
Removing Boot entries (NVRAM variables) from your UEFI Boot list
(and from rEFInd)
To remove a Boot#### entry (i.e., a boot NVRAM variable) from the firmware memory, issue the efibootmgr command with the proper options--see man efibootmgr (see the examples at the end).
CAUTION: Be careful; do not cause your PC not to start properly! Do not delete anything you don't fully understand. If you DO render your PC unbootable (for example, it freezes at the POST screen), you may have to "clear CMOS" to fix it (and you will lose your NVRAM variable settings, as well as your other UEFI-BIOS configuration settings). See your motherboard manual.
Notes:
If you manually delete a subdirectory of /EFI, you may find that the UEFI firmware no longer displays a NVRAM variable for it.
If you manually delete a partition, you may find that the UEFI firmware no longer displays a NVRAM variable(s) for the bootable contents that were on the partition.
Your firmware may offer a delete or a disable option in its boot menu.
When you make any of these changes, you will find that rEFInd, when re-booting and rescanning your system, will no longer present as boot options the items you deleted manually.
Default boot loader
The default boot loader the UEFI firmware may look for is kept at
boot/efi/EFI/BOOT/BOOTX64.EFI
(for a 64-bit x86 system)
For example, if you want a boot loader to be the default, place it in boot/efi/EFI/BOOT/ and rename it BOOTX64.EFI. Some computers use EFI/Microsoft/BOOT/bootmgfw.efi as the default, and you would use it the same way you'd use EFI/BOOT/BOOTX64.EFI for making your boot loader the default. (See Rod Smith's website for more on this.)
**************************************************
**************************************************
SECTION 6: Dual/multi-booting: Know what to expect ... and how to deal with GRUB
Dual-booting Kubuntu -- Two things you should know
Install Kubuntu, then install another OS. What can happen--what will probably happen?
Installing Kubuntu sets up GRUB and populates an ESP in a certain way
How to "fix" your dual-boot setup
Re-install GRUB to fix your boot setup
Use Boot Repair
To help make dual-booting easier -->
Create separate EFI subdirectories for your (K)Ubuntu (derivative) OSs
ESPs, the "default" ESP at sda1, and creating and using more ESPs
Changing the boot order in firmware: you may have to do this quite often
If you get a grub prompt, grub>, don't panic
Dual-booting: How to Use Multiple ESPs
Dual-booting Kubuntu: A summary of your options
Windows? If you are dual-booting with Windows, I don't cover it. You need to consult the many posts on dual-booting Windows with Linux, including the Ubuntu guides. You can start here with SteveRiley's posts:
Dual-booting Kubuntu on a Windows machine
https://www.kubuntuforums.net/showthread.php?65253
Dual-boot with windows 8 - Not able to start Kubuntu (study this thread and SteveRiley's posts)
https://www.kubuntuforums.net/showth...-start-kubuntu
and search Kubuntu forums using the search tip (site:kubuntuforums.net) given at the start of this how-to following the list of references. Search Rod Smith's pages.
http://askubuntu.com/questions/22183...uefi-supported
https://wiki.archlinux.org/index.php...Arch_dual_boot
If you are dual-booting two or more Kubuntu versions or Kubuntu with other Linux OSs, continue reading.
Dual-booting Kubuntu
Two things you should know:
(1) If you're dual-booting, the GRUB from the last installed OS will take over the booting show. After installing the second OS, you may have to fix things the way you like them to be.
(2) The ESP: EFI subdirectories for various OSs.
All Ubuntu based distributions use the (same) directory name ubuntu in the ESP (/boot/efi/EFI/ubuntu), making it difficult to install more than one distribution based on Ubuntu (Kubuntu, Ubuntu, Mint, Xubuntu, Ubuntu Studio, etc.), or even different versions of Kubuntu on the same machine. You can install as many as you like; you just can't keep their boot files in separate folders on the ESP (like /boot/efi/EFI/ubuntu, /boot/efi/EFI/kubuntu, /boot/efi/EFI/mint, etc.). When you install one, it will over-write what is in /boot/efi/EFI/ubuntu with its own boot-loader files. However, other non-Ubuntu OSs WILL have their own subdirectory of /EFI/: /boot/efi/EFI/fedora, /boot/efi/EFI/microsoft, /boot/efi/EFI/suse, and so on. When you install a non-Ubuntu OS, it will only write its boot-loader files to its own subdirectory of the ESP, to /boot/efi/EFI/<its directory name>. It is not supposed to change any other OS's EFI subdirectory.
However ... You actually can make your own separate EFI subdirectories /boot/efi/EFI/<an_OS_name>. See the topic below titled Create separate EFI subdirectories for your (K)Ubuntu (derivative) OSs.
- - - - - - - - - -
Install Kubuntu, then install another OS. What can happen--what will probably happen?
Installing Kubuntu sets up GRUB and populates an ESP in a certain way
While installing Kubuntu, the Kubuntu installer installs the boot-loader GRUB to your computer. It will (very probably) simply go into the main ubuntu subdirectory of the mounted ESP (the ESP being partition sda1), namely to /boot/efi/EFI/ubuntu. To appreciate what can happen--what can go wrong--when you dual-boot, get a good picture of what one instance of an installed Kubuntu looks like on the computer:
-- Kubuntu is on a partition.
-- GRUB's main configuration file is /boot/grub/grub.cfg, located on the Kubuntu (root) partition.
-- You have an ESP on the HDD, it is mounted at /boot/efi (in your Kubuntu OS root directory), the top-level directory of the mounted ESP is EFI, and under that you have a special directory called ubuntu for the GRUB boot files for Kubuntu: /boot/efi/EFI/ubuntu. In that directory you may find booting and other files such as grub.cfg, grubx64.efi, shimx64.efi, and MokManager.efi. The grub.cfg here may be brief; it may simply point at your Kubuntu's GRUB's main configuration file /boot/grub/grub.cfg.
-- While all this has been going on, a new NVRAM variable for the ubuntu subdirectory (on the ESP) has been created and added to the firmware's boot files; and the UEFI firmware BootOrder shows "ubuntu" as Boot0000--first in boot order.
OK, that's the simple picture of having one Kubuntu OS and nothing else installed.
What can change if a second OS is installed?
If the second OS is an Ubuntu derivative (Kubuntu, Ubuntu, Mint, Xubuntu, Ubuntu Studio, etc.), its GRUB--in my experience--will over-write the contents of the existing ESP, the contents of the /boot/efi/EFI/ubuntu directory! The second OS will take over the booting. It will put its own executable grubx64.efi in there, and it will write its own brief grub.cfg file to point at its own partition's main GRUB boot file /boot/grub.grub.cfg. That main grub.cfg file (from the second OS) may include an entry for your existing Kubuntu OS; so if the computer boots, it will use the brief /EFI/ubuntu/grub.cfg file in the mounted ESP, to point at the boot menu from the second OS (its /boot/grub/grub.cfg), and that boot menu (in the second OS) may contain an option to boot into your original Kubuntu. Furthermore, as the second OS was installed, a new NVRAM variable for it (called, again, ubuntu) was created, placed in the firmware, and became part of the BootOrder; in fact, it probably became #1 in the BootOrder, called Boot0000. Your existing Kubuntu would get bumped down to second place in the BootOrder to Boot000x, where x >0 (hard telling how the exact numbering would go, but it would not be first).
If the second Linux OS, call it Linux1, is a non-Ubuntu derivative, hard telling what might happen, but probably you could expect the following: Linux1 will set up its own subdirectory in the same mounted ESP, say /boot/efi/EFI/linux1, and put its boot loader files in there, along with, possibly, some boot loader configuration file. If it uses a non-GRUB boot loader, I don't know what could happen. But if it is GRUB, there's a good possibility that it will take over the booting: A NVRAM Boot variable will be created for Linux1 (pointing at /boot/efi/EFI/linux1) and added to the firmware BootOrder, it will place itself first in BootOrder, your Kubuntu will be bumped to second. If you're lucky, the GRUB from Linux1 will add your Kubuntu to its GRUB boot file. So when the computer boots, it will boot to /boot/efi/EFI/linux1, then the file /boot/efi/EFI/linux1/grub.cfg will point at the main GRUB boot file for Linux1, i.e., /boot/grub/grub.cfg in Linux1, and it will be displayed, and there will be an entry in it for your Kubuntu, and then you can select that entry to boot into your Kubuntu.
Conclusion of these two scenarios
Upon installing a second OS, the GRUB from the second OS took over the booting.
Fact is, you can still boot into all your OSs. The only thing that changed is which GRUB installation is controlling the main, first booting. If you were to delete the second OS (write over it or re-format that partition, or delete the whole partition), then your ability to boot you first-installed OS would be affected: you probably could not boot into it (unless you also had rEFInd installed or if you install it now).
If this is OK with you, there's no problem.
If this is not OK with you, keep reading.
- - - - - - - - - -
How to "fix" your dual-boot setup.
--> Re-install GRUB to fix your boot setup.
If you have Kubuntu installed. Then you installed a second OS, Linux1 (especially where Linux1 is an Ubuntu-derivative), whose GRUB "took over" the booting (as described above in the two scenarios), then to fix this:
Simply boot into Kubuntu (where you want the GRUB to control the booting).
From there, at Konsole, re-install GRUB:
sudo grub-install
sudo update-grub # to regenerate a new boot/grub/grub.cfg file in Kubuntu
Afterwards, in the ESP, the /boot/efi/EFI/ubuntu/grub.cfg file will point at Kubuntu, where the final boot choices will be displayed from the /boot/grub/grub.cfg in Kubuntu. That's it, you're done. The NVRAM variable for ubuntu (your Kubuntu GRUB) will (probably) be set as #1 in UEFI BootOrder (if not, then change the order using efibootmgr).
--> Use efibootmgr to change the BootOrder if Linux1 is non-Ubuntu.
If Linux1 (that you installed after installing Kubuntu) is a non-Ubuntu OS, then it did not overwrite the contents of /boot/efi/EFI/ubuntu. But it did change the UEFI BootOrder and placed itself as #1. Thus, you can use efibootmgr to simple change the BootOrder--see Section 5 above; or see man efibootmgr, the examples at the end. HOWEVER, this method will not put Linux1 in your Kubuntu's GRUB's main configuration boot menu, the /boot/grub/grubcfg. To fix that, simply boot into Kubuntu and issue the command sudo update-grub.
And there's another way to handle things.
You may want to read the next topic -->
- - - - - - - - - -
To help make dual-booting easier -->
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
For now (May 2015), we are stuck with having just one ESP directory dedicated to Ubuntu and its derivatives: /boot/efi/EFI/ubuntu. But you can do this another way, you can have subdirectories for separate installations of GRUB for your different OSs. For example, you could set up /boot/efi/EFI/grubKubuntu1404, /boot/efi/EFI/grubKubuntu1504, /boot/efi/EFI/grubMintxy, and so on. Do this using the more general grub-install command.
If you want an entry in your ESP for the GRUB for a Linux OS called LinuxZ, boot into LinuxZ, make up a name you will recognize for the GRUB from LinuxZ, say grubLinuxZsdxy, and issue this command:
sudo grub-install --efi-directory=/boot/efi --bootloader-id=grubLinuxZsdxy
This will create, in the ESP, the subdirectory
/boot/efi/EFI/grubLinuxZsdxy
populated with GRUB boot-loader files from LinuxZ,
and it will create a new NVRAM variable in the firmware for it under the name grubLinuxZsdxy, which the firmware will recognize, efibootmgr will recognize, and rEFInd will recognize.
But ... keep reading before you try this -->
An easy fix for a problem dual-booting Ubuntu-based OSs (Kubuntu, Mint, etc.)
The method I just talked about, using
sudo grub-install --efi-directory=DIR --bootloader-id=some_name
will work to create and populate /boot/efi/EFI/some_name
for a Linux OS.
However, if the Linux OS is a (K)Ubuntu derivative (including, for example, Mint, Xubuntu, Lubuntu, another Kubuntu version or Ubuntu version, etc.), then there is another issue you must fix, and the fix is easy.
Here's the fix:
If LinuxZ is an Ubuntu OS derivative, first disable secure boot in your computer's UEFI firmware setup; boot into LinuxZ, then use this command to create /boot/efi/EFI/grubLinuxZsdxy:
Code:
sudo grub-install --bootloader-id=grubLinuxZsdxy --no-uefi-secure-boot
The reason for this:
The standard directory for (K)Ubuntu GRUB boot files is /boot/efi/EFI/ubuntu.
It contains grub.cfg, grubx64.efi, shimx64.efi, and maybe other files.
That grub.cfg contains a pointer to the "real" GRUB boot files that will do the booting; and they are the GRUB files located at /boot/grub/grub.cfg of the MOST RECENT (K)Ubuntu OS installed (or from which grub-install (with no options) was run).
The problem is that the pointer (referred to in the previous sentence) is hard-coded in the grubx64.efi file that is being called--EVEN if it is being called from /boot/efi/EFI/grubLinuxZsdxy. Again, note that the pointer in /boot/efi/EFI/ubuntu/grub.cfg corresponds to the MOST RECENT (K)Ubuntu OS installed (or from which grub-install (with no options) was run).
I know, it doesn't make sense, but that's the way it is.
What does this mean? Say you re-boot the computer, enter UEFI firmware setup menus, choose to boot from grubLinuxZsdxy, the GRUB boot menu you will see is the GRUB boot menu pointed to by this file: /boot/efi/EFI/ubuntu/grub.cfg, NOT from the GRUB boot menu in the OS LinuxZ (which would be the file in LinuxZ called /boot/grub/grub.cfg).
To fix this, you must create the EFI entry using the code given above with the --no-uefi-secure-boot option. Then, in UEFI firmware setup, when you select to boot grubLinuxZsdxy, you will see the GRUB boot menu from the root directory of LinuxZ (/boot/grub/grub.cfg).
This has to do with secure booting, and what the Ubuntu devs had to do to deal with secure booting (they, basically, had a choice to risk breaking secure booting or risk breaking multi-booting Ubuntu OSs; they chose the latter risk).
IMPORTANT: link, credit, and disclaimer:
The credit for the use of the option --no-uefi-secure-boot in the grub-install command goes to the author and article here, an article for advanced users:
lxgr's blog
Booting multiple Ubuntu versions with EFI
http://blog.lxgr.net/posts/2015/04/3...efi-multiboot/
My disclaimer is simply that this is all I know about it.
Along with that link, keep this one also in mind (answered by Rod Smith):
What is the difference between grubx64.efi and shimx64.efi?
http://askubuntu.com/questions/34236...64-and-shimx64
Technical Note (Advanced)
Illustrated by an example:
Suppose you have Kubuntu installed, it is your main OS, the file /boot/efi/EFI/ubuntu/grub.cfg points at the GRUB files in your Kubuntu root directory, /boot/grub/grub/cfg.
Then you install Mint. Mint's GRUB will over-write and take over /boot/efi/EFI/ubuntu that was populated by your Kubuntu's GRUB files. To fix that, you boot into Kubuntu and issue the basic command sudo grub-install, so, again, /boot/efi/EFI/ubuntu/ is populated by Kubuntu's GRUB files and /boot/efi/EFI/ubuntu/grub.cfg points at the GRUB files in your Kubuntu root directory.
Then to build a separate /EFI/ directory (and boot option) for your newly-installed Mint, using the special option --no-uefi-secure-boot, you boot into Mint and you issue the command:
Code:
sudo grub-install --bootloader-id=Mint --no-uefi-secure-boot
Look inside /EFI/Mint and you may (probably) find only one file, the GRUB executable grubx64.efi, and you will not see any grub.cfg that points at the Mint partition. However, the pointer to the Mint will be hard-coded in to the grubx64.efi file. So when you boot Mint, you will see the GRUB boot menu from Mint's root file system: /boot/grub/grub.cfg.
There's more! -->
If you want or need or think you have a creative use for more than one ESP, continue reading -->
- - - - - - - - - -
ESPs
The "default" ESP at sda1
and creating more ESPs
For many Kubuntu OS installations, sda1 will probably be the ESP, and it will be mounted at /boot/efi in the Kubuntu root filesystem. When you boot into your Kubuntu, you will (probably) notice that sda1 will be automatically mounted at /boot/efi. You can see an entry for it in /etc/fstab.
Technical note: df /boot/efi will show you the ESP your OS is using.
Most users will have just one ESP and it will usually be sda1 or sda2 (in some Windows systems). If you have more than one ESP, it is not necessarily true that "your ESP is sda1, mounted at /boot/efi." In fact, your ESP may be sda2 in some Windows systems. If you have multiple ESPs, they could be anywhere on your HDD, at any sdxy. That's where df /boot/efi comes in handy. When you boot into an OS, the ESP you are using for that OS will be mounted at /boot/efi. While you are booted into that OS, issue the command at Konsole df /boot/efi, to see what ESP partition is mounted for that OS.
ESPs -- how many?
You can have as many ESPs as you wish. But there is no guarantee that GRUB or the firmware will use them. Also, you can use just one ESP for your entire system (even with more than one HDD, even if dual-booting with Windows). If Windows is present, it was probably installed first, and thus it already set up an ESP, and that ESP can be shared by all the boot-loaders on your system (the GRUB2-EFI installer scripts will find that ESP and use it).
In fact, in my experiments:
-- upon installing Kubuntu, GRUB ignores all ESPs except for the sda1-ESP; even if it installs Kubuntu on a second hard drive sdb that is set up with an ESP as its first partition sdb1--GRUB will use the sda1-ESP; the Kubuntu installer will ignore a second ESP even if you specify the ESP as a target for GRUB installation (there is a drop-down list for you to use during the installation), even when the installer recognizes and labels that partition as an "esp" partition.
and about using a second ESP ...
-- even though GRUB might ignore a second or third ESP, after installing Kubuntu (or a Linux OS) on your PC, you can boot into it and issue the command
sudo grub-install --efi-directory=DIR --bootloader-id=some_name,
directing GRUB to be installed to DIR that is NOT the sda1-ESP, but instead is your second or third (mounted) ESP. The GRUB installed there will point to the OS you were in when you issued the grub-install command.
--> If you do this (install GRUB to an ESP that is not the sda1-ESP), when you re-boot your PC, GRUB menus may not display the option to boot using the GRUB you installed to the other ESP. BUT, the firmware does recognize it, it creates a NVRAM variable for it called some_name (the name you made up in the grub-install command), and you could enter your UEFI firmware setup and select that option to boot from; OR ... you could install and use the boot manager rEFInd and it would recognize and boot from this new boot option. If you do this sort of thing, remember to make up a name you will recognize for the some_name option; e.g., if you installed a Kubuntu OS in sdb2, you might use something like grubKubuntu1504sdb2 as the some_name in the command.
--> See also the section above titled, "GRUB 2 (for EFI)."
--> NEW: See the guide a few lines below titled "Dual-booting: How to Use Multiple ESPs" for a step-by-step sequence for installing two Linux OS, each using its own separate ESP.
Advanced:
Read Peter Jones, http://blog.uncooperative.org/blog/2...tem-partition/
- - - - - - - - - -
Changing the boot order in firmware: you may have to do this quite often
If you are dual-booting, or making any changes to your boot setups (installing or re-installing GRUB, creating ESPs, using the grub-install option --efi-directory=DIR), you may have to adjust the boot order. As explained in Section 5 above ("A few basic things about how your UEFI firmware works to boot your computer"), you can change the boot order in the firmware, the BootOrder NVRAM variable, in two ways:
Use your UEFI firmware setup menu to change the boot order; or
Use efibootmgr to change the boot order. See Section 5 or see man efibootmgr for an example.
- - - - - - - - - -
If you get a grub prompt, grub>, don't panic:
you can type halt to shut down the PC or type reboot to reboot and try again, trying something else, or entering your UEFI firmware setup.
- - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - -
Dual-booting: How to Use Multiple ESPs
To Do:
Install two Linux OSs, dual or multi-booting, where each of the two OSs has its GRUB2-EFI boot files in its own, separate ESP.
Solution:
Set up the ESPs and the OS partitions you need, using your partition editor.
Install each of the two new OSs, in sequence, with this procedure:
Turn off all ESPs except for the ESP you wish to make a dedicated ESP for the OS you are about to install now. Then do the installation using the Manual installation method. Turn on all ESPs and re-boot to test everything.
What you'll find here
Some tips, should-do's, and an example.
Partitioning, set boot flags, set labels
You can do this at the CLI or a GUI. I used GParted installed in my main Kubuntu (Muon: gparted).
To make an ESP in GParted, you can make it 512 MB, FAT32, and set the boot flag on it--that will set the partition type code for an ESP (which is EF00). (GParted: Partition > Manage flags) By "turn on" the ESP, I mean make sure the boot flag is set; by "turn off" the ESP, I mean to remove the boot flag (temporarily).
Tip: Set labels on the ESPs.
I set one label as Mintsda11 and the other label as K1504sda12. (The labels show up nicely in rEFInd and tell you where you are.) My existing ESP (before this experiment) is labeled ESP_sda1 and is my "main" ESP. (GParted: Partition > Label)
Example
Here's my setup after I did all the partitioning for this test; partitions 1-9 were existing; my main OS is Kubuntu 14.04 on sda2, and it uses the ESP on sda1; so I created 10-12 for this test (the ESP codes are in red):
Code:
sudo gdisk -l /dev/sda
...
Number Start (sector) End (sector) Size Code Name
1 2048 1026047 500.0 MiB [COLOR=#ff3333]EF00[/COLOR] <-- [B]ESP[/B][B]_[/B][B]sda1[/B][B], existing for my main OS[/B]
2 1026048 62466047 29.3 GiB 8300 <-- Kubuntu 14.04 on sda2
3 62466048 267266047 97.7 GiB 8300 <-- /home for sda2
4 267266048 300034047 15.6 GiB 8200 <-- swap
5 300034048 361474047 29.3 GiB 8300 <-- Kubuntu 15.04 / on sda5
6 361474048 566274047 97.7 GiB 8300 <-- /home for sda5
7 566274048 567298047 500.0 MiB [COLOR=#ff3333]EF00[/COLOR] <-- [B]Mint[/B][B]sda[/B][B]11[/B][B] (for testing Mint[/B][B] on sda11[/B][B])[/B]
8 567298048 669698047 48.8 GiB 8300 <-- Mint (a previous test installation)
9 669698048 772098047 48.8 GiB 8300 <-- Debian (a previous test installation)
10 772098048 773122047 500.0 MiB [COLOR=#ff3333]EF00[/COLOR] <-- [B]K1504[/B][B]sda1[/B][B]2[/B][B] (for testing Kubuntu 15.04[/B][B], sda12[/B][B])[/B]
11 773122048 824322047 24.4 GiB 8300 <-- for Mint (sda11, the new test installation)
12 824322048 865282047 19.5 GiB 8300 <-- for Kubuntu 15.04 (sda12, the new test installation)
First we install Mint to sda11
Boot into you favorite OS, open Partition Editor gparted, remove the boot flags from the two ESPs sda1 and sda10 (for each one, highlight it, Partition > Manage Flags, remove the check mark for boot). It's a good idea to see how things are before the experiment, so run sudo efibootmgr -v and copy the output to a file and/or flash drive. Re-boot using the Mint installer DVD/USB. Select Manual for Installation type. Then on the Prepare Partition screen, check that the ESP-sda7 is listed. and check that sda1 and sda10 are NOT marked as ESP's. Install Mint to sda11 (highlight sda11, Change, use for ext4, mount /; where to put bootloader GRUB? Anywhere--doesn't matter, since for UEFI it will go into an ESP and there is only one ESP visible to the installer). Then, when installation is complete ...
Re-boot, you should be greeted by the GRUB boot menu from the newly installed Mint, and it should show all your other OSs. Select the new Mint to boot to. In Mint, use Partition Editor gparted to place boot flags on ESP's at sda1 and sda10, and confirm the boot flag is also on the ESP-sda7. (You may have to use the CLI or Synaptic to install gparted.) Then re-boot and check everything this way:
-- Upon re-booting, press the proper key to enter your computer's UEFI firmware setup and inspect the boot menu(s), try to make sense of it, locate what looks like your newly installed Mint OS. Exit your UEFI setup without changing or selecting anything. It will re-boot, and you will be greeted by the GRUB boot menu from the newly installed Mint OS, select that Mint and boot into it.
-- Examine and copy the UEFI BootOrder entries using "sudo efibootmgr -v." This is part of my output:
Code:
Boot[B]0000* ubuntu HD(7[/B],21c0a800,fa000,e0211180-3fb4-4014-8af9-a8112840a308)File(\EFI\UBUNTU\SHIMX64.EFI)
-- Confirm the ESP-sda7 is mounted at /boot/efi of your Mint filesystem by issuing this command:
df /boot/efi. Example output:
Code:
Filesystem 1K-blocks Used Available Use% [B]Mounted on[/B] /dev/sda7 510984 3428 507556 1% /boot/efi
Next, install Kubuntu 15.04 in sda12.
While you are in Mint (from previous re-boot), open Partition editor gparted and turn off boot flags for ESPs sda1 and sda7; leave the boot flag for the ESP-sda10 on. Now re-boot, repeating the sequences and tips used above for installing and checking Mint. Then Kubuntu 15.04 is installed. When you have the boot flags turned on for all three ESPs, sda1, sda7, and sda10, re-boot to Kubuntu 15.04, checking everything as you go, just as we did above. When you run a final "efibootmgr -v," check everything, inspecting that all three ESPs are listed (you will have to identify them using GUIDs, as above, using ls -l /dev/disk/by-partuuid), and checking the ESP-sda10 mounting in Kubuntu 15.04 with df /boot/efi.
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 boot your kernels without GRUB by the stub-loader method. In my example, rEFInd shows more and better detail than my UEFI firmware boot menus. It showed the three ESPs: sda1, sda7, and sda10 nicely labeled: ESP_sda1, Mintsda11, and K1504sda12. rEFInd was perfectly cool: all three ESPs clearly labeled; plus stub-loader boot options for all my kernels, the vmlinuz's; everything well organized and easy to read.
Using your UEFI firmware: It depends on your firmware
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 entires called "ubuntu." Sometimes, you just have to try them by trial-and-error, then remember or set their boot order using efibootmgr (see man efibootmgr) and then remember their order. You can fix this using labels, see:
Labels on UEFI boot entries: using efibootmgr -L
https://www.kubuntuforums.net/showth...229#post378229
I have previously tried some experiments dual-booting with more than one ESP, and it may not go so well, it can become complicated. You can NOT count on the K(U)buntu installer to get things right, to identify and use your ESPs the way you intend; and you can't count on GRUB2-EFI to get the way you want it. The solution above is clean, simple, and relatively speaking, somewhat elegant.
Thanks to Rod Smith for some tips (by email) to make this go smoothly.
Technical Note: df /boot/efi will show you the ESP your OS is using.
Most users will have just one ESP and it will usually be sda1 or sda2 (in some Windows systems). If you have more than one ESP, it is not necessarily true that "your ESP is sda1, mounted at /boot/efi." In fact, your ESP may be sda2 in some Windows systems. If you have multiple ESPs, they could be anywhere on your HDD, at any sdxy. That's where df /boot/efi comes in handy. When you boot into an OS, the ESP you are using for that OS will be mounted at /boot/efi. While you are booted into that OS, issue the command at Konsole
Code:
df /boot/efi
- - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - -
Dual-booting Kubuntu: A summary of your options
To Do: Dual boot two Linux OSs, call them LinuxX and LinuxY.
Assumption: Both OSs come with GRUB2-EFI as their bootloader.
You have many options for configuring your multi-booting setup, one disk or two, one ESP or multiple ESPs, using subdirectories of the EFI directory, and, perhaps, combinations of techniques. Most systems are simple: One HDD, one ESP (at sda1 or sda2). I've listed five techniques, "Solutions," you may consider, some simple, some advanced; and perhaps you can think of other tricks, as well.
A general principle
When you install an OS, a NVRAM variable gets created for it in the computer's UEFI firmware, and that OS is placed first in the UEFI boot order (i.e., BootOrder as shown by the short listing: sudo efibootmgr, or the detailed listing: sudo efibootmgr -v). The other existing OSs are bumped down in the BootOrder; and so, for example, the OS in the #1 position will now be #2, or second, in the BootOrder. Thus, if you do nothing special, when you re-boot your computer, by default the firmware will select to boot to the last OS you installed. What can you do "special" to make it work differently? Two things: (1) When you re-boot, press the magic key to access your computer's UEFI firmware boot menu(s) and select an OS to boot. Or, (2) Change the default boot behavior of the firmware by configuring it differently (and using efibootmgr -o).
Keep the Cheat Sheet handy--Section 7.
In particular, the following commands are very useful when doing this work:
To check the UEFI firmware boot order: sudo efibootmgr -v (or brief: sudo efibootmgr)
To see your GUIDs (listed in the efibootmgr output): ls -l /dev/disk/by-partuuid/
To see what your ESP is (the partition mounted at /boot/efi): df /boot/efi
To check your GPT: sudo gdisk -l /dev/sda
To see your ESP: tree /boot/efi
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 (which will then do the actual booting of your OSs).
Procedure:
rEFInd is a boot manager and a bootloader (using the stub-loader method of booting kernels directly).
It should (and it seems to) work every time.
Install LinuxX, re-boot and install LinuxY, boot into LinuxY and install rEFInd.
You're done.
You will now rely on rEFInd to get you booted into your OSs.
Default: When you boot your computer, you will see the rEFInd boot menu and choose which OS or which kernel you wish to boot (as well as other choices presented in the rEFInd menu).
(Note: If for some reason you installed rEFInd immediately after installing LinuxX, then after installing LinuxY, you would have to boot into one of them and change the boot order so rEFInd is first in the firmware BootOrder. To do this, see Section 5, Changing the boot order, BootOrder, in UEFI firmware: simply use "sudo efibootmgr -o" as explained in "man efibootmgr" (see the examples at the end of that man page).)
Solution #2: Do nothing special. Use GRUB2-EFI.
The focus here is on GRUB: We are letting the UEFI boot manager select the first OS listed in its boot menu to boot, then control is passed to the GRUB bootloader of that OS, which then boots the OS.
Procedure:
Install LinuxX, re-boot, install LinuxY. You're done if you want to be done.
Default: When you boot your computer, LinuxY will boot by default. (And from the GRUB boot menu of LinuxY, you will have a chance to select LinuxX to boot to.)
Modification: Changing which OS controls the booting.
At first, (the GRUB from) LinuxX controlled the booting; after installing LinuxY, the GRUB from LinuxY controlled the booting. If you prefer that (the GRUB from) LinuxX control the booting then:
re-boot into LinuxX and issue two commands:
sudo grub-install
sudo update-grub
Now you are done.
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 your UEFI firmware by pressing a special key to enter UEFI firmware boot menu(s) when your computer boots up, and then selecting an OS to boot.
Your computer's UEFI firmware is also a boot manager, and you can try to use it. How well it performs depends on the firmware design. Find out what key to press when you re-boot to enter your computer's UEFI firmware setup and boot menus. Technical note: The UEFI firmware boot manager is not a bootloader. Thus, it can't boot your Linux OS directly, but it can boot your Linux OS by booting to the GRUB bootloader of that OS. The firmware boot manager can also start another boot manager, like rEFInd, that you select from the UEFI firmware boot menu. Thus, this solution #3--Try to use your UEFI firmware--is similar to Solution #2--booting by GRUB. But solution #3 also includes the option of you manually entering UEFI firmware (each time your computer boots) to select an OS or a boot manager to boot to, rather than simply letting it default to a GRUB boot of the first entry listed in BootOrder.
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. When you re-boot, enter your UEFI setup, access its boot menu(s), see the "ubuntu" entry, select it, you will then boot LinuxY, and its GRUB boot menu should show LinuxX as a boot option, and so you can choose which to boot. If you do nothing, just let the computer boot up, your UEFI firmware will boot LinuxY (which then will show you its GRUB boot menu with LinuxX listed.). And so you are done. (Technical note: Now, /boot/efi/EFI/ubuntu will contain the GRUB boot files from LinuxY.)
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, then do this: Boot into LinuxX and issue two commands: sudo grub-install and sudo update-grub. And you are done. (Technical note: Now, /boot/efi/EFI/ubuntu will contain the GRUB boot files from LinuxX.)
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 a 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").
Re-boot, enter your UEFI firmware boot menu(s), and select the OS you want to boot to.
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.
You're done ...
Unless you don't wish to be done -->
Note: 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 the command: sudo update-grub. And so, then, you are done here ...
Unless ... you want LinuxX to boot by default. In that case, boot into LinuxX and issue two commands: 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: Set up separate subdirectories of EFI for LinuxX and LinuxY
The focus here is on forcing the UEFI firmware to treat multiple Ubuntu derivatives individually; this is done by creating separate EFI subdirectories /boot/efi/EFI/<some_ubuntu_distribution>.
Note: If LinuxX and LinuxY are not both Ubuntu derivatives, there is no problem, no need to set up separate EFI subdirectories (because there will already be separate subdirectories: /boot/efi/EFI/<some_name for LinuxX> and /boot/efi/EFI/<some_name for LinuxY>).
This is discussed above (in this Section 6), under the heading "Create separate EFI subdirectories for your (K)Ubuntu (derivative) OSs."
If both LinuxX and LinuxY are Ubuntu derivatives, proceed as explained there; that is:
Boot into each of them. In each, issue the command
sudo grub-install --efi-directory=/boot/efi --bootloader-id=<some_name> --no-uefi-secure-boot
Secure boot must be disabled in your firmware for this to work.
For LinuxX, you might choose LinuxX for <some_name>; or LinuxXsdxy, where sdxy is the root partition of LinuxX. For LinuxY, choose a name you'll recognize.
Note: Whatever labels you choose, you will be able to recognize them in the UEFI firmware boot menu(s) and in the boot menu shown to you by rEFInd (if rEFInd is installed).
You have now created two EFI subdirectories: /boot/efi/EFI/<some_name for LinuxX> and /boot/efi/EFI/<some_name for LinuxY>. (Recall that your ESP is mounted at /boot/efi, and we assume the same ESP contains the boot files for both LinuxX and LinuxY).
Let's assume you did this for LinuxX first, then for LinuxY.
To make sure that each is listed on the other's GRUB boot menu (if that is what you want), boot into each and issue the command sudo update-grub. (This is not required, it is optional: you can always use your firmware menus to choose either LinuxX or LinuxY to boot into.)
Default:
When you boot your computer, the GRUB boot menu from LinuxY should appear (since LinuxY was installed last), giving you a GRUB menu and the chance to boot LinuxY or LinuxX.
Or,
When you boot your computer, you may choose to press the magic key to enter the UEFI firmware boot menu(s), where you can choose <some_name you set for LinuxX> or <some_name you set for LinuxY>. (And then, you should be shown a GRUB boot menu from that choice.)
You're done ...
Unless ... you want to change the BootOrder so LinuxX boots first:
Do this as we always do it: use efibootmgr -o as explained in the "man efibootmgr" (see the examples at the end of that man page).
You're done ...
Unless ... you want to use rEFInd:
Boot into LinuxX (or LinuxY), install rEFInd. (And so rEFInd was installed last--after LinuxX and after LinuxY, and thus, will appear first in UEFI boot order BootOrder.)
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.
And so then, you are done.
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 wish to do it for design, or for convenience, or for your own reasons or 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 then 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 named /EFI/ubuntu, and then give you a bunch of indistinguishable "ubuntu" choices in its UEFI boot menu.
This was discussed in detail, above in this Section 6 under the heading "Dual-booting: How to Use Multiple ESPs." In general terms, the solution 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 new OSs, in sequence, with this procedure:
Turn off all ESPs except for the ESP you wish to make a dedicated ESP for the OS you are about to install now. Then do the installation using the Manual installation method. Turn on all ESPs and re-boot to test everything.
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 or may not see nice, complete GRUB boot menus unless you have made certain of it by booting into each of your OSs and issuing the command sudo update-grub).
In UEFI firmware: Each OS will be set up in its own ESP under a subdirectory that is clearly named, like /boot/efi/EFI/<some_name that you'll recognize>. And you will see that name (<some_name that you'll recognize>) in the UEFI firmware boot menu; for example, it may be ubuntu, debian, suse, etc. However, for an Ubuntu OS, it is set up in its ESP in a subdirectory called /boot/efi/EFI/ubuntu, and in the UEFI firmware boot menu, you will only see it as "ubuntu." If you have a bunch of Ubuntu OSs installed like this on your computer, you may see a bunch of UEFI firmware boot entries each named "ubuntu," which can be confusing: by trial and error, you can see which entries boot which of your Ubuntu OSs.
You can fix this using labels:
NEW: See Labels on UEFI Boot Entries -- using efibootmgr -L
https://www.kubuntuforums.net/showthread.php?43221-GRUB-2-A-Guide-for-Users&p=378229#post378229
--> rEFInd: If, however, you have rEFInd installed, and you place it first in firmware BootOrder (using sudo efibootmgr -o as described in man efibootmgr), then upon booting, it will show you a boot menu on which the ESPs you created will be clearly identified by their labels (i.e., the labels you made up when you created the ESPs). For example, rEFInd may list as a boot option "/EFI/ubuntu/grubx64.efi from MintTest" and you would recognize that ESP that is labeled MintTest (for Mint, obviously). You can use more descriptive labels for your ESPs, like MintTestsdxy to indicate the partition that instance of Mint is on. Also note that rEFInd will detect and list all the kernels on your computer for you to see and boot.
**************************************************
**************************************************
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, is /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 use CLI: 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 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;
-- /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/EFIUUID=74D7-02F2 /boot/efi vfat defaults 0 1
-- 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 (also shimx64.efi, grub.cfg, MokManager.efi)
Re-install 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 will overwrite previous /EFI/ubuntu contents. Other non-Ubuntu OSs have their own /EFI subdirectory.
(3) The last-installed OS or 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:
#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:
Code:
sudo grub-install --bootloader-id=<some_name_for_LinuxX> --no-uefi-secure-boot
(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:
Code:
sudo efibootmgr -c -d /dev/sdx -p n -L NewLabel -l\\EFI\\<directory_current>\\<boot_loader>
To delete the old boot variable (having the old label):
Code:
sudo efibootmgr -b XXXX -B
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.
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[
)
Comment