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
Hello, first of all, thank you for this great tool. Use of NVRAM for storing variables is discouraged because it wears flash storage. On the other hand, writes to the filesystem frequently cause issues on my machines (I understand that this is the fault of the buggy UEFI implementations): sometimes the PreviousBoot gets corrupted/unreadable which causes rEFInd to stall on the next boot, sometimes the timestamps gets messed up (i.e. Windows "chkdsk" always finds something to complain about). So I...
Hello, first of all, thank you for this great tool. Use of NVRAM for storing variables is discouraged because it wears flash storage. On the other hand, writes to the filesystem frequently cause issues on my machines (I understand that this is the fault of the buggy UEFI implementations): sometimes the PreviousBoot gets corrupted/unreadable which causes rEFInd to stall on the next boot, sometimes the timestamps gets messed up (i.e. Windows "chkdsk" always finds something to complain about). So I...
Hello, first of all, thank you for this great tool. Use of NVRAM for storing variables is discouraged because it wears flash storage. On the other hand, writes to the filesystem frequently cause issues on my machines (I understand that this is the fault of the buggy UEFI implementations): sometimes the PreviousBoot gets corrupted/unreadable which causes rEFInd to stall on the next boot, sometimes the timestamps gets messed up (i.e. Windows "chkdsk" always finds something to complain about). So I...
Hello, first of all, thank you for this great tool. Use of NVRAM for storing variables is discouraged because it wears flash storage. On the other hand, writes to the filesystem frequently cause issues on my machines (I understand that this is the fault of the buggy UEFI implementations): sometimes the PreviousBoot gets corrupted/unreadable which causes rEFInd to stall on the next boot, sometimes the timestamps gets messed up (i.e. Windows "chkdsk" always finds something to complain about). So I...
Hello, first of all, thank you for this great tool. Use of NVRAM for storing variables is discouraged because it wears flash storage. On the other hand, writes to the filesystem frequently cause issues on my machines (I understand that this is the fault of the buggy UEFI implementations): sometimes the PreviousBoot gets corrupted/unreadable which causes rEFInd to stall on the next boot, sometimes the timestamps gets messed up ("chkdsk" always finds some issue). So I was wondering, is there a way...
Hello, first of all, thank you for this great tool. Use of NVRAM for storing variables is discouraged because it wears flash storage. On the other hand, writes to the filesystem frequently cause issues on my machines (I understand that this is the fault of the buggy UEFI implementations): sometimes the PreviousBoot gets corrupted/unreadable which causes rEFInd to stall on the next boot, sometimes the timestamps gets messed up ("chkdsk" always finds some issue). So I was wondering, is there a way...
Hello, first of all, thank you for this great tool. Use of NVRAM for storing variables is discouraged because it wears flash storage. On the other hand, writes to the filesystem frequently causes issues on my machines (I understand that this is the fault of the buggy UEFI implementations): sometimes the PreviousBoot gets corrupted/unreadable which causes rEFInd to stall on the next boot, sometimes the timestamps gets messed up ("chkdsk" always finds some issue). So I was wondering, is there a way...
I managed to find my Issue. There was a brief flash of text (hat to take a photo to read it) before rEFInd came up telling me that the verification of the fs drivers failed. As it turned out, I enrolled the wrong MOK cert. I followed the instructions and enrolled the cert that came with rEFInd (/usr/share/refind/keys/refind.cer) instead of the one generated by refind-install --local-keys (/etc/refind.d/keys/refind_local.cer). Now it works just fine and is (in retrospect) so much easier to setup with...
Hi, I just replaced grub2 with rEFInd on my pc because I was hoping to get better results when enabling secure boot. The setup of rEFInd itself went well (it boots just fine), however when I switch on secure boot rEFInd suddenly fails to find my kernel (Error: Not Found while loading vmlinuz-linux-zen). I installed rEFInd via refind-install --shim /usr/share/shim-signed/shimx64.efi --usedefault /dev/nvme1n1p1 --localkeys --alldrivers and have enrolled the MOK cert. My boot entry is the following:...
Hello I have tried today with 0.14.2 but the problem is the same. I have finished the tests as per github issue last year and found that what makes it works ( refind+ ) is the "disable_rescan_dxe" parameter, which unfortunally is not present on refind "normal". Any chance there would be a backport for it ? I will be happy to continue using refind+, but it would be interessing to have also refind to work fine on new Hp elitebook . @dakanji if interessend I'm talking about issue #185 that is closed...
I am trying to put refind and rescuezilla on one USB - So that I boot my PC to refind [on the USB] and it detects windows and debian (each on an individual SSD) also detecting rescuezilla on the same USB as refind.
Did not explain my objective - will make a new post
Operating System: Debian GNU/Linux 12 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.0-31-amd64 (64-bit) Graphics Platform: X11 Processors: 8 × AMD Ryzen 5 3400G with Radeon Vega Graphics Memory: 13,5 GiB of RAM Graphics Processor: AMD Radeon Vega 11 Graphics Motherboard ASUS B450 gaming/BR 8GB usb sandisk Cruser Fit Rescuezilla installed with Rufus in dd mode 8GB usb sandisk Cruser Blade Refind installed with Rufus in dd mode UEFI BIOS set to Boot...
Hi, i am trying to get refind working with an external Monitor connected over USB-C to my Laptop. refind is working fine on the Laptop Display but not on the the external Monitor. in my Config i tested resolution max and resolution 1 1. Grub2 is working fine with this. But no solution. Thanks a lot for help. BR kami
Operating System: Debian GNU/Linux 12 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.0-31-amd64 (64-bit) Graphics Platform: X11 Processors: 8 × AMD Ryzen 5 3400G with Radeon Vega Graphics Memory: 13,5 GiB of RAM Graphics Processor: AMD Radeon Vega 11 Graphics Motherboard ASUS B450 gaming/BR 8GB usb sandisk Cruser Fit Rescuezilla installed with Rufus in dd mode 8GB usb sandisk Cruser Blade Refind installed with Rufus in dd mode UEFI BIOS set to Boot...
Confirming the issue here, on 2 different machines. Issue which didn't exist in previous rEFInd releases. Strangely enough, if I have in refind.conf : showtools reboot, shutdown, memtest, bootorder, hidden_tags, windows_recovery, shell, firmware, about ...then the reboot and poweroff icons appear duplicated, and the firmware_upgrade icon appears even though it is not listed in wanted tools. But if I comment out the “showtools” line completely, then only the tools actually present on the system appears,...
Hey guys, I am messing around with refind, i have a dual boot W11 and Pop_OS. After installing rEFInd, i found that the options that appeared automatically were 1 windows (ok) 1 linux pop_os(sends me to a terminal), 1 linux recovery (also terminal), and systemd with a boat icon that sends me to my PopOS. So my question is how i disable the blue Booting Os message and just have a black background? For Windows I managed to do it with the use_graphics_for. But for pop os, there's no systemd option and...
Many thanks for your reply! I was following your suggestions when I found a solution from a totally unexpected quarter. I was looking for an EFI shell when I decided to pause and do a diff between my original refind.conf and my current one. It showed that at some point, I had apparently added this: dont_scan_volumes "boot" I removed that and refind shows many more entries, including a systemd boot to KDE Linux, and also an EFI shell. I somehow forgot to make a note about adding that line to all the...
Curious if that other solution has been merged? As I'm still seeing the issue.
Curious if that other solution has been merged? As I'm still seeing the issue.
I see the same issue as well.
Thank you very much for help Roderick. Thank you very much for help mfvianna. I tested it and it works correct :)
If your kernel is the Linux/kde-linux_202501310256+3.efi file on your ESP, then setting the following line in refind.conf should get it detected: also_scan_dirs +,Linux Be sure that there's no later also_scan_dirs line in refind.conf. If this doesn't work, then you might try installing and launching an EFI shell. You can then poke around in the shell to see if that file really is a kernel with an EFI stub loader; you should be able to launch it by typing its name, and if it doesn't launch, you may...
That's not really possible. rEFInd runs under EFI, which has a completely different naming convention from Linux. That is, /dev/sda1 is a Linux partition name that is not retrievable from EFI. In theory, I could poach the Linux kernel's naming code for use in rEFInd, in the hopes of getting the same results; but even that would not be guaranteed to work because of differences in drivers -- a disk might show up in Linux but not the EFI, which would throw off the naming convention. Even the partition...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will also be able to display a more human readable entry. Refind does show the filesystem label on each selection if its labeled, like: "Boot vmlinuz... from file-system-name" To label an ext4 filesystem: tune2fs -L "<label>" /dev/sda1 To label a btrfs filesystem: btrfs filesystem label /dev/sda1 "<label>" To label a xfs filesystem: xfs_admin -L "<label>" /dev/sda1 (please replace /dev/sda1...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will also be able to display a more human readable entry. Refind does show the filesystem label on each selection if its labeled, like: "Boot vmlinuz... from file-system-name" To label an ext4 filesystem: tune2fs -L "<label>" /dev/sda1 To label a btrfs filesystem: btrfs filesystem label /dev/sda1 "<label>" To label a xfs filesystem: xfs_admin -L "<label>" /dev/sda1 (please replace /dev/sda1...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will also be able to display a more human readable entry. Refind does show the filesystem name on each selection if its labeled, like: "Boot vmlinuz... from file-system-name" To label an ext4 filesystem: tune2fs -L "<name>" /dev/sda1 To label a btrfs filesystem: btrfs filesystem label /dev/sda1 "<name>" To label a xfs filesystem: xfs_admin -L "<name>" /dev/sda1 (please replace /dev/sda1 with...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will also be able to display a more human readable entry. Refind does show the filesystem name on each selection if its labeled like "Boot vmlinuz... from file-system-name" To label an ext4 filesystem: tune2fs -L "<name>" /dev/sda1 To label a btrfs filesystem: btrfs filesystem label /dev/sda1 "<name>" To label a xfs filesystem: xfs_admin -L "<name>" /dev/sda1 (please replace /dev/sda1 with the...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will also be able to add a more human name. Refind does show the filesystem name on each selection if its labeled like "Boot vmlinuz... from file-system-name" To label an ext4 filesystem: tune2fs -L "<name>" /dev/sda1 To label a btrfs filesystem: btrfs filesystem label /dev/sda1 "<name>" To label a xfs filesystem: xfs_admin -L "<name>" /dev/sda1 (please replace /dev/sda1 with the appropriate...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will also be able to add a more human name. Refind does show the partition name on each selection if its labeled like "Boot vmlinuz... from file-system-name" To label an ext4 filesystem: tune2fs -L "<name>" /dev/sda1 To label a btrfs filesystem: btrfs filesystem label /dev/sda1 "<name>" To label a xfs filesystem: xfs_admin -L "<name>" /dev/sda1 (please replace /dev/sda1 with the appropriate...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will also be able to add a more human name. Refind does show the partition name on each selection if its labeled like "Boot linux-... from file-system-name" To label an ext4 filesystem: tune2fs -L "<name>" /dev/sda1 To label a btrfs filesystem: btrfs filesystem label /dev/sda1 "<name>" To label a xfs filesystem: xfs_admin -L "<name>" /dev/sda1 (please replace /dev/sda1 with the appropriate partition...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will also be able to add a more human name. Refind does show the partition name on each selection if its labeled like 'Boot linux-... from <name> '</name> To label an ext4 filesystem: tune2fs -L "<name>" /dev/sda1 To label a btrfs filesystem: btrfs filesystem label /dev/sda1 "<name>" To label a xfs filesystem: xfs_admin -L "<name>" /dev/sda1 (please replace /dev/sda1 with the appropriate partition...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will also be able to add a more human name. Refind does show the partition name on each selection if its labeled like 'Boot linux-... from <name> ':</name> To label an ext4 filesystem: tune2fs -L "<name>" /dev/sda1 To label a btrfs filesystem: btrfs filesystem label /dev/sda1 "<name>" To label a xfs filesystem: xfs_admin -L "<name>" /dev/sda1 (please replace /dev/sda1 with the appropriate partition...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will also be able to add a more human name. Refind does show the partition name on each selection if its labeled like "Boot linux-... from <name>":</name> To label an ext4 filesystem: tune2fs -L "<name>" /dev/sda1 To label a btrfs filesystem: btrfs filesystem label /dev/sda1 "<name>" To label a xfs filesystem: xfs_admin -L "<name>" /dev/sda1 (please replace /dev/sda1 with the appropriate partition...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will also be able to add a more human name. Refind does show the partition name on each selection if its labeled like "Boot linux-... from <filesystem label="">":</filesystem> To label an ext4 filesystem: tune2fs -L "<name>" /dev/sda1 To label a btrfs filesystem: btrfs filesystem label /dev/sda1 "<name>" To label a xfs filesystem: xfs_admin -L "<name>" /dev/sda1 (please replace /dev/sda1 with...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will be able to add a more human name. Refind does show the partition name on each selection if its labeled like "Boot linux-... from <filesystem label="">":</filesystem> To label an ext4 filesystem: tune2fs -L "<name>" /dev/sda1 To label a btrfs filesystem: btrfs filesystem label /dev/sda1 "<name>" To label a xfs filesystem: xfs_admin -L "<name>" /dev/sda1 (please replace /dev/sda1 with the...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will be able to add a more human name. Refind does show the partition name on each selection if its labeled like "Boot linux-... from <filesystem label="">":</filesystem> To label an ext4 filesystem: tune2fs -L "<name>" /dev/sda1 To label a btrfs filesystem: btrfs filesystem label /dev/sda1 "<name>" To label a xfs filesystem: xfs_admin -L "<name>" /dev/sda1 (please replace /dev/sda1 with the...
Hi @Matej, You could label your filesystems. In addition to allowing you to identity each installation you will be able to add a more human name. Refind does show the partition name on each selection if its labeled like "Boot linux-... from <filesystem label="">":</filesystem> To label an ext4 filesystem: `tune2fs -L "<name>" /dev/sda1` To label a btrfs filesystem: `btrfs filesystem label /dev/sda1 "<name>"` To label a xfs filesystem: `xfs_admin -L "<name>" /dev/sda1` (please replace /dev/sda1 with...
Dear Roderick, can you please add one functionality in rEFInd? It is very good, that rEFInd support boot from linux kernels, but on my computer it is not clearly on what partition is concrete linux kernel. I use more distributions on the same disk, on more partitions. Based my partition setting during OS installation, every linux kernel is on separate partition on root partition. Based on partition number I know, on what partition I have installed what OS distribution. Based partition number I can...
I do the same as you describe. I don't use NVRAM because I've found it unreliable on some off-brand PCs, so I use the vars/ folder. On Windows in a Cmd Shell with Admin privileges, I do mountvol s: /s cp s:\efi\Refind\vars\PreviousBoot.linux s:\efi\Refind\vars\PreviousBoot Where PreviousBoot.linux I saved from previous boot into linux. Between other boot options I use https://github.com/Kerrnel/Scripts/blob/main/refind-next-boot Which does detect use of nvram and supports that as well - but then...
For fun, I installed the alpha KDE Linux on a partition of my SSD. For the install, I used the default format of btrfs. Docs say the default bootloader is systemd-boot. But refind doesn't see this distro. (In fact, I can find no way to boot it.) Here's list of the files added to the ESP during the install: -rwxr-xr-x 1 root root 123392 Jan 31 17:08 BOOT/bootx64.efi -rwxr-xr-x 1 root root 123392 Jan 31 17:08 systemd/systemd-bootx64.efi -rwxr-xr-x 1 root root 182594560 Jan 31 17:08 Linux/kde-linux_202501310256+3.efi...
For fun, I installed the alpha KDE Linux on a partition of my SSD. For the install, I used the default format of btrfs. The default bootloader for KDE Linux is systemd-boot. But refind doesn't see this distro. [UPDATE 2025-02-01 The "issue" mentioned in the "update" immediately below has been fixed. it had no effect on refind seeing this distro, but it did change the information I provided below about this problem. So I will repost with the new information, under the title "refind can't see stub...