This does NOT an ESP make! And flags are largely irrelevant for Linux, they’re a Windows thing…
rEFInd, or GRUB for that matter, needs .efi files in an EFI System Partition each pointing to a different SYSTEM partition - “root” or /-. You can’t just turn any root filesystem into an ESP which is what you tried with the flags? That’s not how it works. You can have multiple Ubuntu installations (+Windows +other distros, etc.) and only one ESP is required, big enough to contain all the required first-stage bootloaders.
Sure, with 2.57MiB used which means it contains ONE bootloader. This is what rEFInd can see and GRUB as well.
It seems you’re under the impression rEFInd is somewhat “magical”. It isn’t, that much should have been clear in my first reply. rEFInd is just another bootaloader that can chainload many others but it will not install or invent bootloaders that aren’t there! And “there”, again, means in the ESP.
Sorry - I thought refind scanned all partitions and looked for any bootable
OS’s. I thought it would find the /boot directory in my ‘2nd ubuntu’
partition and look within for an entry that would boot. I stand
corrected.
So what can I do to the ESP so that refind can boot my '2nd partition ?`
IF - this is a big “if” - Boot Repair can be used in this situation, the solution is easy to implement and doesn’t require additional knowledge. Otherwise you need to find a way to boot the second Ubuntu without a bootloader and from there install GRUB. How to do that I’m not sure, maybe chrooting, I don’t know. Better wait for the experts here.
How did you verify that you were booted to the Ubuntu on sda2 if both it and sda7 are identical? Did you check whatever configuration file rEfind uses (comparable to grub.cfg) to see what UUID is in the menuentry for the Ubuntu on sda7 as well as sda2? When you select to boot the 2nd instance of Ubuntu (on sda7) do you run df -h to see what the / partitin is?
Just passing through, my question would be more from the viewpoint of “why”? As in “why are you using refind??” There was a time many years ago when refind was helpful for booting linux on Macintosh machines, but then it became more complicated and the utility actually became moot, in that with the use of intel cpus, linux can be booted up using grub on Mac . . . and grub can do multi-boot particularly when one system is the grub ““handler” and the others are “slaves.”
As far as adding an installed system into grub, os-prober is the app that does that, likely for both grub and refind . . . the command to run os-prober would scan the machine for bootable installs.
In Mac there used to be Carbon Copy Cloner, which could clone a system from one partition to another to back up what was then an expensive OSX . . . but in linux, as it is free, and another version coming along, never had need to clone one system to another partition. I just run fresh installs in formatted partitions . . . now on this machine 8 distros?? One system handles grub for bootloading, no refind . . . just another layer of complication.
You can boot the kernel on sda7 using built-in commands within Grub.
It’s a fiddly process but certainly possible.
I can provide generic commands if required.
Is there a specific reason for two identical systems on one disk?
Are you intending to upgrade the copy to 26.04 and keep the original as a fail-safe backup?
We don’t need the GRUB boot loader on EFI-based systems, since an EFI-boot loader stub is built into the Linux kernel itself. All we need is a boot manager to hand off control to the Linux kernel that we want to boot. The Linux kernel will then load itself into memory and execute, instead of depending on an external boot loader like GRUB.
I have two drives both with multiple installs, some obsolete & I need to delete from UEFI entries as non-working.
I rename grub in /etc/default/grub like this: GRUB_DISTRIBUTOR=noble-a
After a grub install, then I get another UEFI boot entry. It used to be that something in the .efi boot files was hard coded so only /boot/efi/EFI/ubuntu/grub.cfg worked. Or only one default even though my new entry had its own grub.cfg. But it now seems to work.
I added rEFInd to my Ventoy flash drive.
I have these in by sda drive, but others in NVMe drive.
Ventoy seemed to find all my entries, several did not work which I expected. Some entries with efi and some directly with kernel.
I prefer grub as I can turn os-prober off. It takes a long time when multiple installs. And since many installs obsolete, I can only add the working installs to 40_custom.
I thought rEFInd was a great utility for 2 reasons:
It would detect other operating systems installed on the same machine, and add them to the GRUB boot menu, allowing me to choose which OS to boot into. I have since learned that this is NOT true, and that ‘os-prober’ may perform this function (if it is enabled). Is this true ?
My understanding is that certain files in the /boot directory (and possible others) have to be in specific locations (addresses) within the ubuntu partition, or grub won’t load them ?? I thought rEFInd wouldn’t care where they were specifically located, as it would search for, and execute, these files within the partition. Is this true ?? If not, than I don’t see the purpose of rEFInd, other than eye candy.
Why the ‘2nd’ reason is important to me: I set up a dual boot (Windows & Ubuntu) laptop for my wife. I want to replace the laptop’s ubuntu 20.04 with a gparted copy of ubuntu unity 26.04 from my desktop. I thought, hopefully, rEFInd wouldn’t care if the pertinent boot files would no longer be in their exact location. Is my theory of replacing ubuntu 20.04 with ubuntu unity 26.04 via a simple gparted copy just a dream??
Is there anything worthwhile here - or should I just purge rEFInd from my system?
So, back to my original post: My desktop is running ubuntu unity 24.04 on an internal SSD. I will be updating this to ubuntu unity 26.04 (just released).
I have an ESATA on my desktop which serves a as backup for my ubuntu unity 24.04. I can boot off the ESATA if I BIOS Disable the internal SSD, and Enable the ESATA. On the ESATA I will gparted copy the newly created ubuntu unity 26.04 onto a 2nd partition. So the ESATA will have 24.04 and 26.04, and I would like to be able to choose which to boot from. rEFInd did not solve this problem for me.
yancek: “How did you verify that you were booted to the Ubuntu on sda2” - The partitions have different labels.
Dennis_N: Maybe you did not edit /etc/fstab on sda7 to change the UUID to that of the new root file system? You are right, I never thought to do this.
If you included the ESP along with all the other relevant partitions… Nowadays only root but there’s nothing wrong in a separated /home (not so useful as it used to be) and the old days swap partition. That works most of times without any additional user intervention. I’ve done several of those imaging processes and the “copy” booted perfectly. Granted, all of them were in the same machine, different (often replaced/upgraded) drive.
rEFInd is a brilliant piece of software. Rod Smith is indeed pretty smart and gained his place in history. That said, as already commented, rEFInd was designed with a purpose in mind and said purpose is kinda moot since many years ago. It has other usages like the one @oldfred commented above, himself also with a solid place in history and an expert that helped countless users with boot issues.
That was relevant for legacy BIOS. It is not relevant for UEFI, so any EFI bootloader - and GRUB is EFI bootloader - will have access to the whole device.
No, it would not. It would detect EFI executable files located in well known directories (or directories specified in the rEFInd configuration). With some luck, running these executable files will have the effect of booting other operating systems, but it is not guaranteed.
You can create a configuration file similar to grub.cfg and specify the exact executable files and give them pretty names. But then you can also do it with GRUB too
If you are were booting from Grub on the original Ubuntu (sda2) with an entry for both Ubuntu/sda2 and the copy of Ubuntu/sda7, the entries in the grub.cfg menu would need to show a different UUID for the different menuentries. You need to verify that the UUID for sda7 Ubuntu is the same as shown by the output of the lsblk command posted above in whatever configuration file rEfind uses. You also must have the correct UUID for sda7 in the /etc/fstab file on sda7.
