[SOLVED] Where is default grub.cfg?

[joneall]

One thing I don't understand is that my current system, where I run "update grub", is on /dev/sda5. But if I look at what I presume to be the default grub pointer, I see a different disk.

sudo cat /boot/efi/EFI/ubuntu/grub.cfg
search.fs_uuid 5bab455f-c534-46a2-aaff-7b5810bfa518 root hd0,gpt3 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

But that disk 5bab... is /dev/sda3, another LTS kubuntu system. Is there a way of modifying this EFI grub.cfg so it points to /dev/sda5? Maybe by installing the current system (or, rather, the next LTS with Neon) on /dev/sda3?

The problem is that at boot, there is no way I can choose the /dev/sda5 system without using reFind. There was a lengthy discussion of this here.

[Rod J]

It's one of the minor annoying things about running multiple Linux OS's on a system is that the last one installed takes over control of grub.

If you boot into the system that you want to have control of grub, then execute this:

sudo grub-install

I believe that should fix the problem.

[Qqmike]

I think Rod J is right. You can try it: boot into sda5 and issue sudo grub-install; and then, for the heck of it, sudo update-grub (although I believe grub-install runs that command, also). I'm not familiar with NEON, which is what you are using, I think.

[joneall]

Thanks, but I have tried that, followed by 'sudo update-grub'. Then tried all possible boot sources (using reFind) and none of them corresponded to what grub just wrote.

In more detail, for every partition listed by grub, one can look at the list of possible versions. None of those correspond to what I see here:

$ l1 /boot/vml*
/boot/vmlinuz-4.13.0-38-generic
/boot/vmlinuz-4.13.0-39-generic
/boot/vmlinuz-4.4.0-119-generic
/boot/vmlinuz-4.4.0-119-generic.efi.signed
/boot/vmlinuz-4.4.0-121-generic
/boot/vmlinuz-4.4.0-121-generic.efi.signed

In particular, the 4.13 versions are never there.

[joneall]

wrong /boot/efi/EFI/ subdir being used?

This is interesting.

$ sudo ls -l /boot/efi/EFI/neon
total 4646
-rwx------ 1 root root     126 mai   12 15:11 grub.cfg
-rwx------ 1 root root 1134456 mai   12 15:11 grubx64.efi
-rwx------ 1 root root 1153336 mai   12 15:11 mmx64.efi
-rwx------ 1 root root 1271672 mars  11  2017 MokManager.efi
-rwx------ 1 root root 1196736 mai   12 15:11 shimx64.efi

Those two grub files are the only files in /boot/efi/EFI which were written today. The grub.cfg contains

$ sudo cat /boot/efi/EFI/neon/grub.cfg
search.fs_uuid 2a44511d-a944-48d8-8985-9b0e2dec55b2 root hd0,gpt5 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

and that uuid does correspond to the correct disk, /dev/sda5. Since

$ sudo ls -l /boot/efi/EFI/
total 4
drwx------ 2 root root 512 déc. 17 2015 debian
drwx------ 2 root root 512 juin 17 2017 neon
drwx------ 6 root root 1024 mars 3 09:55 refind
drwx------ 2 root root 512 déc. 20 2015 tools
drwx------ 3 root root 1024 févr. 2 18:02 ubuntu

maybe the boot is using the ubuntu subdir and not neon. How to know? The grub.cfg in /boot/efi//EFI/ubuntu does point to /dev/sda3.

I am quite frustrated by this. I have reached the point where I really wonder how to overwrite all that and start over with an empty EFI partition and a new system, whenever Neon with the next LTS comes out. I would put that in /dev/sda3 and would want to keep the system on /dev/sda5. I don't really care whether I use grub or reFind at boot. Any pointers or suggestions?

[Qqmike]

maybe the boot is using the ubuntu subdir and not neon. How to know? The grub.cfg in /boot/efi//EFI/ubuntu does point to /dev/sda3.

Boot into your OS, say sda5 (the one you want to get into), and try:

sudo efibootmgr

or for more detail

sudo efibootmgr -v

That should show you the BootOrder that your UEFI firmware is using.

[Qqmike]

And you can change the boot order, you know.

Change UEFI BootOrder: sudo efibootmgr -o 0003,0000,0002,0004, or sudo efibootmgr -o 3,0,2,4
That would make the new boot order Boot0003, Boot0000, Boot0002, Boot0004

I'm a little punchy about NEON as I haven't used it; but I see GRUB issues posted all over this place by NEON users, so maybe they can see something here, as well.

[Qqmike]

btw, see
man efibootmgr
toward the end of that page for changing boot order using -o (the letter "oh" as in)

[joneall]

Re-creating ESP

I am thinking of how I might give up on understanding and just recreate grub, refind and the ESP. Would this work?

Given that my firmware knows about EFI, that my three drives are partitioned with GPT and that a 250MB (overkill?) ESP already exists on /dev/sda;

1. Backup everything at least twice!
2. Use gparted to delete ESP and recreate it in FAT32 (which it is now).
3. Install a new KDE Neon distrib to some partition (/dev/sda2, in my case)
4. Boot the new system
5. Install rEFInd
6. run update-grub (I assume the system installation installed it on the EFI partition).

And everything should be hunky-dory, right? Meaning,

(a) boot with rEFInd will find all my system partitions (on all my drives), and

(b) using rEFInd to boot grub should find all my system partitions, too.

Frankly, it sounds too good to be true, so I hope someone will have objections or at least caveats.

