EFI and BTRFS booting mess. Can I change the GRUB host?

[jlittle]

TriMoon[emoji769];439363] grub.cfg that is used by the grub boot-loader inside <ESP>\EFI\ubuntu,
Taking a look inside...

The last time I checked out the grub.cfg in the EFI/ubuntu directory I found that it was not used, and changes to it had no effect. Instead, the grub boot directory was written into the .efi file. (With secure boot I imagine grub has to work this way.) I don't know why it is there.

[mr_raider]

Ooh ooh ooh I know this one:

https://community.kde.org/Neon/Insta...tion_June_2016

Now, my Neon upgraded to 20.04 has this now (including WIndows 10):

root@dohbuoy-FLEX-15IIL:/boot/efi# tree
.
├── EFI
│   ├── BOOT
│   │   ├── BOOTX64.EFI
│   │   ├── fbx64.efi
│   │   └── mmx64.efi
│   ├── neon
│   │   ├── BOOTX64.CSV
│   │   ├── grub.cfg
│   │   ├── grubx64.efi
│   │   ├── mmx64.efi
│   │   └── shimx64.efi
│   └── ubuntu
│       ├── BOOTX64.CSV
│       ├── grub.cfg
│       ├── grubx64.efi
│       ├── mmx64.efi
│       └── shimx64.efi
└── System Volume Information
   ├── AadRecoveryPasswordDelete
   └── ClientRecoveryPasswordRotation

7 directories, 13 files

I have not done a fresh 20.04 Neon, which is using Calamares, which probably does not have this hard-coding. However, since Neon is using Ubuntu's packaging for all this, some Ubuntu structure may be a bit required. I have no clue, really.

I do have Win 10 on a separate SSD, including its own efi partition.

My install was a fresh 20.04 with Calamares.

[©TriMoon™]

The last time I checked out the grub.cfg in the EFI/ubuntu directory I found that it was not used, and changes to it had no effect. Instead, the grub boot directory was written into the .efi file. (With secure boot I imagine grub has to work this way.) I don't know why it is there.

The "<ESP>\EFI\ubuntu\grubx64.efi" file needs some way to determine the root partition to look for "/boot/grub/grub.cfg" so "<ESP>\EFI\ubuntu\grub.cfg" is the only logical place it will grab that info IMHO...
You could try to change the UUID inside "<ESP>\EFI\ubuntu\grubx64.efi" and check
Don't do this on your normal system because you might get left with an unbootable system if you don't have another bootloader working...

And again i hate to repeat it, but all this mess is solved in a very simple and non-conflicting way by Systemd-boot
Because each distros kernel and ramdisks to be used are put in separate (vendor) directories and defined inside the config snippets:

/boot/efi
├── loader
│   ├── entries
│   │   ├── KeyTool.conf
│   │   ├── MokManager.conf
│   │   ├── efi-kubuntu.conf
│   │   ├── grub-kubuntu.conf
│   │   ├── kubuntu_.conf
│   │   ├── kubuntu_old.conf
│   │   └── kubuntu_prev.conf
│   ├── loader.conf
│   └── random-seed

The "grub-kubuntu.conf" here actually is an entry that instructs Systemd-boot to use the "normal grub" bootloader used by the ubuntu install...

# /loader/entries/grub-kubuntu.conf
title        Grub-loader
version      Kubuntu
architecture x64
efi          /EFI/ubuntu/grubx64.efi

[jlittle]

The "<ESP>\EFI\ubuntu\grubx64.efi" file needs some way to determine the root partition to look for "/boot/grub/grub.cfg" so "<ESP>\EFI\ubuntu\grub.cfg" is the only logical place it will grab that info IMHO...

Yes, I thought it was logical, too. When I first looked into this in detail, I was trying to set up an EFI boot to a boot/grub separate from any particular install, as I'd done on my previous BIOS/MBR system, but changing the EFI/ubuntu/grub.cfg had no effect. The location of /boot/grub/grub.cfg was in the grubx64.efi file; I could see it there by running strings -n 10 on that file. The strings trick stopped working at some point. To control where grub finds /boot/grub, I had to use grub-install --boot-directory

sudo grub-install --boot-directory=/mnt/top/@grub/boot --efi-directory=/boot/efi

Here, /mnt/top is where the btrfs root (which is not the Linux root) is mounted.

In writing this post, I notice that my grub set up dates from 2018, maybe it's about time I refreshed it. I normally leave /boot/efi unmounted in Kubuntu, to stop grub messing with it when updates occur. Because I have a working bootloader in a place I control, I can experiment using another. If I get around to it I'll see if the EFI grub.cfg is still not used.

[©TriMoon™]

The location of /boot/grub/grub.cfg was in the grubx64.efi file; I could see it there by running strings -n 10 on that file. The strings trick stopped working at some point.

For EFI applications you need to use "--encoding=l" because strings in them are all little-endian 16-bit chars (CHAR16)...

In writing this post, I notice that my grub set up dates from 2018, maybe it's about time I refreshed it. I normally leave /boot/efi unmounted in Kubuntu, to stop grub messing with it when updates occur. Because I have a working bootloader in a place I control, I can experiment using another. If I get around to it I'll see if the EFI grub.cfg is still not used.

I would highly recommend to use Systemd-boot, if you run Kubuntu you might want to try my script i linked to several times. (It's on this forum)
But please be aware of it adding "intel_iommu=on" to your kernel commandline at moment, you can simply comment that line out if you don't want it.
If you install and run it once while in your live session it will automatically install Systemd-boot with proper config snippets for your current boot...
(And update the kernel(s) and ramdisk(s) used to boot from on each update of them without unneeded writes to the ESP in case that is on a SSD etc...

[mr_raider]

This is a recent change then. I used to be able to change EFI/Ubuntu/grub.cfg manually to boot off of different subvolumes. That way I had multiple distros installed in different subvolumes in the same partition and I could choose which one I booted.

Sent from my HD1905 using Tapatalk

[GreyGeek]

Ok, ©TriMoon™ come clean!
Are you really Steve Riley in disguise?


Your posts about eif, systemd-boot and the technical level of your discussions reminds me of Steve Riley. He was a former admin in this forum who replaced me when I retired. He formerly worked for MS, Google, River Rock and when Gartner lured him away he was required to quit the forum because of the nature of his work for Gartner. Steve was absolutely brilliant in Windows, of course, and reasonably knowledgeable in Linux when I asked him to replace me. He became brilliant in Linux/Kubuntu in short order. He reminded me of several guys in grad school who were an order of magnitude smarter than most of the rest of us. Certainly me.

I notice from the time sigs on your posts that you are somewhere in GMT -1 +-1.

[©TriMoon™]

Hehehe no not really...
I share some of his knowledge maybe but that's un-avoidable if you've eating binary since 8yrs old... (im now 53)
I grewup using FIDO-net, VIC-20 etc and as hacker like most kid-geeks, then turned whitehat for a while (uhmm oops )

And no im in GMT+3 since uhmmm 5-6 yrs now.. (Was GMT+1 whole my live)