Now, I can’t load the first system.
The problem is: the first EFI partition is still loading the second system
What I have already tried:
Adding entries to efibootmgr manually - no effect, all the entries are booting the second system
Adding entry to grub - couldn’t do it due to problem with composefs
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
/usr/bin/grub2-probe: error: failed to get canonical path of `composefs'.
I’ve tried using rEFInd - it still didn’t detect my first system
Here is some info about my system (I am booted from the second one, the first three are respectively efi, boot and root partitions from my first system):
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
zram0 251:0 0 8G 0 disk [SWAP]
nvme0n1 259:0 0 931.5G 0 disk
├─nvme0n1p1 259:1 0 600M 0 part
├─nvme0n1p2 259:2 0 2G 0 part
├─nvme0n1p3 259:3 0 200G 0 part
├─nvme0n1p4 259:4 0 900M 0 part /boot/efi
├─nvme0n1p5 259:5 0 2G 0 part /boot
└─nvme0n1p6 259:6 0 726G 0 part /var/home
/var
/sysroot/ostree/deploy/fedora/var
/sysroot
/etc
Can you please advise me, what is the best solution to build
The EFI spec stipulates “one EFI partition per drive” for removable media only.
So multiple EFI partitions wouldn’t be expected to work on a USB stick, but it should be supported on a fixed SSD.
However, we know from various issues here that BIOSes can be quirky about booting, and don’t stick rigidly to spec. So it could be that this particular BIOS doesn’t like multiple EFIs.
But if rEFInd also can’t boot one of the installs, that suggests that it’s not just the BIOS causing the problem here.
Can you show the current output of efibootmgr ?
Atomic Desktops don’t use grub2-mkconfig, they use a static GRUB file.
However, if both your EFI partitions end up booting to the same Kinoite install, what we should look at is the stub GRUB config in the EFI partition (as opposed to the one in the boot partition).
Can you show:
sudo cat /boot/efi/EFI/Fedora/grub.cfg
And then mount the other EFI partition to compare the file there:
mkdir -p ~/mnt/otherefi
sudo mount /dev/nvme0n1p1 ~/mnt/otherefi
sudo cat /mnt/otherefi/EFI/Fedora/grub.cfg
Efibootmgr output using only the efi partition from the first system (the one that is NOT booting). I’ve tried adding manually the second system, but it disappears after reboot
Then, about grub.cfg file, it seems that my system using a different location
$ sudo cat /boot/efi/EFI/Fedora/grub.cfg
cat: /boot/efi/EFI/Fedora/grub.cfg: No such file or directory
The file from other partition:
$ sudo cat ~/mnt/otherefi/EFI/Fedora/grub.cfg
if [ -e (md/md-boot) ]; then
# The search command might pick a RAID component rather than the RAID,
# since the /boot RAID currently uses superblock 1.0. See the comment in
# the main grub.cfg.
set prefix=md/md-boot
else
if [ -f ${config_directory}/bootuuid.cfg ]; then
source ${config_directory}/bootuuid.cfg
fi
if [ -n "${BOOT_UUID}" ]; then
search --fs-uuid "${BOOT_UUID}" --set prefix --no-floppy
else
search --label boot --set prefix --no-floppy
fi
fi
if [ -d ($prefix)/grub2 ]; then
set prefix=($prefix)/grub2
configfile $prefix/grub.cfg
else
set prefix=($prefix)/boot/grub2
configfile $prefix/grub.cfg
fi
boot
Thanks. efibootmgr reads the BIOS NVRAM, not the EFI partitions. So what we’re seeing here is that both the “Fedora” entries in the NVRAM point to the same EFI partition (the c5cd... ).
It’s not so much that “the first EFI partition is still loading the second system”, it’s that both NVRAM entries load the second system.
Weird, I wonder what is doing this.
That’s weird! Try sudo tree /boot/efi/EFI to see if we can find any GRUB config there?
Ah, OK, so rEFInd has overwritten the EFI partition of your second Kinoite install. That feels a bit messy, but obviously that’s not the one that you have problems booting.
Why isn’t booting from GRUB working?
Thinking about this more, the difficulty may be in your “other” Fedora/grub.cfg file.
The EFI grub.cfg on a non-Atomic Fedora install is very simple - effectively it just chains to the config on the boot partition of that install, based on a hard-coded partition UUID. Here’s mine:
But the Atomic EFI grub.cfg file you have is more complicated. In some cases it searches for a partition by label (search --label boot ...). And that may go wrong if you have two boot partitions from two installs.
If GRUB could see a ${BOOT_UUID}, then that would fix the problem, but I don’t know the details of how this is supposed to work, so let’s see if someone has better advice.
Why isn’t booting from rEFInd working?
rEFInd may be able to bypass the above problem by finding Linux kernels directly.
You may need to enable this by adding a line to your refind.conf (as shown in your directory tree above) -
scan_all_linux_kernels true
That should then be able to find the kernel of your “first” Kinoite, but I’m not sure if it will be flawless (because it won’t see parameters from that Kinoite’s boot-directory GRUB config).
So, am I right to conclude that the simpler solution would be the following: instead of using 2 Kinoite, use one Kinoite and one Fedora KDE. And during the Fedora KDE installation, I should let it overwrite EFI partition and then use it’s GRUB to control the boot process?
Maybe, but I don’t know whether it would be easy to add the Kinoite install to KDE’s GRUB config. From a couple of issues I’ve seen here, it seems that grub-mkconfig isn’t finding other Linux installs that it should (example with Fedora & Nobara).
On your current setup, a slightly hacky thing you could try is to add this as the first line of the Fedora/grub.cfg on the first EFI partition:
set BOOT_UUID=4fcd507f-af2b-4574-a8d4-4ade52070c32
(but replace the UUID with the UUID of the actual boot partition of the first Kinoite install).
I’m not sure though whether that would ever get overwritten by a system update.
Your second system appears to boot correctly now using rEFInd? If so, then you should still be able to boot into it by selecting rEFInd from the BIOS’s boot menu.
Edit: actually no, because rEFInd probably just works now by chaining to the first Kinoite’s EFI partition.
I think you would need an extra step, probably best done from a live USB.
Edit grub.cfg in EFI partition 1 as already mentioned
Remove the rEFInd files from EFI partition 2
Copy the contents of EFI partition 1 to EFI partition 2
Edit the grub.cfg in EFI partition 2 to include set BOOT_UUID=xxx (insert UUID of your second boot partition here).
Then use efibootmgr to remove the rEFInd entry, and add an entry for the Fedora shimx64.efi on EFI partition 2, so you have boot entries for the two separate EFI partitions.
$ efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0002,0000,0001
Boot0000* Fedora C HD(1,GPT,c5cd708b-e575-420b-97e5-773acc91181c,0x800,0x12c000)/EFI\fedora\shimx64.efi
Boot0001* Fedora W HD(4,GPT,6e9cda0d-79ce-4993-bb52-a99d24ddd268,0x1952c800,0x1c2000)/\EFI\fedora\shimx64.efi
Boot0002* Fedora HD(1,GPT,c5cd708b-e575-420b-97e5-773acc91181c,0x800,0x12c000)/\EFI\fedora\shimx64.efi0000424f
First EFI (from system not booting)
$ $ cat ~/mnt/otherefi/EFI/fedora/grub.cfg
set BOOT_UUID=001a51f0-d556-495a-b8fc-31c69566afa2
if [ -e (md/md-boot) ]; then
# The search command might pick a RAID component rather than the RAID,
# since the /boot RAID currently uses superblock 1.0. See the comment in
# the main grub.cfg.
set prefix=md/md-boot
else
if [ -f ${config_directory}/bootuuid.cfg ]; then
source ${config_directory}/bootuuid.cfg
fi
if [ -n "${BOOT_UUID}" ]; then
search --fs-uuid "${BOOT_UUID}" --set prefix --no-floppy
else
search --label boot --set prefix --no-floppy
fi
fi
if [ -d ($prefix)/grub2 ]; then
set prefix=($prefix)/grub2
configfile $prefix/grub.cfg
else
set prefix=($prefix)/boot/grub2
configfile $prefix/grub.cfg
fi
boot
$ sudo cat /boot/efi/EFI/fedora/grub.cfg
set BOOT_UUID=8abd5ab2-d443-4fe9-b3f2-a74cec328086
if [ -e (md/md-boot) ]; then
# The search command might pick a RAID component rather than the RAID,
# since the /boot RAID currently uses superblock 1.0. See the comment in
# the main grub.cfg.
set prefix=md/md-boot
else
if [ -f ${config_directory}/bootuuid.cfg ]; then
source ${config_directory}/bootuuid.cfg
fi
if [ -n "${BOOT_UUID}" ]; then
search --fs-uuid "${BOOT_UUID}" --set prefix --no-floppy
else
search --label boot --set prefix --no-floppy
fi
fi
if [ -d ($prefix)/grub2 ]; then
set prefix=($prefix)/grub2
configfile $prefix/grub.cfg
else
set prefix=($prefix)/boot/grub2
configfile $prefix/grub.cfg
fi
boot
is there a bootuuid.cfg file anywhere in the EFI partition? (Though if there was, there probably would never have been an issue.)
What is happening in /grub/grub2.cfg in each boot partition (not EFI partition). Does that have a reference to the UUID of the corresponding root partition, or does it try to dynamically discover it (and potentially find the wrong one)?
