Calm down bro. Dakanji is only trying to help and your attitude is not helping you.
I already explained hdbios did not work There is no mention of hdbios anywhere in your original post. Bottom line is that without this in your scanfor list, a legacy BIOS boot disk will not be scanned and not be displayed.
hdbios is literally step 1... why would I be asking this question? Yea I figured it out already, thanks
hdbios is literally step 1... why would I be asking this question?
that was the FIRST thing I tried, and I already explained that did not work There is no mention of hdbios anywhere in your original post. Bottom line is that without this in your scanfor list, a legacy BIOS boot disk will not be scanned and not be displayed.
that was the FIRST thing I tried, and I already explained that did not work There is no mention of hdbios anywhere in your original post. Bottom line is that without this in your scanfor list, a legacy BIOS boot disk will not be scanned and not be displayed.
bro I did use "hdbios" that was the FIRST thing I tried, and I already explained that did not work. I'm not sure why, but I believe (as I already said) its probably because my current windows is in Legacy mode and not EFI. I already said I realize I need to re-install Windows but I'm not at that point yet... Like I said, the ONLY one that works for MY windows is "boot to harddrive" via the "scanfor firmware" option, I thought I was clear about that in my post, but I guess I did not specificy the...
that was the FIRST thing I tried, and I already explained that did not work There is no mention of hdbios anywhere in your original post.
bro I did use "hdbios" that was the FIRST thing I tried, and I already explained that did not work. I'm not sure why, but I believe (as I already said) its probably because my current windows is in Legacy mode and not EFI. I already said I realize I need to re-install Windows but I'm not at that point yet... Like I said, the ONLY one that works for MY windows is "boot to harddrive" via the "scanfor firmware" option, I thought I was clear about that in my post, but I guess I did not specificy the...
bro I did use "hdbios" that was the FIRST thing I tried, and I already explained that did not work. I'm not sure why, but I believe (as I already said) its probably because my current windows is in Legacy mode and not EFI. I already said I realize I need to re-install Windows but I'm not at that point yet... Like I said, the ONLY one that works for MY windows is "boot to harddrive" via the "scanfor firmware" option, I thought I was clear about that in my post, but I guess I did not specificy the...
Use scanfor internal,hdbios and also read the documentation, or at least notes in the config file, next time you have issues. https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/refind.conf-sample#L315-L334
I'm trying to dualboot between Linux and Windows with rEFInd working for Linux, but Windows is giving me multiple icons with several icons do not work, so I just need 1 manual stanza with the option "reboot to harddrive" for Windows... I removed the # before "showtools" in the refind.conf to enable hidden_tags, I press delete or minus (-) to hide icons, but some of the icons keep coming back after I restart. I only want 2 icons, 1 for Linux and 1 for Windows. I tried changing the line regarding which...
I'm trying to dualboot between Linux and Windows with rEFInd working for Linux, but Windows is giving me multiple icons with several icons do not work, so I just need 1 manual stanza with the option "reboot to harddrive" for Windows... I removed the # before "showtools" in the refind.conf to enable hidden_tags, I press delete or minus (-) to hide icons, but some of the icons keep coming back after I restart. I only want 2 icons, 1 for Linux and 1 for Windows. I tried changing the line regarding which...
I'm trying to dualboot between Linux and Windows with rEFInd working for Linux, but Windows is giving me multiple icons with several that do not work, so I just need 1 manual stanza for the option "reboot to harddrive" for Windows... I removed the # before "showtools" in the refind.conf to enable hidden_tags, I press delete or minus (-) to hide icons, but some of the icons keep coming back after I restart. I only want 2 icons, 1 for Linux and 1 for Windows. I tried changing the line regarding which...
Hi, I've installed refind and it works, when I select it from the boot options. Now I would like to make it the default. But when I run refind-mkdefault I get this error: Traceback (most recent call last): File "/usr/sbin/refind-mkdefault", line 205, in <module> sys.exit(main()) ~~~~^^ File "/usr/sbin/refind-mkdefault", line 192, in main changed = set_refind_first(boot_entries, boot_order, args.label) File "/usr/sbin/refind-mkdefault", line 117, in set_refind_first if label.lower() in boot_entries[entry].lower():...
Just an update I get black screen with the official binary release, too (so it is quite hard to debug :D ). Let's hope I can find out what does it cause - I am curious how RefindPlus can be configured for keeping background image, and how it works with deferred takeover.
Thank you! Yepp, the first part was clear, but I was not sure how it leaves the screen in graphics mode. And now I see why it is complicated (it would need to remove icons, shadows, text, etc, or quickly redraw to a defined image). Yesterday I gave a try to RefindPlus, because I had the feeling it will do that. :) I used the GitHub Actions method, which ran fine and produced REL efi files. I added the UEFI_APP---x64_RefindPlus_REL.efi file with efibootmgr as a separate entry, but it produced only...
What is the expected behavior for the use_graphics_for option? The setting is to determine which mode, graphics or text, the screen is to be set to before passing control over to what is to be run next. I thought it will keep the banner image until the booting OS overwrites the screen, but sometimes I read this option will set the background to the upleft pixel's color of the banner. The screen is cleared before exiting and handing off to something else. Either way, would it be feasible to add an...
What is the expected behavior for the use_graphics_for option? The setting is to determine which mode, graphics or text, the screen is to be set to before passing control over to what is to be run next. I thought it will keep the banner image until the booting OS overwrites the screen, but sometimes I read this option will set the background to the upleft pixel's color of the banner. The screen is cleared before exiting and handing off to something else. Either way, would it be feasible to add an...
QUite old topic, but... I am trying to create a more-or-less continuous boot experience with rEFInd and Plymouth. I had to fight with the buggy HP NTFS driver issue and other framebuffer issues, but it works now. Except that rEFInd clears the screen and sets it to black after I select a boot entry (Gentoo Linux). The kernel has deferred takeover, I use banner=xxxx for the image (which is displayed properly, however it flickers 3 times), textonly is not enabled, resolution is my maximum 1920x1080,...
Enable building for RISC-V architecture
Chiming in to request this get looked at as well. Appears to still be an issue.
Using 0.14.2 installed from ZIP file over the version from Debian Bookworm, and having configured TEXT MODE in refind.conf, the optional delay for detecting additional removable drivers is displayed in the BIOS-es graphic mode instead of the configured text mode, looks like rEFInd forgets to load the text mode from the config file before executing the startup delay from the same config file. This was observed on Dell hardware with the AMI UEFI skin (Aptio) from 2013 .
The patch works nicely. My worry is that this issue hasn't had any response by the refind author, even when there's a working patch that could be just merged and released with little effort. Is the project abandoned?
@Panayotis Katsaloulis Both patches work, but the second version of the fix is much simpler and required less editing of the code: https://sourceforge.net/p/refind/code/merge-requests/55/
I tried the patch from the PR that was originally sent and I confirm too that I can see only one tool. In the PR it was mentioned that maybe this is not the optimal way to handle this and the patch was cancelled. I don't know if there's a better patch (I couldn't find it), neither in pending patches or accepted. So I think no more progress has been done. If the"proper" patch is not available yet, I could provide the binary that I compiled with the "wrong" patch, since it works for me -- although...
➜ ~ sudo efibootmgr BootCurrent: 0006 Timeout: 3 seconds BootOrder: 0006,0004,0005 Boot0004 artixHD(1,GPT,09f3454c<snip>,0x1000,0x96000)/\EFI\artix\grubx64.efi Boot0005</snip> Hard Drive BBS(HD,,0x0)414d474f <snip> Boot0006* UEFI: FlashDriBLA_001HD(2,MBR,0x31c94cad,0xe8e6000,0x10000)/\EFI\BOOT\BOOTX64.EFIAMBO ➜ ~ sudo refind-mkdefault rEFInd was not found in the boot options list! You should create a rEFInd entry with efibootmgr or by re-installing (with refind-install, for example) No changes s...
+1 this issue kills the whole point of having "pretty and customizable" boot manager.
Arch Linux ARM: $ make Did not find /usr/local/edk2-vUDK2018 or /usr/local/UDK2014/MyWorkSpace; building with GNU-EFI make gnuefi make[1]: Entering directory '/dev/shm/refind/v.0.14.2' make MAKEWITH=GNUEFI -C libeg make[2]: Entering directory '/dev/shm/refind/v.0.14.2/libeg' /usr/bin/aarch64-linux-gnu-gcc -Os -fno-strict-aliasing -fno-tree-loop-distribute-patterns -fno-stack-protector -fshort-wchar -Wall -fno-merge-constants -ffreestanding -DEFIAARCH64 -fno-stack-check -fpic -I/usr/include/efi -I/usr/include/efi/aarch64...
I'm stumped -- rEFInd was working beautifully for quite a while, and now suddenly any kernel I build is hitting a Not Found error, even though my older kernels still work, and I don't see any enlightening details in the logs either. It's particularly strange since I'm not even using a manual boot stanza, so these kernels which are "not found" have already been auto-detected and validated to begin with, based on the logs as well. Grub appears to be OK with these new kernels but I'd rather use rEFInd...
I'm stumped -- rEFInd was working beautifully for quite a while, and now suddenly any kernel I build is hitting a Not Found error, even though my older kernels still work, and I don't see any particularly enlightening details in the logs either. It's particularly strange since I'm not even using a manual boot stanza, so these kernels which are "not found" have already been auto-detected and validated to begin with, based on the logs as well. Grub appears to be OK with these new kernels but I'd rather...
You can use the new mod for refind and refindplus it is designed with old firmware support in mind, give it a try: https://github.com/aterro/rEFInd-for-All/tree/master/Release or https://github.com/Abz79/RefindPlus
You can use the new mod for refind and refindplus it is designed with old firmware support in mind, give it a try: https://github.com/aterro/rEFInd-for-All/tree/master/Release or https://github.com/Abz79/RefindPlus
Instead of rEFInd’s traditional single horizontal row of OS icons, refind_grid presents the icons in a grid format. This improves clarity and access when many operating systems or boot options are available. It maximizes screen real estate, allowing for faster visual scanning and selection. Interactive Reordering with 'R' Key: Holding down the R key while selecting a boot option allows users to reposition icons using arrow keys (↑ ↓ ← →). Once rearranged, the grid menu order is persistently saved...
I've been working hard at implementing a grid layout for rEFInd. I have a working version right now that centers the grid on the screen and dynamically changes the rows and columns and adds support for the use of the up and down arrows for navigation. I would be finished with it by now but decided to implement a couple more features. What I am working on now is a 'select and move' function within rEFInd that will let the user hold a hotkey while highlighting a selection and use the navigation arrows...
When multiple instances of Windows are present on the same unit, there can be problems with using third party loaders such as rEFInd if disks holding existing instances were not disconnected before installing subsequent instances (such as when installed on the same disk). A way to get around this is outlined below: https://www.toptensoftware.com/blog/booting-multiple-windows-with-refind If the link is broken, as it currently is for me, try the Wayback Machine : https://51.159.194.213/web/20250113191514/https://www.toptensoftware.com/blog/booting-multiple-windows-with-refind/?__cpo=aHR0cHM6Ly93ZWIuYXJjaGl2ZS5vcmc...
When multiple instances of Windows are present on the same unit, there can be problems with using third party loaders such as rEFInd if disks holding existing instances were not disconnected before installing subsequent instances such as when installed on the same disk. A way to get around this is outlined below: https://www.toptensoftware.com/blog/booting-multiple-windows-with-refind If the link is broken, as it currently is for me, try the Wayback Machine : https://51.159.194.213/web/20250113191514/https://www.toptensoftware.com/blog/booting-multiple-windows-with-refind/?__cpo=aHR0cHM6Ly93ZWIuYXJjaGl2ZS5vcmc...
Thanks for the info Roy. My minor issues with Windows Boot Manager really don't justify undertaking that type of solution. Slàinte mhath Jim
I solved a similar problem by always booting from a usb thumb drive (set in UFEI boot san disk partition1 on motherboard configuration screen) - I have win 10 on first partition of an old 1GB hard disk 2nd partition NTFS, windows 11 on an 120 gb ssd and opensuse tumbleweed on a 220gb ssd. I have 3 fat 32 partitions 1 refind 2 rescuezilla 3 system rescue CD refind detects all and if I add another ssd/hd with another OS or plug in a linux distro live cd on a usb it detects everything. I can easily...
I have a dual boot Win10 Win11 system. In my BCD I have the Windows systems with EaseUS and Macrium recovery PEs. I decided to use rEFInd because of issues I was having with Windows Boot Manager but unfortunately rEFInd puts me back into Windows Boot Manager. Is there a way I can have rEFInd allow me to drop the Windows Boot Manager and handle the four items I want to use? Slàinte mhath Jim [6758c711-5067-4b61-bfc6-83f11b60f0d1]
I've got an update for Mint today. Masking have survive to update, I think because name of masking names haven't change. So problem is 'masked' but not solved. And no response from my email to developer.
Something like this? https://github.com/EHfive/uefi-toys?tab=readme-ov-file Apologies for resurrecting a thread after 4 years, but this is relevant.
Thanks for all.
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
RefindPlus does some things differently to rEFInd out of the box, including defaulting to generic operating systems 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
Well, not sure it is a bug as such. The notes in the rEFInd config file clearly say symlinks are not followed by default as this may result in undesirable outcomes: https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/refind.conf-sample#L507-L515 What you have experienced looks like one such undesirable outcome. In terms of making feature requests, I think this is the place to do so. Alternatively, you could also try sending an email to the developer. The address...
Ok thanks for RefindPlus link. And about my question to add the feature inside Refind, I Am on right place to ask or post actual bug ?
RefindPlus does some things differently to rEFInd out of the box, including defaulting to generic icons for operating systems. 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 the project. https://github.com/RefindPlusRepo/RefindPlus
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 ?
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...
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...
@ roy rodgers : my problem is not detection problem, but false symlink. Please read from the beginning.
@ roy rodgers : my problem is not detection problem, but false duplicate. Please read from the begining.
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
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...
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.
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.
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...
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...
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 right 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...
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 right 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 will always point at the current...
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 right 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 will always point at the current...
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 right 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 mnaul stanza, it will always refer to the link files and will always point at the current...
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 right 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 mnaul stanza, it will always refer to the link files. So just use the manual stanza setup...
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 as it seemed the only logical way for Tumbleweed to be using symlinks ... this was the question I asked right at the beginning! If you have /PATH/TO/vmlinuz and /PATH/TO/initrd.img in a mnaul stanza, it will always refer to the link files. So just use the manual stanza setup...
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
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.
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.
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 !
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.
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.
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.
Can confirm having this issue aswell
Yes, perhaps dont_scan_files , I use it for EFI files, does it work also for links ?
Take a look at the dont_scan_XYZ config options
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 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....
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 ?
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...
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 ... constant.is 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...
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 ... constant.is So, the question was is it not that Target_A, the path to a symlink, is constant and Kernel_XYZ, what it points to, 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...
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 ... constant. So, the question was is it not that Target_A, the path to a symlink, is constant and Kernel_XYZ, what it points to, 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...
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 ... constant. So, the question was is it not that Target_A, the path to a symlink, is constant and Kernel_XYZ, what it points to, 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...
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 ... constant. So, the question was is it not that Target_A, the path to a symlink, is constant and Kernel_XYZ, what it points to, 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...
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 ... constant. So, the question was is it not that Target_A, the path to a symlink, is constant and Kernel_XYZ, what it points to, 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...
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 ... constant. So, the question was is it not that Target_A, the path to a symlink, is constant and Kernel_XYZ, what it points to, 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...
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.
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 symlink found instead grouping it in Mint input.
The entry for Thumbleweed is fixed, read my first message. It is not fixed for mixed linked / fixed kernels like Mint (I use) or Ubuntu because Mint is base on Ubuntu.
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....
Is the entry that is symlinked 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....
Is the entry that is symlinked 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 at 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....
Is the entry that is symlinked 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 at is pointed to by the symlink. Anyway, just a potential workaround suggestion. If it doesn't fit your needds, you need to ditch one of rEFInd, Tumbleweed or Mint/Ubuntu....
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?)
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.
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...
Just resurfacing this mr from the depths. Would really love to get this merged so I can make my refind clean and shiny again
RefindPlus has a transient_boot setting, which will make it not save data about the previous boot anywhere. https://sf.net/p/refind/discussion/general/thread/4d2754f090/#5d5f
Looks like a memory conflict caused it to hang. Can you try temporarily replacing the rEFInd efi with one from RefindPlus to see if it does the same? See: https://github.com/RefindPlusRepo/RefindPlus/releases Just change the rEFInd file extension to .efix, give the RefindPlus file the same name as rEFInd had and reboot as normal. Use the RefindPlus DBG file (for debugging) to generate a log file. The REL file (for normal use) does not produce logs. You can share the log here. Thanks.
Found a somewhat "hacky" solution to prevent further writes to a PreviousBoot file by setting a read-only attribute on the said file. Thank you