While a BBS menu is a perfectly valid method of opening a boot menu, it requires a specific keystroke at the right time to invoke. Otherwise, whatever the default OS is set as top priority in UEFI BIOS setup and efibootmgr boots right up, no questions asked. With Grub, a boot menu appears by default. TW’s BLS default shouldn’t be applied automatically when the installer finds existing entries on the ESP. The installer should ask what bootloader to install, explaining the characteristics that differentiate them. If it’s not doing that, it’s a bug that needs fixing.
2 Likes
I agree, that would be nice, but it needs to be reported first.
However, GRUB2 using BLS should still be capable of handling Linux installs whose EFI binaries live under /boot/efi/EFI/. Support for chainloading would be very useful.
A manually added .conf entry certainly should work.I think it failed earlier in the topic because the kernel and initrd have to be referenced explicitly. So something like this
title Ubuntu 24.04 LTS
version 6.8.0-31-generic
linux /boot/vmlinuz-6.8.0-31-generic
initrd /boot/initrd.img-6.8.0-31-generic
options root=UUID=9f2c6d4e-8b3a-4b7e-a4f1-2d6f9a1c8e21 ro quiet splash
where the correct root file system is referenced. Maintaining that manually as an external Linux install would be difficult. That’s why chainloading capability would be better.
Just reported: bug 1257510.
1 Like
@deano_ferrari @mrmazda it’s the default as explained on the mailing List, no dual boot/multiboot etc…
Users need to understand that Tumbleweed is a development platform and things do change.
That may well be, but some TW users only use it because Leap 16 is not supported by their hardware, and recently switched due to that limitation, so not yet well understanding of how TW works.
1 Like
Very, very “exactly”.
No I get that. However, as Felix mentioned a bug report is warranted with respect to it being made default. I agree that there could be basic automated checks made to prevent it when multi-boot environments detected.
Also, as I mentioned in my last post it can be made to boot other Linux distros as explained (but a pain to create the .conf files manually).
1 Like
@deano_ferrari
Hi
I managed to get entries into the Grub selection screen by creating in
/boot/efi/loader/entries two files
system-opensuse-tumbleweed-6.xx.8-1-default-1.conf
where “xx” is a higher number than in the current entries resulting in AV Linux and Ubuntu are on top of the list.
I used your suggested entries as place holders => so far so good
Where do I get the correct entries from , pointing to Ubuntu / AV Linux
Following the conversation It appears to be the non-dual-boot is a bug. To get a fix could take a long time.
It would help me considerably to get it going.
I am on e of them !
Having had my experience with 16.0 … understanding runs thin
I am running suse since 2004 and was very happy with the stability of the system.
Only two hitches I can remember one was around 2005 where half a year later a new (I guess unscheduled) release came out and a bit later when KDE introduced Plasma.
With the 16.0 experience I was close to jumping ship.
I’m not currently using GRUB BLS (I tried it briefly but quickly reverted to classic GRUB on my Slowroll install).
Anyway, from TW, what is shown by lsblk -f?
That should show device partitions and UUID info.
Mount the other Linux partition from Tumbleweed eg
sudo mount /dev/nvme0n1p6 /mnt # Ubuntu root
ls /mnt/boot
Look for vmlinuz-* and initrd.img-* files.
These paths will be used in the BLS entry relative to the root filesystem eg
linux /boot/vmlinuz-6.x.x-generic
initrd /boot/initrd.img-6.x.x-generic
Create the BLS entry suing that information eg
title Ubuntu 24.04 LTS
version 24.04
linux /boot/vmlinuz-6.x.x-generic
initrd /boot/initrd.img-6.x.x-generic
options root=UUID=1546223c-8376-4726-b262-162c6577d01f ro quiet splash
Hopefully, that gives the basic idea. Uncharted territory for me, so I’ve had to gleam information from various Fedora info:
If it all gets too much you can always switch back to classical grub again.
1 Like
Hi
@ozotto stop creating more issues for your self, grub-bls/snapper/btrfs are intertwined, if you want a multiboot system then you need to use grub-efi, plain and simple… either sort that (I would not recommend) or re-install.
1 Like
Ok done that
# Test Test
# ubuntu-studio created 30th Jan 2026 by Otto Hase
# test if boot menue entries can be created for dual boot
#
#
#For Ubuntu
# title Ubuntu Studio 24.04
#efi /EFI/ubuntu/grubx64.efi
#
title Ubuntu Studio
version 6.14.0-37-generic
linux /boot/vmlinuz-6.14.0-37-generic
initrd /boot/initrd.img-6.14.0-37-generic
options root=UUID=9f2c6d4e-8b3a-4b7e-a4f1-2d6f9a1c8e21 ro quiet splash
#
# vmlinuz-6.14.0-37-generic
#initrd.img-6.14.0-37-generic
# End
#
When selecting ubuntu, grub comes back with "you need to load the kernel first " ?
I have no intention to make life more difficult …
question : how long will it take to fix bug 1257510
It’s not really a bug - more a lack of a feature in design. Don’t dwell on it. You can always switch to grub-efi as already mentioned.
1 Like
I’m about to go out (late morning here), will return to this later. Interesting result though.
@ozotto what is hard about pressing the BIOS boot menu key and selecting your boot preference? If you don’t want to do that, then just select one of the other systems as primary boot and use that grub menu? Else switch to grub-efi and see if that works/helps? Bear in mind your boot from snapshots etc may be broken.
… that sounds like NewZealand
Anyway, I think I know the solution to the problem 
but don’t know how to get there 
Grub Does not know which partition to look at;
So , something like this could make it work. ( specifically it did not work)
title Ubuntu Studio
version 6.14.0-37-generic
mount /dev/nvme0n1p6 /mnt
linux mnt/boot/vmlinuz-6.14.0-37-generic
initrd nmt/boot/initrd.img-6.14.0-37-generic
I guess I used the wrong commands, but along those lines it will work
I’m out currently, but that is why the UUID is needed. 
uuid ? … booting up to Grub is within a specific partition. For dual boot Grub needs to know in which partition the other system lives. So within a/my system the partition names are unique.
So from my understanding the pointer starts with partition name then / then boot
Yes, I think what is missed here is that with this approach the kernel and initrd need to be in the openSUSE /boot directory (as that is where GRUB will expect it to be located).
Anyway, back in post 11 I had suggested chainloading, but now I’m not sure if you tried this explicitly?
Ubuntu grubx64.efi exists in this location right?
ls /boot/efi/EFI/ubuntu/grubx64.efi
Let me know if we’re covering old ground here.