[Qqmike]

Oh boy, I wouldn't YET start from scratch! You have two things going on: UEFI and NEON. In any case, it takes no time to simply see what it looks like now, when booted into sda5:
sudo efibootmgr
I'll bet /EFI/neon is not listed as first in boot order (but you want it to be first, right?).
If Neon is not first, I'd try sudo efibootmgr -o ..... to try to make it first in BootOrder.

-------------------------------------------------
As for what you listed in post #9:

Use gparted to delete ESP and recreate it in FAT32 (which it is now).

AND: in gparted, set the boot flag on it! Doing so does not make it bootable in the old, classical sense; but it marks it specifically as the ESP.

run update-grub (I assume the system installation installed it on the EFI partition).

I'm not sure one way or the other -- it depends on your goal here. In general, update-grub does this:
When you are booted into an OS and you run
sudo update-grub
then the grub.cfg menu in the OS /boot/grub that you are now booted into will be updated to include other OSs on your disk(s). Example: Say you boot into the OS on sdax and you issue the command sudo update-grub. Then on the partition sdax, the file /boot/grub/grub.cfg will be updated to include other OSs you have on your PC system disks.

[joneall]

I am at the point at which I am starting to tear out my few remaining hairs (both of them).

I did change the boot order and checked in the "BIOS" that it had been recorded. I picked Neon for the first one. (I have tried selecting that manually in the boot config, with the same result.) In /boot/efi/EFI/neon/grub.cfg, I see it is looking at the partition for this system, /sda5.

$ sudo cat /boot/efi/EFI/neon/grub.cfg
search.fs_uuid 2a44511d-a944-48d8-8985-9b0e2dec55b2 root hd0,gpt5
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

$ blkid | grep 2a44511d-a944-48d8-8985-9b0e2dec55b2
/dev/sda5: UUID="2a44511d-a944-48d8-8985-9b0e2dec55b2" TYPE="ext4" PARTUUID="ad398cc6-a634-479b-9478-2e7645ffc9c1"

$ df /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda5 61796348 23074220 35560016 40% /

On this disk, I see several systems:

$ ls -1 /boot/vml*
/boot/vmlinuz-4.13.0-39-generic
/boot/vmlinuz-4.13.0-41-generic
/boot/vmlinuz-4.4.0-121-generic
/boot/vmlinuz-4.4.0-121-generic.efi.signed
/boot/vmlinuz-4.4.0-124-generic
/boot/vmlinuz-4.4.0-124-generic.efi.signed

I am running this one:

$ uname -a
Linux jon-neon 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

because refind found it independently of grub. Looking at the /boot/grub/grub.cfg, I see menu entries for:

/boot/vmlinuz-4.13.0-41-generic
/boot/vmlinuz-4.13.0-41-generic
/boot/vmlinuz-4.13.0-39-generic
/boot/vmlinuz-4.13.0-39-generic
/boot/vmlinuz-4.4.0-124-generic.efi.signed
/boot/vmlinuz-4.4.0-124-generic.efi.signed
/boot/vmlinuz-4.4.0-121-generic.efi.signed
/boot/vmlinuz-4.4.0-121-generic.efi.signed

and then entries for other drives. So that all hangs together and looks fine. BUT, when I boot with refind from /boot/neon/grubx64.cfg, it does not see this set of files.

Maybe I don't understand refind(?).

[Qqmike]

I'd still like to see
sudo efibootmgr
(You would issue this command from sda5--the OS you wish to be in.)

Because, if you are using UEFI (which you say you are, and which it certainly looks like you are), then you should be able to set /boot/efi/EFI/neon as first in BootOrder.

when I boot with refind from /boot/neon/grubx64.cfg, it does not see this set of files.
Maybe I don't understand refind(?).

Hard telling what rEFInd is doing here. In general, rEFInd will boot your Linux OSs using the stub loader method, and for that rEFInd ONLY needs to know the kernel you want to boot, and rEFInd should show you that kernel in its boot menu (that you see when you boot your PC and the rEFInd screen shows up), like you might see and entry for vmlinuz-4.4.0-124-generic.efi.signed listed somehow in a way that identifies this kernel to boot.

[joneall]

$ sudo efibootmgr
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0003,0000,0002,0006,0007,0008,0009,000A,0005, 0004
Boot0000* ubuntu
Boot0001* rEFInd Boot Manager
Boot0002* debian
Boot0003* neon
Boot0004 CD/DVD Drive
Boot0005* ubuntu
Boot0006* UEFI OS
Boot0007* UEFI: KINGSTON SV300S37A480G
Boot0008* UEFI: Hitachi HDS721010CLA330
Boot0009* UEFI: ST1000DM003-1CH162
Boot000A* Hard Drive

I realize this is not the one you want, but when I do it with that one, I get the result mentioned in my last reply.

Btw, is there a way to get rid of all that stuff llike the CD/DVD drive? And why does Boot0000 look a lot like Boot005?

I will do what you suggest and post it tomorrow. It's getting late here.

Thanks for you help!

[joneall]

I'm a little punchy about NEON as I haven't used it; but I see GRUB issues posted all over this place by NEON users, so maybe they can see something here, as well.

Could it be related to Neon? To its having its own subdirectory /boot/efi/EFI/neon in addition to /boot/efi/EFI/ubuntu?

[GreyGeek]

If you continue to have problems and go looking for a solution, let me advise you AGAINST using Grub Customizer. It will mess up your system, sooner or later, and the only solution to that is a fresh install.