rEFInd / Discussion / General Discussion: Multibooting with Opensuze Thumbleweed

Alberto - 2025-04-27

HI, I've installed since years Refind , works fine and recently I have adde Thumbleweed in addition to Windows, Linux Mint, Debian and Redhat.
To detect Thumbleweed kernels, I have added in conf file follow_symlinks for this purpose. It works for Tubleweed.
But I have next distro distro boot folder parsed with mixed simlink / non simlink kernels: It's Linux Mint 22 (based on Ubuntu 24). When parsing the /boot folder, it detect vmlinuz and vmlinuz.old simlinks. Well but it creates a new entry and surprise it didn't attributes it to Linux mint but to next entry wich is Debian.
How to solve the problem (grouping simlinked and not simlinked) to Mint correctly or exclude simlinked kernels for Linux Mint only ?
I've done logs level 4 if need, same result for version 0.14 and 0.14.2

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dakanji - 2025-04-30

You could try disabling follow_symlinks and move your Tumbleweed item to a manual stanza.

I think Manual Stanzas may follow symlinks by default as there doesn't seem to be a check for such there in the code as compared to normal entries.

If correct, this would let the others work as normal and symlinks used for the one that needs it.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alberto - 2025-04-30

The manual entry works, but this is not the purpose of Refind (have a automated detecting kernels bootmanager). follow_symlink is need to detect Tumbleweed kernels automaticly (or I have missed something?)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dakanji - 2025-04-30

Is the entry that is a symlink not fixed in Tumbleweed?

That is, is it not that there is a fixed Target_A that is a symlink pointing to a Kernel_XYZ that changes?

If so, you add Target_A to your manual stanza and it will point to the current Kernel_XYZ whatever that may be at any point in time. basically always picking the current kernel that is pointed to by the symlink.

Anyway, just a potential workaround suggestion. If it doesn't fit your needs, you need to ditch one of rEFInd, Tumbleweed or Mint/Ubuntu.

Good luck!

Last edit: dakanji 2025-04-30

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alberto - 2025-04-30

The entry for Thumbleweed is fixed with follow_symlinks, read my first message. But with follow_symlink It is not fixed for mixed linked / fixed kernels like Mint (I use) or Ubuntu because Mint is base on Ubuntu, it creates an additional (not working) input with symlinks found instead grouping it in Mint input.

Last edit: Alberto 2025-04-30

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dakanji - 2025-04-30

It seems you took my use of fixed as refering to reparing something that was not working but it should have been clear from the context that it was used to refer to something not changing ... that is, something constant.

So, the question was that is it not that Target_A, the path to a symlink, is constant and Kernel_XYZ, what it points to, is what changes?

The suggestion was that if that is the case, pointing to Target_A in a manual stanza would work and changed kernels always found in the same way as things currently work while avoiding the issue you have by disabling folow_symlinks for the other items.

The commit that added follow_symlinks: sf.net/p/refind/code/merge-requests/46
It is global and there is no way to isolate some item once set. The Manual Stanza option suggested is the only way I can think of to work around a situation such as yours.

We are going around in circles and I will break out here.
Good luck again!

Last edit: dakanji 2025-04-30

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alberto - 2025-04-30

For thumbleweed, all kernels have a link in /boot and they changed name on update. For Mint / Ubuntu, the 2 links points to previous and last kernel in same /boot folder. The problem is here. I will look on kernel update if name of link change, if not perhaps I can blacklist the boths links scanned ?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dakanji - 2025-05-01

If the name of the actual link file changes and the path therefore becomes different, the stanza option will not work for Tumbleweed.

An alternative would be to move the affected items to stanzas. They might have constant links that if pointed to, will pick the latest kernel. You need to get creative to figure out how to work around things. This could be by blocking some things indeed.

The feature is OFF by default as it can have unwanted outcomes and is currently targeted at those that are not affected. I suppose it needs tweaking to allow targeting/excluding instances.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alberto - 2025-05-01

