Confused about grub partitions

[mr_raider]

Thanks, all. I will read Qqmike's document grub2 et al. I still have one point of confusion, but it is perhaps explained in that document. I will ask anyway. As I said, in the efi partition, I see:

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

From what you say, all my systems will use ubuntu for booting. Even neon? If not, why is the neon one there? Surely, one can have a multi-boot system with xubuntu, neon, windoze and even macOS. Is each one going to use a different subdirectoryof efi/EFI? If so, will they find each other without my having to loop thru all those systems to run grub2?

refind will use the info in the refind folder. I don't know how debian handles efi. Windows uses it's own efi bootloader.

Neon and ubuntu are using the same folder, notably. If ubuntu is absent, neon will use the grub.cfg file in it's subfolder. If there are both, the grub.cfg in ubuntu's folder is used, regardless of which grubx64.efi boots.

check the grub.cfg file in both neon and ubuntu subfolders. Does the root uuid match? If not, the Ubuntu one is usually the one being used and control of boot is passed to that grub. You can test this by changing the name of the EFI/neon/grub.cfg and your boot should still work.

To find out which EFI is being updated run

cat /etc/fstab

from the booted install. That tells you which efi is being written.

Which efi is booted can be seen from

sudo efibootmgr -v

which grub is in control of teh boot process can be seen from the UUID listed in the grub.cfg file of the appropriate EFI bootloader.

All three are not necessarily the same.

I maintain my suggestion of disconnecting all drives except the one that has neon, booting it and fixing that OS to start. Then we can attack the other one by one.

[mr_raider]

Here is a similar issue between mint and ubuntu:

https://askubuntu.com/questions/8043...-launch-ubuntu

[joneall]

Here is a similar issue between mint and ubuntu:

https://askubuntu.com/questions/8043...-launch-ubuntu

Interesting. But does it have to be so complicated? Seems to me I never had this problem before, and that's for 15 years or more.

[joneall]

refind will use the info in the refind folder. I don't know how debian handles efi. Windows uses it's own efi bootloader..

Then what updates that when a new version of a system is installed? Or does refind reread everything (all disks) at each boot?

Neon and ubuntu are using the same folder, notably. If ubuntu is absent, neon will use the grub.cfg file in it's subfolder. If there are both, the grub.cfg in ubuntu's folder is used, regardless of which grubx64.efi boots.

check the grub.cfg file in both neon and ubuntu subfolders. Does the root uuid match? If not, the Ubuntu one is usually the one being used and control of boot is passed to that grub. You can test this by changing the name of the EFI/neon/grub.cfg and your boot should still work.

They are different. In ubuntu, it points to my Neon partition. In ubuntu, to a 16.04 LTS partition. Maybe if I run update-grub there...

To find out which EFI is being updated run

cat /etc/fstab

from the booted install. That tells you which efi is being written.

Which efi is booted can be seen from

sudo efibootmgr -v

which grub is in control of teh boot process can be seen from the UUID listed in the grub.cfg file of the appropriate EFI bootloader.

All three are not necessarily the same.

You are certainly right there:
modified part = /dev/sda1
EFI/ubuntu part = /dev/sda5
EFI/Neon part = /dev/sda3

The BootOrder given by efibootmgr is
rEFInd (which I installed since this post), neon, ubuntu, debian, UEFI: Hitachi (whatever that means; it's /dev/sdb), UEFI: ST1...(/dev/sdc), UEFI OS ..., UEFI KINGSTON (/dev/sda). CD. Hard Drive, ubuntu (again!)

I maintain my suggestion of disconnecting all drives except the one that has neon, booting it and fixing that OS to start. Then we can attack the other one by one.

Yeah, I am just loath to pulling wires loose in my computer (I'm a software guy, not a hardware one), so I was hoping for another solution. Looks like I'm not going to find it. It's getting on toward evening here, so I'll leave that for tomorrow. Thanks for all your input.

[mr_raider]

It looks like /dev/sda5 has the grub you are looking for.

A software solution would be to nuke all EFI partitions except for one.

Within that EFI keep only neon and refind. Have neon point to your install. Mount that in fstab and update that.

Alternatively you could forget grub and have refind directly boot your kernel.

Yes refind scans all partitions on each boot. That's is its power.

Sent from my ONEPLUS A5010 using Tapatalk

[joneall]

Neon and ubuntu are using the same folder, notably. If ubuntu is absent, neon will use the grub.cfg file in it's subfolder. If there are both, the grub.cfg in ubuntu's folder is used, regardless of which grubx64.efi boots.

Sorry to go on beating this same subject, which I think I am understanding (with your help and AdamW's description). It's confusing this ubuntu/neon stuff, because the boot order for my install is clearly 1, 3, 0, i.e., refind, then neon, then ubuntu. Having neon look first in ubuntu seems like an infringement of the rules.

Oh, yes, where does that boot order come from? Who put it there and when?

[joneall]

By "nuke", do you mean just

rm -rf /boot/efi/debian

or is there a fancier way of doing it, like with efibootmgr? maybe initially a rename would be safer.

[mr_raider]

Sorry to go on beating this same subject, which I think I am understanding (with your help and AdamW's description). It's confusing this ubuntu/neon stuff, because the boot order for my install is clearly 1, 3, 0, i.e., refind, then neon, then ubuntu. Having neon look first in ubuntu seems like an infringement of the rules.

Oh, yes, where does that boot order come from? Who put it there and when?

The boot order is in the motherboard nvram. When you install an OS it creates an entry in the nvram for its EFI loader.

The order is respected. The issue is that neon mint and Ubuntu use the same grub2 package, that was configured by Ubuntu. In the case of neon, it installed with the distributor id parameter set to neon. Nevertheless, if it finds the Ubuntu folder, it will boot using the parameters in the Ubuntu folder.

In single install of neon, the Ubuntu folder does not exist, initially, until you get an update to the grub or shim packages. Then it gets created. And your neon folder stops being used.

Sent from my ONEPLUS A5010 using Tapatalk

[mr_raider]

By "nuke", do you mean just

rm -rf /boot/efi/debian

or is there a fancier way of doing it, like with efibootmgr? maybe initially a rename would be safer.

Yeah don't touch debian because I don't know how it behaves.

I meant get rid of all the EFI partitions on the other drives.

While it is allowable to have seperate EFI partitions, and you could put one in each disk, I see no advantage to that except in dual boot scenarios with windows.

I would keep one EFi partition, and have all your bootloaders and refind there.

Make sure all your OSes have that partition mounted in fstab.

That still will not resolve the issue of neon and Ubuntu using the same grub.cfg file. One thing you could do is manually point it to the neon UUID, and exclusively use the neon grub to boot all your OSes. But beware that upgrading grub from any other Ubuntu type OS will bork the UUID again.

Sent from my ONEPLUS A5010 using Tapatalk