Yes, sometimes ago I have 2 Garuda DE’s on sda and 4 on sdb.
I never knew what is what in refind (short try and travel 
). With grub and custom.cfg no problem.
Why do the work when you can do it easily.
Honestly I do not regret it because I learned a lot! And now I know my /boot/efi/EFI/ directory like the back of my hand. 
1 Like
Everything I would need to know about it doesn't fit on the back of my hand. Unfortunately
2 Likes
Meanwhile I found this:
Gentoo Forums :: View topic - os-prober creating duplicate entry for main linux system
TL;DR
a partition can be blacklisted from os-prober so it doesn't show up twice
perhaps on EFI there's no need for a GRUB entry, but I don't have EFI and don't know jack about it.
edit: posting this just in case someone is still on BIOS booting, my previous comments were due to my misunderstanding that this case is about an EFI boot.
4 Likes
The grub menu is auto-generated, so you have to identify the real reason for the double menus and eliminate it, if it's actually a bug (you never know...).
If you want to find the actual problem, we need more info.
sudo grep "menuentry_id_option \|root=UUID" /boot/grub/grub.cfg
sudo findmnt --all --real
ls /etc/grub.d/
pacman -Qo /etc/grub.d/*
pacman -Qs grub
2 Likes
Actually, it should. Removing the os-prober is likely to eliminate the multiple entries problem of OP - and os-prober is completely redundant given a rEFInd setup.
BTW - the difficulties on multiple Garuda usage exist only if both of them are using grub to boot. The example screenshot I showed had 2 Garuda builds, but one was NOT on grub - and judicious partition naming makes multiple entries easy to distinguish from the ‘startup’ line displayed on icon selection in rEFInd. I find rEFInd ‘complications’ MUCH easier to deal with than grub ones - much less editing and arcane commands to learn…
I like your choices of Garuda icons to delineate the difference!
Hey guys, appreciate all the tips here. Been trying many things so sorry for the late update. I tried modifying many files so far including the os prober lists and other grub config files but these either get rid of Windows boot entry as well or are only temporary until grub is regenerated in an update. Maybe I have missed something though as I continue to look for a solution. This problem was, however, caused after I ran the update command where the terminal outputted some text along the lines of finding snapshots and Garuda on /dev/sda2.
I also gave refind a go and enjoyed it after theming it tbh. With refind I would however like to keep both instances as one boots directly and one boots into the grub menu for snapper support etc. The problem is, that after setting up refind I would get some random KDE crashes but no logs for whatever reason. So for now I have uninstalled refind and still have the two Garuda entries. Would my best bet be to simply remove the os prober list and make a custom entry for my windows installation? I'm also wondering if this is simply a grub bug as this didn't happen until after a recent update. Thanks for any advice.
sudo grep "menuentry_id_option \|root=UUID" /boot/grub/grub.cfg
sudo findmnt --all --real
ls /etc/grub.d/
pacman -Qo /etc/grub.d/*
pacman -Qs grub
[dragon] empower adamj:
menuentry 'Garuda Linux' --class garuda --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-95b636ca-42a5-47b4-9b7a-038581af6cdf' {
linux /@/boot/vmlinuz-linux-cachyos root=UUID=95b636ca-42a5-47b4-9b7a-038581af6cdf rw rootflags=subvol=@ quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 resume=UUID=41193397-191d-45b5-8c2b-405cf71e73b2 loglevel=3
submenu 'Advanced options for Garuda Linux' $menuentry_id_option 'gnulinux-advanced-95b636ca-42a5-47b4-9b7a-038581af6cdf' {
menuentry 'Garuda Linux, with Linux linux-cachyos' --class garuda --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-cachyos-advanced-95b636ca-42a5-47b4-9b7a-038581af6cdf' {
linux /@/boot/vmlinuz-linux-cachyos root=UUID=95b636ca-42a5-47b4-9b7a-038581af6cdf rw rootflags=subvol=@ quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 resume=UUID=41193397-191d-45b5-8c2b-405cf71e73b2 loglevel=3
menuentry 'Garuda Linux, with Linux linux-cachyos (fallback initramfs)' --class garuda --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-cachyos-fallback-95b636ca-42a5-47b4-9b7a-038581af6cdf' {
linux /@/boot/vmlinuz-linux-cachyos root=UUID=95b636ca-42a5-47b4-9b7a-038581af6cdf rw rootflags=subvol=@ quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 resume=UUID=41193397-191d-45b5-8c2b-405cf71e73b2 loglevel=3
menuentry 'Garuda Linux (on /dev/sda2)' --class garuda --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-95b636ca-42a5-47b4-9b7a-038581af6cdf' {
linux /@/boot/vmlinuz-linux-cachyos root=UUID=95b636ca-42a5-47b4-9b7a-038581af6cdf rw rootflags=subvol=@ quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 resume=UUID=41193397-191d-45b5-8c2b-405cf71e73b2 loglevel=3
submenu 'Advanced options for Garuda Linux (on /dev/sda2)' $menuentry_id_option 'osprober-gnulinux-advanced-95b636ca-42a5-47b4-9b7a-038581af6cdf' {
menuentry 'Garuda Linux (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/@/boot/vmlinuz-linux-cachyos--95b636ca-42a5-47b4-9b7a-038581af6cdf' {
linux /@/boot/vmlinuz-linux-cachyos root=UUID=95b636ca-42a5-47b4-9b7a-038581af6cdf rw rootflags=subvol=@ quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 resume=UUID=41193397-191d-45b5-8c2b-405cf71e73b2 loglevel=3
menuentry 'Garuda Linux, with Linux linux-cachyos (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/@/boot/vmlinuz-linux-cachyos--95b636ca-42a5-47b4-9b7a-038581af6cdf' {
linux /@/boot/vmlinuz-linux-cachyos root=UUID=95b636ca-42a5-47b4-9b7a-038581af6cdf rw rootflags=subvol=@ quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 resume=UUID=41193397-191d-45b5-8c2b-405cf71e73b2 loglevel=3
menuentry 'Garuda Linux, with Linux linux-cachyos (fallback initramfs) (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/@/boot/vmlinuz-linux-cachyos--95b636ca-42a5-47b4-9b7a-038581af6cdf' {
linux /@/boot/vmlinuz-linux-cachyos root=UUID=95b636ca-42a5-47b4-9b7a-038581af6cdf rw rootflags=subvol=@ quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 resume=UUID=41193397-191d-45b5-8c2b-405cf71e73b2 loglevel=3
menuentry 'Memory Tester (memtest86+) (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/@/boot/memtest86+/memtest.bin--95b636ca-42a5-47b4-9b7a-038581af6cdf' {
menuentry 'Windows Boot Manager (on /dev/sdb1)' --class windows --class os $menuentry_id_option 'osprober-efi-CE50-7D14' {
menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' {
TARGET SOURCE FSTYPE OPTIONS
/ /dev/sda2[/@] btrfs rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvoli
├─/run/user/1000/doc
│ portal fuse.porta rw,nosuid,nodev,relatime,user_id=1000,group_id=1000
├─/home /dev/sda2[/@home] btrfs rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvoli
├─/root /dev/sda2[/@root] btrfs rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvoli
├─/srv /dev/sda2[/@srv] btrfs rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvoli
├─/var/cache /dev/sda2[/@cache] btrfs rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvoli
├─/var/tmp /dev/sda2[/@tmp] btrfs rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvoli
├─/var/log /dev/sda2[/@log] btrfs rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvoli
└─/boot/efi /dev/sda1 vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shor
.rwxr-xr-x 8.9k root 17 Jan 12:36 00_header
.rwxr-xr-x 12k root 17 Jan 12:36 10_linux
.rwxr-xr-x 13k root 17 Jan 12:36 20_linux_xen
.rwxr-xr-x 12k root 17 Jan 12:36 30_os-prober
.rwxr-xr-x 1.4k root 17 Jan 12:36 30_uefi-firmware
.rwxr-xr-x 700 root 7 Feb 17:01 35_fwupd
.rwxr-xr-x 214 root 17 Jan 12:36 40_custom
.rwxr-xr-x 215 root 17 Jan 12:36 41_custom
.rwxr-xr-x 26k root 14 Dec 2021 41_snapshots-btrfs
.rwxr-xr-x 1.2k root 12 Jun 2021 60_memtest86+
.rwxr-xr-x 487 root 3 Feb 05:35 61_custom_leave_options
.rw-r--r-- 483 root 17 Jan 12:36 README
/etc/grub.d/00_header is owned by grub 2:2.06-4.1
/etc/grub.d/10_linux is owned by grub 2:2.06-4.1
/etc/grub.d/20_linux_xen is owned by grub 2:2.06-4.1
/etc/grub.d/30_os-prober is owned by grub 2:2.06-4.1
/etc/grub.d/30_uefi-firmware is owned by grub 2:2.06-4.1
/etc/grub.d/35_fwupd is owned by fwupd 1.7.5-1
/etc/grub.d/40_custom is owned by grub 2:2.06-4.1
/etc/grub.d/41_custom is owned by grub 2:2.06-4.1
/etc/grub.d/41_snapshots-btrfs is owned by grub-btrfs 4.11-1
/etc/grub.d/60_memtest86+ is owned by memtest86+ 5.31b-1
/etc/grub.d/61_custom_leave_options is owned by garuda-common-settings 2.5.4-2
/etc/grub.d/README is owned by grub 2:2.06-4.1
local/grub 2:2.06-4.1
GNU GRand Unified Bootloader (2)
local/grub-btrfs 4.11-1
Include btrfs snapshots in GRUB boot options
local/grub-garuda 2.06-1
meta pkg for grub
local/grub-theme-garuda-dr460nized r2.49d1e5e-1
Garuda Dr460nized grub theme
local/python-markdown 3.3.6-3
Python implementation of John Gruber's Markdown.
local/snapper-support 1.1.0-1
Support package for enabling Snapper with snap-pac and grub-btrfs support
local/update-grub 0.0.1-7
Simple wrapper around grub-mkconfig
You know what? I’ve been using rEFInd for about six weeks now and this did not occur to me. It seems so obvious, now that you mention it! I think I’ll make this change myself now, so my grubs can’t see eachother (nothing like a nice clean grub menu, as I’m sure OP agrees!).
I was determined to preserve the grub boot, because the Garuda devs went to the bother of setting up the custom grub screen with the snapshot interface and everything. Not only is there a utility to being able to access the snapshots so easily, I happen to think the custom grub menu itself is pretty cool (my two installs each have a different one, actually).
Pressing the “delete” key and taking an entry off of your boot screen does not actually delete it, as counter-intuitive as that may seem. It only hides it from view. Any boot options rEFInd is able to discover that you choose to hide away in this manner can still be accessed easily from the menu below the icons. So if you wanted to boot from an EFI stub but keep a proper grub boot tucked away in case of emergency, that is supported.
That is puzzling! Logically it seems like that should not be related, since rEFInd is just a boot manager and shouldn’t be doing anything at all once you get to your display manager to sign in. Then again, for all I know there could be more to it. 
Do you boot Windows from grub? Just curious.
I noticed you switched to a different kernel. Did the extra boot option coincide with updating grub after the kernel switch, or have you been off the zen kernel for a while?
3 Likes
Had to Google how to do this lol as I'm not familiar but yeah this worked perfectly thank you! Ran the command blkid and saw /dev/sda2 which was my problem.and added that uuid at that partition with following that link and now after an update and reboot there's only the one Garuda instance. So thanks!
2 Likes
I haven’t set this up yet, but it’s been on my todo list… refind-btrfs/README.md at master · Venom1991/refind-btrfs · GitHub Its supposed to add the same functionality of grub-btrfs for detecting snapshots and adding to the refind boot options for an entry. The annoying thing is that it currently seems to require creating a manual boot stanza instead of leveraging the scan_dirs automatically.
3 Likes
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.