It's complicated to me to modify things for Thumbleweed, kernel links are detected correctly and automaticly with follow_symlink option.
The problem with this option is /boot parsing from Mint volume. Initramfs generates kernels (no symlinks) +2 links pointed to theses kernels. I will look more at next update, but I think the 2 links are constant names.
How to backlist theses symlink names from autodetect ?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dakanji - 2025-05-01

Take a look at the dont_scan_XYZ config options

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alberto - 2025-05-01

Yes, perhaps dont_scan_files , I use it for EFI files, does it work also for links ?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alberto - 2025-05-03

I have added vmlinuz and vmlinuz.old (the links from Mint /boot folder) to dont_scan_files, but did not help. It still give an entry for Debian (the next volume parsed) as attached picture.

Last edit: Alberto 2025-05-03

refind.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Roy Rodgers - 2025-05-04
  
  I have not been following this thread closely. I do not install refind
  on any os. I install it on a usb pendrive and multiboot win 10 q4os
  tumbleweed or anything else using an 8 GB formated into 3 fat 32
  partitions first esp and refind.
  
  As a bonus I installed rescuezilla on the second partition then
  installed system rescue cd on the third partition then set the uefi bios
  to boot from partition 1
  
  If you need details let me know. this is the way I deal with multiboot
  and distro hopping
  
  On 5/3/25 2:19 AM, Alberto wrote:
  
  I have added vmlinuz vmlinuz.old (the links from Mint /boot folder) to
  dont_scan_files, but did not help. It still give an entry for Debian
  (the next volume parsed) as attached picture.
  
  Attachments:
  
  refind.png
  https://sourceforge.net/p/refind/discussion/general/thread/73ef48a8d0/99c2/attachment/refind.png
  (11.6 kB; image/png)
  
  Multibooting with Opensuze Thumbleweed
  https://sourceforge.net/p/refind/discussion/general/thread/73ef48a8d0/?limit=25#99c2
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/refind/discussion/general/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  Screenshot_20250504_101334.png
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dakanji - 2025-05-04

You could hide the unwanted instance by highlighting it and pressing the minus or delete keys.
RefindPlus will allow limiting follow_symlinks to user defined volumes at some point.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alberto - 2025-05-04

Yep I've hide the unwanted instance, hope the hiding will survive to next Linux Mint update! (but the problem is still not solved but masked) Where to post the bug ?
Thanks for your advice for RefindPlus !

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dakanji - 2025-05-04

Good chance it might not survive an update.
A better option might be to undo the hiding and to enable fold_linux_kernels if not set.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alberto - 2025-05-04

With that option its going a little better , but is buggy too in that case. vmlinuz.old is going to Mint selector ok, but vmlinuz is still in faulty Debian selector.
Attached boot folder from Mint, in blue color = links

Last edit: Alberto 2025-05-04

bootfolder.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dakanji - 2025-05-04

So what you are showing is that the links are always called initrd.img, initrd.img.old, vmlinuz and vmlinuz.old.

The other file names may be changing but the link files always have these names. That is to say, they are constant. This was the question I asked at the beginning as it seemed the only logical way for Tumbleweed to be using symlinks.

If you have /PATH/TO/vmlinuz and /PATH/TO/initrd.img in a manual stanza, it will always refer to the link files and these will always point at the current and correct ultimate destination. So just use the manual stanza setup and disable follow-symlinks as described right at the start and move on.

Last edit: dakanji 2025-05-04

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alberto - 2025-05-04

No. image above was for Mint. If I disable follow-symlinks, I loose detection of Thumbleweed kernels links (the Icon after Windows), this distro have only links. Secondly the manual stanza above will only show 1 of both kernels. I will test next Mint kernel update and hiding.
Attached thumbleweed boot folder

Last edit: Alberto 2025-05-04

