Hi, in my system, I have 3 EFI partitions, one for Windows, one for Manjaro and one for Opensuse.
Both Manjaro and Opensuse are installed in a single BTRFS partition.
os-probe detects only Windows (and any other Debian based distros that I’ve tested in the past).
By the way, the opposite is also true. Opensuse boots Windows (or any other Debian based distros), detects and show Manjaro in the grub menu, but can’t boot it.
Is it a BTRFS issue? Is there anything that can be done from Manjaro side? Thanks!
That’s a lot of EFI partitions… I personally just use the Window’s EFI partition, and mount it to /boot/EFI on all of my distros. Don’t know if having 3 EFI partitions is causing the issue or not.
Thanks for joining. It’s the only way to boot Manjaro and Opensuse, otherwise I can just boot the last installed one. I know both grub versions were highly customized though.
Why not? I just don’t need to use a separate home and/or boot partition for them. (just to make it clear, I use one BTRFS volume for each of them, so 2 different partitions).
Yeah, the grub menu from opensuse detects and boots Windows. Manjaro does the same.
I read your initial post as sharing the same volume. My mistake.
To better understand, you’re saying if you use Manjaro’s Grub menu,
you can boot into Manjaro
you can boot into Windows
you cannot boot into openSUSE
While with openSUSE’s Grub menu,
you can boot into openSUSE
you can boot into Windows
you cannot boot into Manjaro
Is there any warning generated by update-grub?
It might have something to do with being on the same Btrfs partition.
What does your generated grub.cfg show? You might have to paste a link to pastebin or similar, since it’ll be a very long output. Or just paste the relevant parts.
Yes, but Manjaro does not even show Opensuse as a boot option. Opensuse shows Manjaro, but can’t boot it. I’ll copy the error message later.
A gerar ficheiro de configuração grub...
Tema encontrado: /usr/share/grub/themes/manjaro/theme.txt
Imagem Linux encontrada: /boot/vmlinuz-5.15-x86_64
Imagem initrd encontrada: /boot/intel-ucode.img /boot/initramfs-5.15-x86_64.img
Found initrd fallback image: /boot/initramfs-5.15-x86_64-fallback.img
Imagem Linux encontrada: /boot/vmlinuz-5.14-x86_64
Imagem initrd encontrada: /boot/intel-ucode.img /boot/initramfs-5.14-x86_64.img
Found initrd fallback image: /boot/initramfs-5.14-x86_64-fallback.img
Aviso: os-prober será executado para detectar outras partições de arranque.
A sua saída será usada para detectar binários de arranque nessas partições e criar novas entradas.
Encontrado Windows Boot Manager em /dev/nvme0n1p1@/efi/Microsoft/Boot/bootmgfw.efi
Encontrado Kali GNU/Linux Rolling em /dev/nvme0n1p8
A adicionar entrada de menu para UEFI Firmware Settings ...
Detecting snapshots ...
Info: Separate boot partition not detected
Found snapshot: 2021-09-30 21:44:23 | timeshift-btrfs/snapshots/2021-09-30_21-44-22/@
Found snapshot: 2021-09-30 12:07:44 | timeshift-btrfs/snapshots/2021-09-30_12-07-44/@
Found snapshot: 2021-09-30 09:23:00 | timeshift-btrfs/snapshots/2021-09-30_09-23-00/@
Found 3 snapshot(s)
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: aviso: tipo de dispositivo nvme0n1 desconhecido.
Please, let me know if I need to translate it into English, but I think you can follow the output.
And my SSD is this. For a bit of privacy, I’ve hidden the name of some partitions.
There’s way too much going on: you have 4 EFI partitions and 3 Btrfs partitions (of which are further divided into subvolumes for each Linux installation?), and it appears you’re actually quad-booting?
From what I can gather, you need to decide which EFI should be used as your motherboard’s default boot selection, and whichever one that is, use the distro’s Grub generator to make an all-encompassing boot menu (Windows 10, Kali, Manjaro, and openSUSE).
Otherwise, a simpler alternative is to rely on your computer’s hot keys (such as ESC, DEL, F1, F2, F9, F10, etc) to select the EFI boot loader when starting your computer, and use that instead of a Grub menu:
Windows 10 EFI
Kali EFI
Manjaro EFI
openSUSE EFI
It won’t look as fancy compared to a themed Grub menu, but it will work just the same.
Someone else might be able to offer a better solution based on your partition layout and Grub issues.
Yeah, there are 4 OS: Windows (EFI + NTFS), Manjaro (EFI + BTRFS), Kali (or Debian-based) (EFI + BTRFS), SUSE (EFI + BTRFS). Each system works perfectly. The issue is only the grub/boot.
If I use just one EFI, grub is overwritten. Manjaro grub cannot boot SUSE, and vice-versa. The problem is that this does not work: “use the distro’s Grub generator to make an all-encompassing boot menu”. None Debian system grub can boot neither Manjaro nor SUSE.
It’s what I used to do with a simple dual-boot setup between Windows and Linux, even back on the MBR days if dealing with two different drives. The neat thing with EFI is you don’t need different drives, just separate EFI boot loaders and/or EFI partitions.
You lose out on the fancy colors and themes. Not so much a big deal in my opinion, but I can understand the desire for something that’s more “sleek” and professional-looking.
My hunch is there’s something going on with Btrfs and auto-detecting / properly configuring the other Linux installations’ boot entries (which are installed on different Btrfs partitions/subvolumes).
It might also explain why listing and booting Windows works, regardless of which Grub menu you display (Manjaro’s, openSUSE’s, etc)
Well, although my configuration changed, I managed the situation creating (adding) a file /boot/grub/custom.cfg pointing the grub entries to the full path of grub.cfg on other distros. Note that the path differs as per BTRFS distro-specific layout.
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "Kali" {
insmod part_gpt
insmod btrfs
insmod ext2
set root='hd1,gpt8'
configfile /@rootfs/boot/grub/grub.cfg
}
menuentry "Manjaro" {
insmod part_gpt
insmod btrfs
insmod ext2
set root='hd1,gpt10'
configfile /@/boot/grub/grub.cfg
}
If you are in the same situation, just choose the menuentry name, set root to the grub.cfg file. It should work, at least, on any Arch-based distro.
The advantages of this method:
It will load full grub menu of the other distro (with recovery, snapshots entries, etc.) on-the-fly during boot
It is independent of any changes made in the distros (like updating kernels or modules)
You don’t even need re-running grub-mkconfig , since the default /etc/grub.d/41_custom adds the necessary source statement to the generated configuration file: it’s set and forget!
I’m marking this thread as solved based on the above statement.
Please make sure you always mark your threads as solved if you happen to find a solution, even by yourself. You can do so by clicking on the hamburger icon (similar to the ellipsis mark). The solution option is hidden there.