Where is default grub.cfg?

[jlittle]

On my Bionic Kubuntu, there is a stub grub. cfg in the EFI/ubuntu directory that is not used at all. Making changes to it had no effect. Before I mucked around with it the grub EFI executable beside it had a reference inside it (in grub's format) to /@/boot/grub/grub.cfg, which is what Kubuntu sees as /boot/grub/grub.cfg, and that is what update-grub updates.
I'm not sure your Neon does things that way.
I have taken control of grub by giving it its own subvolume and manually maintaining a very simple grub.cfg there. No install will trample on it.

[edit] After posting this I realised that I use btrfs, and probably the OP does not. The above still applies to ext4 file systems, just delete "/@" and substitute "partition" for "subvolume". I used grub like that for many years, with so little effort I forgot how I did things.

Regards, John Little

[Qqmike]

(After reading this post, see also the next post #18.)

Regarding your Post #13 above:

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?

(1) It is the one I want.

(2) No, don't bother getting rid of stuff like CD/DVD drive. It is not messing anything up to just keep it in the UEFI boot menu. The usual rule with UEFI is this: Never delete a boot entry you don't fully understand, or a boot entry that MAY be important. However ... that said, yes you can delete UEFI boot entries from the UEFI boot menu using the form efibootmgr -b XXXX -B to delete BootXXXX -- see the man page by issuing the command man efibootmgr.

(3) Boot0000 looks like Boot0005 because in the UEFI system, there is only one subdirectory that is used by ALL OSs that are Ubuntu derivatives (like Ubunutu, Mint, Kubuntu, Xubuntu, etc.). Yes, that is unfortunate, it is confusing, and it is a flaw in the UEFI system. That one single subdirectory is, of course, /boot/efi/EFI/ubuntu. But my how-to's show how to get around this limitation; in fact, how to essentially fix this limitation. Don't get too bogged down now, but for reference you can see a list of my how-to's on UEFI here:
https://www.kubuntuforums.net/showth...-fixing-things

OK, so now what? You can try to change the UEFI boot order. You can see from Post #13 that Boot0001 boots first (that is rEFInd). But you are telling me that somehow rEFInd is not giving you the option of booting rEFInd? I think it SHOULD, but maybe you can't identify it in rEFInd's boot menu? Or maybe rEFInd is not "seeing" that neon subfolder (boot/efi/EFI/neon) in the ESP. I don't know the answers. However ...

You can try to change the UEFI boot order so that neon is tried first; so that Boot0003 is tried first. To do so, boot again like you did in Post #13 (into sda5, I think), and issue this command:

sudo efibootmgr -o 0003,0001,0000,0002,0006,0007,0008,0009,000A,0005, 0004

Notes:
-- You can see that we only interchanged rEFInd with neon.
-- That argument -o is minus the letter oh, "o" as in ontological.
-- Let's not mess anything up! Thus, I am including ALL those BootXXXX variables, as you can see--eleven of them.
-- There is no space between the BootXXXX variables in that list of eleven of them, separated only by a comma.

So you would do that, re-boot, and see what happens! If the neon boot variable works, you should see something familiar from Neon. You will not see rEFInd boot menu if the Neon boot variable works (i.e., Neon's Boot0003 will work instead of rEFInd's Boot0001 doing the booting). If the UEFI system cannot boot from Boot0003, it will then try the next in line, which is Boot0001 (i.e., rEFInd), and that should work as it has been working. If Boot0001 fails (but it should work ok), the next one tried will be Boot0000 which is one of your "ubuntu" OS's, and that would probably work to get you into an OS you recognize. And so on. But, we are hoping here that Boot0003 (i.e., neon) will work as you expect. You can always re-boot into sda5 (somehow) and change that boot order back around to the way it was in Post #13. (Btw, in the future, it is always handy to have rEFInd on a bootable CD/USB that you can use to get booted into something. See that list of how-to's in the above link I gave.)

[Qqmike]

Just to be clear, in Post #17, I tried to answer your questions. Then I suggested the next step on your part would be this:

You can try to change the UEFI boot order so that neon is tried first; so that Boot0003 is tried first. To do so, boot again like you did in Post #13 (into sda5, I think), and issue this command:

sudo efibootmgr -o 0003,0001,0000,0002,0006,0007,0008,0009,000A,0005, 0004

We hope that that would cause your PC to boot up directly into Neon (which is Boot0003) using /boot/efi/EFI/neon, which is what I think you want.

[joneall]

All working, but why...?

Using refind, I logged into an LTS system and ran grub-install and update-grub. Now the grub.cfg in /boot/efi/EFI/ubuntu is "correct", meaning it points to the partition corresponding to that system's system partition.

I used this to log into Neon and ran grub-install and update-grub there too. Comparing dates in /boot/efi/EFI shows clearly which system writes what. Running update-grub on a Kubuntu system writes a grub.cfg file into EFI/ubuntu, a Neon system into EFI/neon, a Debian system into EFI/debian, refind into EFI/refind. I don't know who uses EFI/tools since that directory is empty on my computer.

$ 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

I also changed the boot partition order both with efibootmgr, as qqmike suggested, and using the firmware configuration of my mother board. I believe I understand how that works now. Thanks for your insistence on that.

As a result of all this, everything seems to work properly, although I am not quite sure why. For me, the main things are that

1. I got a lot of good suggestions from you guys, for which much thanks; and
2. I learned a lot about the UEFI boot process.

If anybody is interested, I'll do a summary of that. There are some questions in there too.

I like to know the steps followed by a program, which I prefer to determine experimentally (which is the only way if I don't feel like reading the sources).

1. The UEFI firmware on the motherboard contains an ordered list of boot options.
2. The options apparently may correspond to subdirectories of the ESP or, it seems, to physical partitions.
3. The order of these entries may be modified with the firmware interface at boot time or using efibootmgr on a Linux system.
4. For an ESP subdirectory, the UEFI booter reads EFI/$subdir/grub.cfg to get the UUID of the partition to read. This was written by the last update-grub on that system. QUESTION: If you don't use grub, who writes it?
5. It then looks in /boot/grub/grub.cfg on that partition to find the list of bootable systems on that partition. This also is written by grub.

Refind is a bit more detailed: It can find grub entries, which on being selected present a normal grub boot list. Or it may show some individual choices. In my case, these are the latest two Neon systems, 4.4.0-124 and 4.13.0-41. QUESTION: How does it know to do that?

Once again, thanks all. And if you have corrections to my summary or answers to my questioins, I want to learn.

[Qqmike]

Hi joneall. Glad you got things fixed the way you want them. Everything you have done looks good. I'll respond more later, as I am being pulled away on some social stuff here, for awhile ...

[Qqmike]

OK, back for awhile, so ...

Good practice:
You ran efibootmgr to see the list of BootXXXX variable and their order in UEFI. Then you made some changes. So it is good practice to run efibootmgr again -- like doing a before and after check, to see things as they are now and to confirm things as you expected them to be.

Your points 1-5 look good; just comments on 2 & 4:

On your point 2:

The options apparently may correspond to subdirectories of the ESP or, it seems, to physical partitions.

The options do correspond to the subdirectories /boot/efi/EFI/<sub-directories>. In the subdirectories: That's where the EFI executables are stored, that's where the boot loaders are stored.

or, it seems, to physical partitions.

No, not so much -- at least that is not the primary focus of the UEFI Boot variables. Yes, within the subdirectories /boot/efi/EFI/<sub-directories>, you may find references to partitions where you can find kernels or configuration files.

Point 4:

For an ESP subdirectory, the UEFI booter reads EFI/$subdir/grub.cfg to get the UUID of the partition to read. This was written by the last update-grub on that system. QUESTION: If you don't use grub, who writes it?

If you don't use GRUB, maybe you use some other bootloader, and that bootloader would write everything it needs within its $subdir. If you don't use GRUB, you can boot in at least ways: (1) using rEFInd; and (2) MAYBE by using ONLY the UEFI firmware, which will boot by the stub loader method -- for recent kernels, the kernel is bootable; that's how rEFInd may work, too. I have done these experiments. For example:

Remove GRUB from UEFI -- Instead, use rEFInd and/or UEFI firmware boot menus
https://www.kubuntuforums.net/showth...317#post378317

Boot Kubuntu Using UEFI Only -- no GRUB, no bootloader, no rEFInd, no other boot manager/loader
https://www.kubuntuforums.net/showth...271#post396271

A related topic is "registering" a bootloader with UEFI. I talk about that a little in my how-to's on changing labels. Rod Smith addresses it at length. When you register a UEFI executable (e.g., a bootloader) with UEFI, that process sets up the references and details your firmware needs to boot from it.

Registering the Boot Loader with the EFI
http://www.rodsbooks.com/efi-bootloa....html#register

Refind is a bit more detailed: It can find grub entries, which on being selected present a normal grub boot list. Or it may show some individual choices. In my case, these are the latest two Neon systems, 4.4.0-124 and 4.13.0-41. QUESTION: How does it know to do that?

Rod Smith wrote rEFInd, and it's one heck of a good program. Rod understands a lot about booting and boot data structures and UEFI. His program searches and finds as much as it can that looks like something it can boot from.

The rEFInd Boot Manager
http://www.rodsbooks.com/refind/index.html

More below, next post -->

[Qqmike]

joneall, people seem baffled by UEFI but in many ways it is simpler than the old GRUB Legacy ways. Conceptually, it is this simple (this kind of repeats what you have discovered above in your post):

You have the UEFI firmware running in your computer and starting it up. It looks for something to boot or to run-execute (i.e., it looks for a UEFI executable). Where does it look? It looks in your ESP (EFI System Partition). Your ESP is usually mounted at /boot/efi, and its main directory is /boot/efi/EFI. Within EFI you will find subfolders containing UEFI executables (and that includes bootloaders). Those subfolders under EFI contain Boot variables that UEFI searches through, using the BootOrder, which you can see and change using efibootmgr. Thus, the UEFI looks through the subfolders of /boot/efi/EFI to find UEFI executable bootloaders (or other UEFI executables to run). And that's it, in a conversational nutshell.

[joneall]

Great! Many thanks.

[oshunluvr]

Late to this thread and I just skimmed it, but a couple comments;

As a multi-booter I got tired of this problem (each new distro taking over grub) long ago and I fixed the problem by building a stand-alone grub install that would not be wiped out each time I installed a new distro. Now, because of btrfs, it's even simpler. Something to consider and if you are running into this problem often I would recommend do this. I will not detail it here as I have in other posts on this forum.

Rod Js comment about the grub-install command was spot on, but running it without options as suggested would not change the boot drive as I thought was part of your issue. You can also use the command to switch which distro grub comes from.

By adding the desired boot device at the end of the grub-install command you can direct which drive(s) is/are bootable. In my case, I have 4 drives installed so all of them are bootable just in case one fails or gets a damaged boot table.

To set which installation of grub you wish to use, you can either boot into the desired install ("owner") of grub and run grub-install, mount the /boot folder of the desired install and add the --boot-directory option, or mount the root folder of the desired install and use the --root-folder option.

Example: sudo grub-install --boot-directory=/mnt/boot /dev/sdb

This would look in the "/mnt/boot" folder for the grub directory and install the grub boot loader to drive sdb. This is what you might do after a new installation required you to install grub without option and you wanted to revert back to using another installation's grub.

I can't speak to any differences that EFI might involve, but I believe the above process works for both EFI and non-EFI installs. Qqmike can answer that.

[Qqmike]

oshunluvr: I can't speak to any differences that EFI might involve, but I believe the above process works for both EFI and non-EFI installs

No, it doesn't work with UEFI. With UEFI, you have to use the grub-install options which make sense for UEFI. See man grub-install. The key is that with UEFI, you have an ESP which contains all your boot loaders.