opensuzeboot.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Roy Rodgers - 2025-05-04
  
  why not always boot refind from a usb - it will always detect mint and
  everything else
  
  On 5/4/25 2:24 PM, Alberto wrote:
  
  No. image above was for Mint. If I disable follow-symlinks, I loose
  detection of Thumbleweed kernels links (the first Icon), this distro
  have only links. Secondly the manual stanza above will only show 1 of
  both kernels. I will test next Mint kernel update and hiding.
  
  Multibooting with Opensuze Thumbleweed
  https://sourceforge.net/p/refind/discussion/general/thread/73ef48a8d0/?limit=25#94e6
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/refind/discussion/general/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Roy Rodgers - 2025-05-04
    
    I cannot help I never had this problem or anything related - I am not a
    refind expert i dont have a clue
    
    On 5/4/25 3:05 PM, Roy Rodgers wrote:
    
    why not always boot refind from a usb - it will always detect mint and
    everything else
    
    On 5/4/25 2:24 PM, Alberto wrote:
    
    No. image above was for Mint. If I disable follow-symlinks, I loose detection of Thumbleweed kernels links (the first Icon), this distro have only links. Secondly the manual stanza above will only show 1 of both kernels. I will test next Mint kernel update and hiding. ------------------------------------------------------------------------ Multibooting with Opensuze Thumbleweed https://sourceforge.net/p/refind/discussion/general/thread/73ef48a8d0/?limit=25#94e6 ------------------------------------------------------------------------ Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/refind/discussion/general/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
    
    Multibooting with Opensuze Thumbleweed
    https://sourceforge.net/p/refind/discussion/general/thread/73ef48a8d0/?limit=25#94e6/db45
    
    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/refind/discussion/general/
    
    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/
    
    alternate
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alberto - 2025-05-04

@ roy rodgers : my problem is not detection problem, but false symlink. Please read from the beginning.

Last edit: Alberto 2025-05-04

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dakanji - 2025-05-05

image above was for Mint

I see.

Try the attached experimental build of RefindPlus.
You can do this by putting into the rEFInd folder and renaming to match your current rEFInd file.
See sf.net/p/refind/discussion/general/thread/4d2754f090/#5d5f

It allows setting follow_symlinks as follows follow_symlinks ON "Vol1,Vol2,Vol3"
"Vol1,Vol2,Vol3" is a list of one or more volumes you want it to apply to. Volumes not on the list will be scanned without following symlinks.

The additional parameters are optional

follow_symlinks - Symlinks always followed follow_symlinks ON - Symlinks always followed follow_symlinks OFF - Symlinks never followed follow_symlinks OFF "Vol1,Vol2" - Symlinks never followed follow_symlinks ON "Vol1,Vol2" - Follow on listed volumes

Take a look at the config file notes for dont_scan_volumes for what can be used to ID the volumes in the list. It takes volume names, GUID etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alberto - 2025-05-05

Yep this one is working perfectly , I have done it via : follow_symlinks ON "opensuse" and entry Debian has gone.
But some works on this one to be done, icons for Linux are gone, and efi binary is not signed.
Have we a chance to include this feature in next Refind release ?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dakanji - 2025-05-05

RefindPlus does some things differently to rEFInd out of the box, including defaulting to generic operating system icons.

What it does differently can be reversed by configuration if not wanted. Consult the project GitHub repository README for details. This also provides guidance on how to add SBAT sections to binaries and sign such yourself, if wanted, as these are not currently done by that project.

https://github.com/RefindPlusRepo/RefindPlus

Last edit: dakanji 2025-05-05

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Multibooting with Opensuze Thumbleweed

An EFI boot manager utility

Forums

Help

Multibooting with Opensuze Thumbleweed

Multibooting with Opensuze Thumbleweed

An EFI boot manager utility

Forums

Help

Multibooting with Opensuze Thumbleweed document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

Multibooting with Opensuze Thumbleweed