Activity for rEFInd
-
dakanji modified a comment on discussion General Discussion
NUM_TOOLS is defined to be 24 in global.h, but the default showtools array in main.c is only zeroed out to a total of 21 items. Good catch! This could well be the mysterious memory issue as SetMem is used with a larger size. EDIT: ShowTools is set to NUM_TOOLS size here: https://github.com/dakanji/rEFInd/blob/94ba63b502c65933f4d8ef8871c5914d6dae4495/refind/global.h#L394 So the sizing should not be an issue. That is, ShowTools by itself is OK and something else is manifesting. The issues with the...
-
NUM_TOOLS is defined to be 24 in global.h, but the default showtools array in main.c is only zeroed out to a total of 21 items. Good catch! This could well be the mysterious memory issue as SetMem is used with a larger size. EDIT: ShowTools is set to NUM_TOOLS size here: https://github.com/dakanji/rEFInd/blob/94ba63b502c65933f4d8ef8871c5914d6dae4495/refind/global.h#L394 So the sizing should not be an issue. That is, ShowTools by itself is OK and something else is manifesting. The issues with the...
-
Hi Michael, Do you mind trying RefindPlus and sharing the log? Rename your existing rEFInd efi file Place the efi file in the same folder Rename the new file as the original rEFInd efi had Reboot and a log file should be in the ESP Also confirm whether it addresses your issue
-
NUM_TOOLS is defined to be 24 in global.h, but the default showtools array in main.c is only zeroed out to a total of 21 items. Good catch! This could well be the mysterious memory issue as SetMem is used with a larger size. EDIT: ShowTools is set to NUM_TOOLS size here: https://github.com/dakanji/rEFInd/blob/94ba63b502c65933f4d8ef8871c5914d6dae4495/refind/global.h#L394 So the sizing should not be an issue
-
NUM_TOOLS is defined to be 24 in global.h, but the default showtools array in main.c is only zeroed out to a total of 21 items. Good catch! This could well be the mysterious memory issue as SetMem is used with a wrong larger size.
-
NUM_TOOLS is defined to be 24 in global.h, but the default showtools array in main.c is only zeroed out to a total of 21 items. Good catch! This could well be the mysterious memory issue as SetMem is used with a wrong size.
-
NUM_TOOLS is defined to be 24 in global.h, but the default showtools array in main.c is only zeroed out to a total of 21 items. Might want to add a few more zeros to that initial showtools array in main.c. Good catch! This could well be the mysterious memory issue as SetMem is used with a wrong size.
-
I handled the iteration as well as invalid entries differently in RefindPlus. The i-1 setup is not used. and there are separate iterators for TokenList and GlobalConfig.ShowTools. Additionally, a variable counts invalid items and this is added to the TokenList iterator. There is an issue otherwise as you noted indeed where if a user enters an invalid entry, things go out of shape. I have also dropped SetMem (not yet pushed) and now just zero things out manually there as well. This is done right off...
-
I handled the iteration as well as invalid entries differently in RefindPlus. The i-1 setup is not used. and there are separate iterators for TokenList and GlobalConfig.ShowTools. Additionally, a variable counts invalid items and this is added to the TokenList iterator. There is an issue otherwise as you noted indeed where if a user enters an invalid entry, things go out of shape. I have also dropped SetMem (not yet pushed) and now just zero things out manually there as well. This is done right off...
-
I handled the iteration as well as invalid entries differently in RefindPlus. The i-1 setup is not used. and there are separate iterators for TokenList and GlobalConfig.ShowTools. Additionally, a variable counts invalid items and this is added to the TokenList iterator. There is an issue otherwise as you noted indeed where if a user enters an invalid entry, things go out of shape. I have also dropped SetMem (not yet pushed) and now just zero things out manually there as well. This is done right off...
-
I handled the iteration as well as invalid entries differently in RefindPlus. The i-1 setup is not used. and there are separate iterators for TokenList and GlobalConfig.ShowTools. Additionally, a variable counts invalid items and this is added to the TokenList iterator. There is an issue otherwise as you noted indeed where if a user enters an invalid entry, things go out of shape. I have also dropped SetMem (not yet pushed) and now just zero things out manually there as well. This is done right off...
-
I handled the iteration as well as invalid entries differently in RefindPlus. The i-1 setup is not used. and there are separate iterators for TokenList and GlobalConfig.ShowTools. Additionally, a variable counts invalid items and this is added to the TokenList iterator. There is an issue otherwise as you noted indeed where if a user enters an invalid entry, things go out of shape. I have also dropped SetMem (not yet pushed) and now just zero things out manually there as you did.
-
I handled the iteration as well as invalid entries differently in RefindPlus. There are separate iterators for TokenList and GlobalConfig.ShowTools. Additionally, a variable counts invalid items and this is added to the TokenList iterator. The i-1 setup is not used. There is an issue otherwise as you noted indeed where if a user enters an invalid entry, things go out of shape. I have also dropped SetMem (not yet pushed) and now just zero things out manually there as you did.
-
I handled the iteration as well as invalid entries differently in RefindPlus. There are separate iterators for TokenList and GlobalConfig.ShowTools. Additinally, a variable counts invalid items and this is added to the loop iterator. The i-1 setup is not used. There is an issue otherwise as you noted indeed where if a user enters an invalid entry, things go out of shape. I have also dropped SetMem (not yet pushed) and now just zero things out manually there as you did.
-
Jeremy S posted a comment on discussion General Discussion
Sorry, last thing. Should note that my "fixed" code at https://github.com/loserMcloser/rEFInd/blob/86c7ab03db42001bfbe5c7e72654e568572e063f/refind/config.c#L669-L718 is not actually an appropriate fix, because of the way that the TokenList index variable and the GlobalConfig.ShowTools index variable are tied together. If the SetMem command is commented out and one of the TokenList items triggers the final "unknown showtools flag" else block, the entry at position GlobalConfig.ShowTools[i-1] is not...
-
Also, isn't there an off-by-one error in the bound of that for loop in config.c ? Since i-1 is used as the index variable to set items in the GlobalConfig.ShowTools array, shouldn't for (i = 1; (i < TokenCount) && (i < NUM_TOOLS); i++) { instead be for (i = 1; (i < TokenCount) && (i <= NUM_TOOLS); i++) { ?
-
Yes, this is almost certainly the issue. I edited the showtools code in config.c by commenting out the SetMem call and then adding a loop to "manually" zero out the rest of the GlobalConfig.ShowTools array, and it fixed the issue. See here: https://github.com/loserMcloser/rEFInd/blob/86c7ab03db42001bfbe5c7e72654e568572e063f/refind/config.c#L669-L718 Couple of side notes: * On my two machines where the issue occurs, secure boot is enabled and managed by rEFInd. My machine where the issue doesn't occur...
-
The GlobalConfig.ShowTools item has a default of 12 items: https://github.com/dakanji/rEFInd/blob/94ba63b502c65933f4d8ef8871c5914d6dae4495/refind/main.c#L154-L156 When you set showtools in your config, the defaults are supposed to be cleared here: https://github.com/dakanji/rEFInd/blob/94ba63b502c65933f4d8ef8871c5914d6dae4495/refind/config.c#L670 I suspect what you are seeing is out of a deep lying memory management issue , most likely what I call El Gordo that I think is a buffer overrun of sorts....
-
Only one showtools option in my configs: % grep -r showtools /boot /boot/EFI/refind/refind.conf:showtools mok_tool,reboot,shutdown,firmware,memtest After commenting out hideui the two instances of mok_tool reported identical paths. The other tools did not report any paths. (Sorry for the glare.) Here is my current config: ######################## # General Settings ######################## timeout 10 resolution 1920 1200 showtools mok_tool,reboot,shutdown,firmware,memtest scanfor manual default_selection...
-
Roderick W. Smith committed [94ba63] on Code
Do more to fix the refind-mkdefault bug involving a bad BootOrder variable
-
rEFInd 0.14.2 introduced some significant changes to the way it scans for disk-based tools. I did this for various reasons -- partly to simplify the code, partly to deal with changes in the names and locations of some tools (most notably, various memtest tools). One consequence, however, is that rEFInd may detect a slightly different set of tools, potentially increasing or decreasing the number of tools, depending on what's available on a system. That said, some of what you've reported seems strange,...
-
Since upgrading to 0.14.2 on Archlinux, the tools are duplicated. My showtools entry in refind.conf is showtools mok_tool,reboot,shutdown,firmware,memtest but since upgrading, what shows up on the refind screen when booting is mok_tool,reboot,shutdown,memtest,mok_tool,about,shutdown,reboot,memtest I'm not the only archuser to have this issue: rEFInd - showtools option no longer working after updating to 0.14.2-1 Oddly, the issue only occurs on two of my three Archlinux machines (laptop, home desktop,...
-
Fixed bug in refind-mkdefault if BootOrder has invalid entry.
-
nl6720 posted a comment on discussion General Discussion
@srs5694, I think you may have forgotten to push the tags.
-
rEFInd relies on various on-disk files for much of its functionality, so if it's started over a network, it won't know where to look to find those files -- and they may not be available at all. I tested this years ago, and IIRC, at the time it would sort-of work, but without icons and with only the defaults from refind.conf (since of course it couldn't load that file). It may be that it's gotten worse -- or maybe not. What happens when you do as you're prompted and press a key to continue? If rEFInd...
-
rEFInd automatically filters out duplicate partitions based on the filesystem's UUID or serial number. This is done so as to prevent the display of duplicate entries in software RAID 1 arrays. Chances are this is what's causing your issue -- your backup partition likely contains a duplicate serial number. You might want to check your backup software to see if it has an option to not duplicate the serial number when cloning a partition. As the point of a filesystem serial number is to uniquely identify...
-
I do use git tag on release versions; the latest has a tag of "v.0.14.2".
-
First, you can always set icons_dir in refind.conf to point to a replacement or supplemental directory for icons. These will not be replaced when rEFInd is updated. This option is most commonly used in theming operations, but you can use it to add one or two icons, if you like. Second, I've just added an ArcaOS icon to the rEFInd git repository. I picked a different one than you presented for licensing reasons and because it better fills the square; however, the original was just 80x80, and so it...
-
David Runge posted a comment on discussion General Discussion
Hi! Up until recently I have been maintaining this project as a package for Arch Linux. Going back to bump the version for fixing https://sourceforge.net/p/refind/discussion/general/thread/7659d4ff48/ I realized that the git repository of this project does not have any tags: https://sourceforge.net/p/refind/code/ci/master/tree/ In light of recent events (backdoor code added to the xz project and activated using a manipulated configure script in a custom (signed) source tarball) I would like to ask...
-
Dave Yeo posted a comment on discussion General Discussion
Hi, what would it take to add OS/2 support? Actually AOS support. AOS is an OEM version of OS/2. https://www.arcanoae.com A few folk successfully use rEFind for booting, works well, including as I use it for booting both legacy and UEFI installs of OS/2. Problem is every time I update (Linux Mint), my icon gets moved to icons-backup, seems best to have it in the package. Here's how OS/2 gets installed in the EFI partition, launcher.efi is a minimalist launcher. The volume label in drive U is EFI_SYSTEM....
-
Version 0.14.2 release
-
rEFInd released /0.14.2/refind-src-0.14.2.tar.gz
-
-
-
-
-
-
-
-
-
Makefile changes for GNU-EFI:
-
Theoretically add gzip.lib to 'make tiano' build target; but that target is deprecated and doesn't work for me.
-
Remove commented-out code; reformat a few lines.
-
Build at commit c1a97f5780259de42d80f9dfdedbe17e4fa86051 works fine! 🎉
-
I've pushed my changes to the git repository. Could you please try them, @nl6720? They work for me on Ubuntu 22.04 on x86-64, Ubuntu 24.04 pre-release on ARM64, and Arch Linux on ARM64. Both the Ubuntus used a locally-built GNU-EFI 3.0.18, but the Arch used the Arch GNU-EFI 3.0.18 package. I'm afraid I don't have a working Arch installation on x86-64 for testing. Note that the ARM64 build change requires editing Make.common or passing GNUEFI_ARM64_TARGET_SUPPORT=y when using GNU-EFI 3.0.17 or later;...
-
Accommodate change in GNU-EFI 3.0.17 and later build options for ARM64
-
Worked around problems with GNU-EFI 3.0.18
-
I think I've got this sorted out. There are actually three problems: * The change you identified that causes failures to launch if -j .rodata is not used with objcopy. This was the easiest to deal with. * The commit I identified, which changed the way CopyMem() was defined. This one's weird; it was as if the rEFInd build process was ignoring the EFIAPI option on that function, thus calling it with the wrong ABI. Maybe it was; the rEFInd build process is pretty convoluted. I've worked around the problem...
-
Backport Apple Fat Binary Validity Fix from RefindPlus
-
Closing as manually merged https://github.com/dakanji/rEFInd/commit/a9bf0f7fb330d7b13fea903d26f18f05193d5b49
-
Further information: It's also necessary to add -j .rodata as an objcopy option. This may well be related to the commit you identified, @nl6720. (I'd been experimenting with that and forgot I had it set when I found the EFIAPI commit.)
-
To quote Marge Gunderson ("Fargo"), "I'm not sure I agree with you a hundred percent on your police work there, Lou." Poking through the Sourceforge git repo for GNU-EFI, I find that the following commit is the troublesome one: https://sourceforge.net/p/gnu-efi/code/ci/deb8a7f267d96299b9aa41300539f617db54c2a9 All commits prior to that one work fine for me, but once I build with that one, it fails in the way you describe. The commit in question changes SetMem() and CopyMem() to use the EFIAPI calling...
-
Ford Prefect posted a comment on discussion General Discussion
I'm aware of it being a known issue whereby Windows won't show the manufacturer's boot logo when booted via rEFInd, but I suspect it should be fixible and, better still, customisable. What I noticed was that if you use the "use_graphics_for = windows" option, the screen will go completely white (taking the background colour from the banner) and the Windows twirly circle (Win11) will draw over the white screen; but just where the circle is. The rest of the display remains white. It would appear that...
-
Fixed 'fat' Apple binary detection bug
-
I bisected gnu-efi and the offending commit is https://github.com/ncroxon/gnu-efi/commit/262c1f4604dded6485ef338345487c421ab3c8cb
-
Build logs attached.
-
If rEFInd is built against gnu-efi 3.0.18, I get start_image() returned Load Error in VirtualBox (I didn't test on real hardware yet). Booting is not possible. This is using Arch Linux package refind 0.14.1-1 (currently in the testing repo) which is built against the gnu-efi 3.0.18-1 package. Rebuilding refind 0.14.1 against Arch package gnu-efi 3.0.17-3 makes it work. See Arch Linux bug: https://gitlab.archlinux.org/archlinux/packaging/packages/refind/-/issues/2
-
Cheers. Forced pushed the cleaner syntax.
-
Minor logging bug fix & optimization in IsValidLoader()
-
Fix typo in refind-sb-healthcheck message
-
Cheers. Will leave as is
-
joevt posted a comment on merge request #50
For CHAR8 *Header the simplest check is probably: (*(UINT32 *)Header == FAT_ARCH) For CHAR8 Header[512] the simplest check is probably: (*(UINT32 *)&Header == FAT_ARCH) I believe the proposed check works for either case but is not as easy to read: (*(UINT32 *)&Header[0] == FAT_ARCH)
-
Backport Apple Fat Binary Validity Fix from RefindPlus
-
Forgot to save NEWS.txt after editing it....
-
Added Shim information to Info/About screen
-
You need to change the source code to do that.
-
Code optimizations, mostly in scan.c's FindTool() and IsValidTool()
-
Restructured tool-scanning code; added also_scan_tool_dirs token
-
Richard Province posted a comment on discussion General Discussion
Does anyone know of a way to make the OS 2 rows instead of one row that you have to scroll? I have too many OS's installed to fit on one screen without scrolling and I really dont like to scroll.
-
Remove a few commented-out lines
-
Improved RPM & Debian packaging, particularly related to Secure Boot
-
Version 0.14.1 final release
-
-
-
-
-
-
-
-
-
-
Updated LodePNG to version 20230410
-
Remove bootx64.efi (etc.) as valid memtest filenames
-
Update of copyright dates in multiple files
-
Remove duplicate tools caused by duplicate tool locations
-
Move memtest from boot loader to tools menu if found in a boot loader location
-
Fixed bug in refind-install that caused --ownhfs option to fail
-
jimmy CHou modified a comment on discussion General Discussion
I often simulate a "sandbox" by cloning (using Macrium/Reflect) my Win11 boot drive to another SSD in the same system. Even though it succeeds and is bootable w/o REFIND, the latter maintains that I have only one Windows installation - i.e., I never get a 2nd (seemingly "deserved") Gray Flag. Is REFIND too smart for its own good - somehow filtering out the cloned drive? (Old Dell Precision Tower 5810, so I recognize, that may be the prob.) Last, I did modify the conf file to introduce a 5 second...
-
I often simulate a "sandbox" by cloning (using Marcrium/Reflect) by Win11 boot drive to another SSD in the same system. Even though it succeeds and is bootable via the BIOS/UEFI, REFIND maintains that I have only one Windows installation - i.e., I never get a 2nd (seemingly "deserved") Gray Flag. Is REFIND too smart for its own good - somehow filtering out the cloned drive? (Old Dell Precision Tower 5810, so I recognize, that may be the prob.) Last, I did modify the conf file to introduce a 5 second...
-
sgn posted a comment on discussion General Discussion
From binutils 2.38, objcopy learnt a new option --target=efi-app-aarch64 to build a PE/COFF executable for arm64. Also "objcopy -O binary" no longer works with arm64: /usr/bin/aarch64-linux-gnu-objcopy: refind_aa64.efi: file format not recognized Switch to new option, unless we have old objcopy (by the define OBJCOPY_LT_2_38). Make.common | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Make.common b/Make.common index 5dfa202..1fb6a97 100644 --- a/Make.common +++ b/Make.common @@ -154,8 +154,10...
-
Thanks for the submission. I've accepted it, but added a drop shadow to the icon, to match other rEFInd icons.
-
Adds icon for EndeavourOS
-
add the EndeavourOS icon
-
Document recent Btrfs RAID code submission in NEWS.txt
-
Thanks for the contribution!
-
port RAID1C3/4 support from grub2
-
Elvis Trujanovic posted a comment on discussion General Discussion
Yes we all know that but this framework is not an pure emulator too so there is a high possibility of using one of these frameworks to dynamically be translator between two different CPU architectures (one is host architecture that will get translated memory and stuff and one is target architecture that we want to run but it's not supported by default in the host machine). Framework is better than emulator in this case. Just download an example executables from Unicorn/Quiling framework (shared library...
-
Startergo posted a comment on discussion General Discussion
rEFInd is a bootloader not an emulator.
-
Is it possible to implement Unicorn Emulation Framework in rEFInd or anything similar to that to emulate CPU instructions and architecture to be able to execute any bootloader from this boot manager. Basically if boot manager detects that an Windows/Ubuntu ARM64 bootloader is installed, it will use that framework to emulate support for that architecture and execute that bootloader that could lead to booting ARM64 OS on Intel/AMD CPUs natively without needing to run the full VM in the booted system...
-
bam80 posted a comment on discussion General Discussion
Thank you, I will when I get a chance. Hopefully, the author of the original will respond too.
1 >