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

[Qqmike]

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

See:

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

Along with References at the beginning, here's the abbreviated TOC:

TABLE of CONTENTS

SECTION 1: UEFI+GPT to replace BIOS+MBR
SECTION 2: Install your Kubuntu properly in UEFI mode
SECTION 3: GRUB 2 (for EFI)
SECTION 4: Use rEFInd alongside GRUB (Rod Smith is the rEFInd author/maintainer)
SECTION 5: A few basic things about how your UEFI firmware works to boot your computer
SECTION 6: Dual/multi-booting: Know what to expect ... and how to deal with GRUB
SECTION 7: Cheat Sheet--Tools, facts, tips, summary

This guide should get you started (it may be all you ever need) with a decent view and some handy EFI tools.

The how-to is placed, as a separate post, Post 121, in the how-to thread "GRUB 2 A Guide for Users." In a sense, the present post is also an update to GRUB for EFI. There is GRUB Legacy, GRUB 2, then GRUB 2 for EFI.

I hope it's OK to post this additional pointer to the UEFI for Kubuntu--simplified. My new stuff for UEFI is being tacked on to a long GRUB 2 thread and maybe not easy to find without a search. I plan to not only drop links like this, but also to put pointers up-front--a TOC of sorts--at the GRUB 2 how-to.

[Buddlespit]

With systemd 220+, you can enable systemd-boot and boot your system without grub.

$ bootctl --help
bootctl [COMMAND] [OPTIONS...]


Install, update or remove the sdboot EFI boot manager.


  -h --help          Show this help
     --version       Print version
     --path=PATH     Path to the EFI System Partition (ESP)
     --no-variables  Don't touch EFI variables


Commands:
     status          Show status of installed systemd-boot and EFI variables
     install         Install systemd-boot to the ESP and EFI variables
     update          Update systemd-boot in the ESP and EFI variables
     remove          Remove systemd-boot from the ESP and EFI variables

[SteveRiley]

With systemd 220+, you can enable systemd-boot and boot your system without grub.

systemd incorporated gummiboot for this purpose. IMHO, it isn't as elegant as rEFInd. While it will automatically detect the Windows Boot Manager (\EFI\Microsoft\Boot\Bootmgfw.efi), the EFI shell (\shellx64.efi) and the EFI default loader (\EFI\Boot\bootx64.efi), it will not automatically detect any Linux kernel. You must manually define stanzas for them. Which seems totally weird for a boot manager intended primarily for Linux systems!

You also need to manually copy the bootable Linux kernels to your EFI system partition. Gummiboot won't boot them from anywhere else. You'll need to remember to do this after each kernel update, too.

(source)

[Buddlespit]

systemd incorporated gummiboot for this purpose. IMHO, it isn't as elegant as rEFInd. While it will automatically detect the Windows Boot Manager (\EFI\Microsoft\Boot\Bootmgfw.efi), the EFI shell (\shellx64.efi) and the EFI default loader (\EFI\Boot\bootx64.efi), it will not automatically detect any Linux kernel. You must manually define stanzas for them. Which seems totally weird for a boot manager intended primarily for Linux systems!

You also need to manually copy the bootable Linux kernels to your EFI system partition. Gummiboot won't boot them from anywhere else. You'll need to remember to do this after each kernel update, too.

I don't know about elegant, but the options in refind took me a half-day to figure out and it gave a really pretty boot selection screen (once I was done). It took all of 10 minutes to figure out gummiboot and it is a tad 'ugly' if you decide you want boot options. A total of six lines written in two files, four of those for each kernel.

loader.conf
timeout 5
default arch-ck

arch-ck.conf
title        Arch Linux CK
linux        /vmlinuz-linux-ck
initrd       /initramfs-linux-ck.img
options      root=PARTUUID=c45c0c5e-b330-4927-8900-1ee72f4621e1 rw add_efi_memmap elevator=bfq quiet

Every boot loader/menu anyone uses will have to have some sort of editing. Especially if you have graphics problems or want to change your kernel cmdline. I haven't used grub in almost three years. And I cannot see why the linux world is still using it. My daughters laptop is a bios/Kubuntu system booted thru syslinux (the reason why I'm hanging around the forums, btw). Syslinux for bios is faster and easier to maintain, IMHO.

(source)

Yeah, I added that last *NOTE* at the bottom about Win10 stealing the boot order from UEFI yesterday. I found a dirty little hack for it. THAT was inelegant.

[Qqmike]

[Gummiboot] will not automatically detect any Linux kernel. You must manually define stanzas for them. Which seems totally weird for a boot manager intended primarily for Linux systems!

To me, this is one of the main attractions of rEFInd, and has come in sooooo handy sooooo many times for this user.

You also need to manually copy the bootable Linux kernels to your EFI system partition. Gummiboot won't boot them from anywhere else. You'll need to remember to do this after each kernel update, too.

A super-valid point for anyone who messes with these things and has tried different ways of using and configuring. Having to manually copy and maintain updates for anything is a PITA for these booting issues.

No shortage of opinions, huh?

[Qqmike]

so, for this:
UEFI for Kubuntu--simplified. And ... some dual-booting tips for Kubuntu

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

> it's tighter, new material added, and has a better Cheat Sheet at the end

The new Cheat Sheet is copied to here (to give you an idea of the fun you may be missing ):

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

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; /usr/lib/grub: x86_64.efi[-signed]? GRUB: grub-efi (not grub-pc); /sys/firmware/efi present? GPT?: sudo gdisk -l /dev/sdx


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
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 BootXXX: sudo efibootmgr -b XXXX -B
Creating Boot entries, labels efibootmgr -c -L:
sudo efibootmgr -c -d /dev/sdx -p n -L NewLabel -l \\EFI\\<directory_current>\\<boot_loader>

grub-install: Separate /EFI subdirectories, /boot/efi/EFI/<some_name_for_LinuxX> :
sudo grub-install --bootloader-id=<some_name_for_LinuxX> --no-uefi-secure-boot

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 the OS is using;

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

-- Top-level directory of ESP: /boot/efi/EFI
-- Default boot-loader: /EFI/BOOT/bootx64.efi, mounted: /boot/efi/EFI/BOOT/bootx64.efi
-- See what's in your ESP: (1) Dolphin: /boot/efi. (2) CLI: cd /boot/efi, ls -l (3) tree /boot/efi
-- sudo gdisk -l /dev/sdx lists GPT partitions and ESP with Code EF00


GPT -- GUID Partition Table layout:
Protective MBR -- first 512 bytes (for BIOS/CSM/legacy-MBR compatibility)
Partition Table Header -- the next 512 bytes
The Partition Table entries (128 in this setup, each has 128 bytes).
The actual partitions (those listed in the Partition Table entries)
The end-of-disk backup to the Partition Table
The end-of-disk backup to the Partition Table Header called the Secondary Partition Table Header
All GPT partitions are at level of a primary partition, though not called primary; only partition with a boot flag is the ESP (it doesn't mean bootable; marks it as the, 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: grubx64.efi in ESP /boot/efi/EFI/ubuntu (also shimx64.efi, grub.cfg, MokManager.efi)
Re-install while booted into Kubuntu: sudo grub-install; 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 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:

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

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


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


Labels: Setting labels for UEFI Boot variables--useful for "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 /EFI/<directory_current>/<boot_loader>, boot (in UEFI mode) the OS (represented by BootXXXX). Issue:

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

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

sudo efibootmgr -b XXXX -B

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