Announcement

Collapse
No announcement yet.

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

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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.
    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

    #2
    With systemd 220+, you can enable systemd-boot and boot your system without grub.
    Code:
    $ 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
    I do not personally use Kubuntu, but I'm the tech support for my daughter who does.

    Comment


      #3
      Originally posted by Buddlespit View Post
      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)
      Last edited by SteveRiley; Jul 05, 2015, 10:18 PM.

      Comment


        #4
        Originally posted by SteveRiley View Post
        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.
        Code:
        loader.conf
        timeout 5
        default arch-ck
        Code:
        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.


        Originally posted by SteveRiley View Post
        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.
        Last edited by Buddlespit; Jul 06, 2015, 05:38 AM. Reason: spell check, which seems to have turned off in my Plasma5...
        I do not personally use Kubuntu, but I'm the tech support for my daughter who does.

        Comment


          #5
          [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?
          An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

          Comment


            #6
            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:
            Code:
            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:
            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
            --> 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.
            Last edited by Qqmike; Sep 28, 2015, 05:49 AM.
            An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

            Comment

            Working...
            X