Activity for rEFInd
-
Nicolas posted a comment on discussion General Discussion
Is there an update for the ext4 drivers? I'm having problems with loading kernels 6.18, 6.19 and currently the only workaround seems to be to downgrade to an older kernel version
-
Arthur LE MOIGNE posted a comment on merge request #60
I was finally able to update MR... Also add 1 commit to resize initial background to always fill screen in case of resolution change. This way, GlobalConfig.InitialScreen will always fill the entire screen whatever happen. Banner size should not really matter anymore.
-
dakanji modified a comment on merge request #60
Saving the initial screen and then using this as the banner is a clever way to get around previous shortcomings as your pictures demonstrate. However, blind spots may still exist. You might want to make sure you check scenarios like where banners are full size background images and not just a small image like the rEFind icon one you tested for instance. Well done regardless.
-
Saving the initial screen and then using this as the banner is a clever way to get around the previous shortcomings as your pictures demonstrate. However, blind spots may still exist. You might want to make sure you check scenarios like where banners are full size background images and not just a small image like the rEFind icon one you tested for instance. Well done regardless.
-
Saving the initial screen and then using this as the banner is a clever way to get around the previous shortcomings as your pictures demonstrate. However, blind spots may still exist. You might want to make sure you check scenarios like where banners are full size background images for instance and not just a small image like the rEFind one you tested for instance. Well done regardless.
-
Saving the initial screen and then using this as the banner is a clever way to get around the previous shortcomings as your pictures demonstrate. However, I suspect your focus is still a bit too narrow and that you have a few blind spots. You might want to make sure you test scenarios like where banners are full size background images for instance and not just a small image like the rEFind one you tested. Well done regardless.
-
Saving the initial screen and then using this as the banner is a clever way to get around the previous shortcomings as your pictures demonstrate. However, I suspect your focus is still a bit too narrow and that you have a few blind spots. You might what to make sure you test scenarios like where banners are full size background images for instance and not just a small image like the rEFind one you tested. Well done regardless.
-
Saving the initial screen and then using this as the banner is a clever way to get around the previous shortcomings as your pictures demonstrate. However, I suspect your focus is still a bit too narrow and have a few blind spots. You might what to make sure you test scenarios like where banners are full size background images for instance and not just a small image like the rEFind one you tested. Well done regardless.
-
Saving the initial screen and then using this as the banner is a clever way to get around the previous shortcomings as your pictures demonstrate. Well done. Best now wait for input from the maintainer.
-
Saving the initial screen and then using this as the banner is a clever way to get around the previous shortcomings as your pictures demonstrate. The only remaining issue I see is that your focus is still perhaps a bit too narrow and that the HideBanner setting should be working as they currently do without change. That is, should not be "transparent" regardless of whether the user has set the transparent flag or not. Ignoring that I think the change muddies the perception given to users about what...
-
I updated a bit my code but for some reason the MR is not reflecting the changes. Here is the final commit: https://sourceforge.net/u/alemoigne/refind/ci/b1a3c8ce6d984bfb8fd8e1436ad359ff5d88994f/ I am not familiar with SourgeForge contributions (more familiar with Github, Bitbucket and Gitlab). Happy to update MR if someone point me to any procedure to do it. About your comment, I am not sure your first suggestion would work :/ . Every call to egClearScreen need to be catch to have full transparency...
-
The transparency feature only works if HIDEUI_FLAG_BANNER is also set. This is undesirable IMO and think it should not be tied to two settings. While what is happening behind the scenes is that transparent actually means the banner is not loaded, the perception being given is that the banner is loaded but made transparent. However, this picture is being muddled by tying the feature to HIDEUI_FLAG_BANNER, which is meant to indicate the banner is to be made absent. Also, the established outcome of...
-
The transparency feature only works if HIDEUI_FLAG_BANNER is also set. This is undesirable IMO and think it should not be tied to two settings. While what is happening behind the scenes is that transparent actually means the banner is not loaded, the perception being given is that the banner is loaded but made transparent. However, this picture is being muddled by tying the feature to HIDEUI_FLAG_BANNER, which is meant to indicate the banner is to be made absent. Also, the established outcome of...
-
The transparency feature only works if HIDEUI_FLAG_BANNER is also set. This is undesirable IMO and think it should not be tied to two settings. While what is happening behind the scenes is that transparent actually means the banner is not loaded, the perception being given is that the banner is loaded but made transparent. However, this picture is being muddled by tying the feature to HIDEUI_FLAG_BANNER, which is meant to indicate the banner is to be made absent. Also, the established outcome of...
-
The transparency feature only works if HIDEUI_FLAG_BANNER is also set. This is undesirable IMO and think it should not be tied to two settings. While what is happening behind the scenes is that transparent actually means the banner is not loaded, the perception being given is that the banner is loaded but made transparent. However, this picture is being muddled by tying the feature to HIDEUI_FLAG_BANNER, which is meant to indicate the banner is to be made absent. Also, the established outcome of...
-
The transparency feature only works if HIDEUI_FLAG_BANNER is also set. This is undesirable IMO and think it should not be tied to two settings. While what is happening behind the scenes is that transparent actually means the banner is not loaded, the perception being given is that the banner is loaded but made transparent. However, this picture is being muddled by tying the feature to HIDEUI_FLAG_BANNER, which is meant to indicate the banner is to be made absent. Also, the established outcome of...
-
The transparency feature only works if HIDEUI_FLAG_BANNER is also set. This is undesirable IMO and think it should not be tied to two settings. While what is happening behind the scenes is that transparent actually means the banner is not loaded, the perception being given is that the banner is loaded but made transparent. However, this picture is being muddled by tying the feature to HIDEUI_FLAG_BANNER, which is meant to indicate the banner is to be made absent. Also, the established outcome of...
-
The transparency feature only works if HIDEUI_FLAG_BANNER is also set. This is undesirable IMO and think it should not be tied to two settings. While what is happening behind the scenes is that transparent actually means the banner is not loaded, the perception being given is that the banner is loaded but made transparent. However, the picture is being confused by tying the feature to HIDEUI_FLAG_BANNER, which is meant to indicate the banner is to be made absent. Also, the established outcome of...
-
The transparency feature only works if HIDEUI_FLAG_BANNER is also set. This is undesirable IMO and think it should not be tied to two settings. While what is happening behind the scenes is that transparent actually means the banner is not loaded, the perception being given is that the banner is being loaded but being made transparent. However, the picture is being confused by tying the feature to HIDEUI_FLAG_BANNER, which is meant to indicate the banner is to be made absent. Also, the established...
-
The transparency feature only works if HIDEUI_FLAG_BANNER is also set. This is undesirable IMO and think it should not be tied to two settings. While what is happening behind the scenes is that transparent actually means the banner is not loaded, the perception being given is that the banner is being loaded but being made transparent. However, the picture is being confused by tying the feature to HIDEUI_FLAG_BANNER, which means the banner is being made absent. Also, the established outcome of setting...
-
The transparency feature only works if HIDEUI_FLAG_BANNER is also set. This is undesirable IMO and think it should not be tied to two settings. While what is happening behind the scenes is that transparent actually means the banner is not loaded, the perception being given is that the banner is being loaded but being made transparent. However, the picture is being confused by tying the feature to HIDEUI_FLAG_BANNER, which means the banner is being made absent. Also, the established outcome of setting...
-
Thanks for your feedback. Indeed it make more sens using banner_scale to reflect that capability. I just open an MR to better talk and review the changes: https://sourceforge.net/p/refind/code/merge-requests/60/
-
Anonymous created merge request #60 on Code
Add transparent background capabilities
-
The transparent version looks interesting but while it may work from your perspective, you need to make sure such proposals work universally. Imagine a scenario where a user has set this and "GlobalConfig.HideUIFlags |= HIDEUI_FLAG_BANNER" is therefore also forced on along with "GlobalConfig.BannerFileName" being set to "transparent". If they then at some point later decide to try a theme, include a theme.conf file and this includes a banner setting pointing to a file, "GlobalConfig.BannerFileName"...
-
The transparent version looks interesting but while it may work from your perspective, you need to make sure such proposals work universally. Imagine a scenario where a user has set this and "GlobalConfig.HideUIFlags |= HIDEUI_FLAG_BANNER" is therefore also forced on along with "GlobalConfig.BannerFileName" being set to "transparent". If they then at some point later decide to try a theme, include a theme.conf file and this includes a banner setting pointing to a file, "GlobalConfig.BannerFileName"...
-
The transparent version looks interesting but while it may work from your perspective, you need to make sure such proposals work universally. Imagine a scenario where a user has set this and "GlobalConfig.HideUIFlags |= HIDEUI_FLAG_BANNER" is therefore also set along with "GlobalConfig.BannerFileName" being set to "transparent". If they then at some point later decide to try a theme, include a theme.conf file and this includes a banner setting pointing to a file, "GlobalConfig.BannerFileName" will...
-
The transparent version looks interesting but while it may work from your perspective, you need to make sure such proposals work universally. Imagine a scenario where a user has set this and "GlobalConfig.HideUIFlags |= HIDEUI_FLAG_BANNER" is therefore also set along with "GlobalConfig.BannerFileName" being set to "transparent". If they then at some point later decide to try a theme, include a theme.conf file and this includes a banner setting pointing to a file, "GlobalConfig.BannerFileName" will...
-
The transparent version looks interesting but while it may work from your perspective, you need to make sure such proposals work universally. Imagine a scenario where a user has set this and "GlobalConfig.HideUIFlags |= HIDEUI_FLAG_BANNER" is therefore also set along with "GlobalConfig.BannerFileName" being set to "transparent". If they then at some point later decide to try a theme, include a theme.conf file and this includes a banner setting pointing to a file, "GlobalConfig.BannerFileName" will...
-
Another alternative could be adding concept of "transparent" banner. It may be even more proper since it does not add any new configuration keyword. It just add reserved keyword for banner field. Tested and working with below config: timeout -1 use_graphics_for osx,linux banner transparent
-
Another alternative could be adding concept of "transparent" banner. It may be even more proper since it does not add any new configuration keyword. It just add reserved keyword for banner field. Tested and working with below config: timeout -1 use_graphics_for osx,linux hideui banner banner transparent
-
Hi everyone, I would like to suggest a patch to keep motherboard manufacturer logo present and do not clear screen while booting. The main goal is to have a clean boot (as it is with Windows) using rEFInd + Plymouth with BGRT theme. With that patch I am successfully able to have a full boot without any flickering and nothing display on screen from power up to login screen. The options that also need to be enable to make it work are listed bellow: timeout -1 use_graphics_for osx,linux hideui banner...
-
Viorel posted a comment on discussion General Discussion
Something changed in objcopy
-
Bribbo38 modified a comment on discussion General Discussion
Is there any news on this? 2026 and the issue is still here, is there some guide or someone who can help me fix it with the patch (even tough it's not the best or whatever) EDIT: I managed to manually patch it and compiled it using the still not merged fix: https://sourceforge.net/p/refind/code/merge-requests/55/.
-
HJ Jansen posted a comment on discussion General Discussion
The file " 40_custom" in the grub menu then looked like this (this worked before I entered developer mode and before I enabled Andoid Subsystem): menuentry "Fydeos" { set root='(hd0,6)' set img=/fydeos/fydeos_dual_boot.img search --label --set root FYDEOS-DUAL-BOOT loopback loopdev $img linux (loopdev,gpt12)/syslinux/vmlinuz.A init=/sbin/init root=/dev/sda6 boot=local rootwait noresume noswap ro loglevel=7 console= i915.modeset=1 cros_efi fydeos_dualboot initrd /boot/dual_boot_ramfs.cpio } After...
-
Note that I tried this. And it worked. Until it didn't work anymore. What happens is: you make an entry for Fydeos in the Efi-partition. This entry will do. Or you can make it easier, skipping the multi-boot. However, when you do either of two things on Fydeos the efi partition information will be altered by Fydeos itself. And when the grub-information is still the same and doesn't change, strange things will happen to your system. So when does this happen: a. When you enter "developer mode" in Fydeos...
-
Note that I tried this. And it worked. Until it didn't work anymore. What happens is: you make an entry for Fydeos in the Efi-partition. This entry will do. Or you can make it easier, skipping the multi-boot. However, when you do either of two things on Fydeos the efi partition information will be altered by Fydeos itself. And when the grub-information is still the same and doesn't change, strange things will happen to your system. So when does this happen: a. When you enter "developer mode" in Fydeos...
-
Wouldn't stripping stuff out break building for those building with older versions? I presume they were added in this new version but were missing before, hence the original decision to include in rEFInd. Would it better to make inclusion conditional instead? Something like this perhaps? #ifndef CompareGuid RELATED ITEM PREVIOUSLY DELETED #endif #ifndef AsciiLen RELATED ITEM PREVIOUSLY DELETED #endif Just a thought
-
Tianon posted a comment on discussion General Discussion
For now, I've committed those hacks in https://salsa.debian.org/debian/refind/-/commit/1c2775e5ee9bbbdfb8701e513d70b009345a9d87, but I don't plan to upload that to Debian unless I can do some direct testing or Rod tells me that my hacks are actually OK and seem sane. 😅
-
Ok, after applying #define GNU_EFI_USE_REALLOCATEPOOL_ABI 0 in the appropriate places (which feels wrong, but maybe it's not?) and deleting both AsciiStrLen and CompareGuid from the rEFInd source code completely, I have a successful build again, so hopefully that's enough clues to come up with what you think is a suitable "real" fix for these, @srs5694 🙇 ❤️
-
... the next commit I bump into is https://github.com/ncroxon/gnu-efi/pull/40/commits/a093fe03786b15ecabaa0d16f84c8133f76ca0c0 and the recurring theme of "match EDK2 ABI" causing breakage in rEFInd continues 😂
-
I believe https://github.com/ncroxon/gnu-efi/pull/25/commits/f3656c88007a775562b625a2cfe1bc54c1170bfe is the specific commit which introduced this bug (note the two different function signatures for ReallocatePool there). I don't think it's the correct solution (so I don't plan to apply it), but I can get past these errors with a patch like the following: diff --git a/EfiLib/legacy.c b/EfiLib/legacy.c index 4ee6229..258e9af 100644 --- a/EfiLib/legacy.c +++ b/EfiLib/legacy.c @@ -15,6 +15,7 @@ * */...
-
Just for compairson's sake, here's the exact errors I'm getting in Debian: legacy.c: In function ‘BdsAddNonExistingLegacyBootOptions’: legacy.c:794:31: error: passing argument 1 of ‘ReallocatePool_1’ makes integer from pointer without a cast [-Wint-conversion] 794 | mBootOptionBbsMapping, | ^~~~~~~~~~~~~~~~~~~~~ | | | BOOT_OPTION_BBS_MAPPING * In file included from /usr/include/efi/efi.h:75, from legacy.c:19: /usr/include/efi/legacy.h:35:19: note: expected ‘UINTN’ {aka ‘long unsigned int’} but argument...
-
Hah, I applied https://sourceforge.net/p/refind/code/ci/cf542da4459ff18535b0ae3a7910af032834e469/ in the Debian package to fix https://bugs.debian.org/1121853 and ran into this same issue (likely thanks to https://tracker.debian.org/news/1705409/accepted-gnu-efi-400-1-source-into-unstable/ on 2026-01-07)!
-
David Runge posted a comment on discussion General Discussion
Hi! I'm maintaining this project as a package for Arch Linux. I'm currently trying to rebuild it against gnu-efi 4.0.4. Unfortunately I'm running into several errors due to pointer to int and int to pointer conversion without a cast: /usr/bin/gcc -Os -fno-strict-aliasing -fno-tree-loop-distribute-patterns -fno-stack-protector -fshort-wchar -Wall -DEFIX64 -DEFI_FUNCTION_WRAPPER -m64 -mno-red-zone -fpic -I/usr/include/efi -I/usr/include/efi/x86_64 -I/usr/include/efi/protocol -I../include -I../refind...
-
Both pass my tests Thanks for the update
-
Scott Ellis posted a comment on discussion General Discussion
Both of those drivers pass my tests, which were: 1) cp of vmlinuz... from {btrfs|ext4} to FAT32 and check file size (did not do cksum) 2) cat /etc/os-release (btrfs only for this test) which is a symlink 3) cat /etc/xattr.conf (btrfs only for this test) which is a small file 4) Load vmlinuz... successfull from {btrfs|ext4}
-
@scotteai ... Almost done. Do you mind giving the attached a final once over? Zip has "almost final" BtrFS and Ext4 drivers.
-
@scotteai ... Please give the [REMOVED] a try.
-
Your /etc/os-release is a symlink. The [REMOVED] should plug that blind spot.
-
@scotteai ... Almost done. Do you might giving the attached a final once over? Zip has "almost final" BtrFS and Ext4 drivers.
-
Roderick W. Smith committed [cf542d] on Code
Fix build problems on Debian Testing caused by objcopy changes
-
Is there any news on this? 2026 and the issue is still here, is there some guide or someone who can help me fix it with the patch (even tough it's not the best or whatever)
-
Hi, Shim can also be named BOOTX64.EFI (this is its default name in /boot in shim 15.8), so here is a small patch to add this name to refind-install.
-
Yes, it is currently a beta and that was a debug build. Actually, an NPT build, which is one that gives detailed output in the RefindPlus setup. Usable though (at least in graphics screen mode) but yeah, the REL build will be best for day to day use. WIll move things through the dev cycle as needed and presently, an RC version that can be built will be pushed to the GitHub repo ahead of the next release. Backporting might be a challenge due to quite a bit of refactoring that has taken place and is...
-
6C works great. If it wasn't for the debug printf's, I'd use this on my daily driver. :-)
-
Your /etc/os-release is a symlink. The attached should plug that blind spot.
-
That's cool. It does not have extra size checks for items with "Inline" extents, while I had added checks everywhere I could. Turns out the vmlinuz file goes through a "Regular" extents code path while these are "inline" and that the checks I added were too strict for very small files. Anyway, relaxed these in the {REMOVED} to just ensure we have data as want to keep some sanity checks but if still problematic, can just return stuff without checks here as the baseline does.
-
Your os-release is a symlink. The attached should process that.
-
Partial success. The kernel copy still works, and now cat'ing some of the smaller files like xattr.conf works, but not all. For example, os-release fails (but per above, does work with the stock rEFInd driver).
-
Nice one. Thanks. The process used for BtrFS is reliable but slowish as it does one block at a time. Handling contiguous void blocks at once is better as long as properly detected. Please run the {REMOVED} to confirm nothing's been broken with this optimisation. EDIT: Just realised that you may have used a v6.8 kernel to test the Ext4 driver. However, the hole apparently appeared in v6.17 and does not affect v6.8.
-
That's cool. It does not have extra size checks for items with "Inline" extents, while I had added checks everywhere I could. Turns out the vmlinuz file goes through a "Regular" extents code path while these are "inline" and that the checks I added were too strict for very small files. Anyway, relaxed these in the attached to just ensure we have data as want to keep some sanity checks but if still problematic, can just return stuff without checks here as the baseline does.
-
Unfortunately (?), yes I can. rEFInd 14.2's btrfs driver seems to work fine on those files.
-
The 5A run "fails different" to an extent. Please give the {REMOVED} a go.
-
Can you cat those files with the baseline btrfs driver where 6A fails?
-
Check whether you can cat those files with the baseline driver where it fails with 6A.
-
Using 6A, some files on one btrfs partition (the one that has the holey kernels, zstd compression, etc.) report "Status 5" when trying to cat them. Trivial files, like /etc/os-release and /etc/xattr.conf. The 6A driver isn't totally broken though, as those same files on an older btrfs partition can be viewed. As a sanity check, the same files that report "Status 5" work in Linux (duh) and with the btrfs-efi driver that I built/hacked-on per way earlier in this thread.
-
Using 6A, some files on one btrfs partition (the one that has the holey kernels, zstd compression, etc.) report "Status 5" when trying to cat them. Trivial files, like /etc/os-release and /etc/xattr.conf. The 6A driver isn't totally broken though, as those same files on an older btrfs partition can be viewed. As a sanity check, the same files that report "Status 5" work in Linux (duh) and with the btrfs-efi driver that I built/hacked-on per way earlier in this thread.
-
Got it on 6.18 /6.8. Thanks. Basically done with the shell based tests and you can report on funnies seen elsewhere.
-
I used a 6.18 (not 6.8) which does seem to have a hole. Attached is the good behaviour with 6A. Works like the earlier BTRFS test version. On a related topic, I tried setting 6A as the driver for rEFInd and got some "volume corrupted" warnings/errors on startup in the shell (I assume from the driver) but didn't want to muddy things in this thread. Basically 6A works in the tests we were doing historically, but there may be other cases where things aren't 100%. If you want me to report those now,...
-
Nice one. Thanks. The process used for BtrFS is reliable but slowish as it does one block at a time. Handling contiguous void blocks at once is better as long as properly detected. Please run the attached to confirm nothing's been broken with this optimisation. EDIT: Just realised that you may have used a v6.8 kernel to test the Ext4 driver. However, the hole apparently appeared in v6.17 and does not affect v6.8.
-
Nice one. Thanks. The process used for BtrFS is reliable but slowish as it does one block at a time. Handling contiguous void blocks at once is better as long as properly detected. Please run the attached to confirm nothing's been broken with this optimisation. EDIT: Just noticed that you may have used a v6.8 kernel to test the Ext4 driver. However, the hole apparently appeared in v6.17 and does not affect v6.8.
-
Nice one. Thanks. The process used for BtrFS is reliable but slowish as it does one block at a time. Handling contiguous void blocks at once is better as long as properly detected. Please run the attached to confirm nothing's been broken with this optimisation. EDIT: Just noticed that you may have used a v6.8 kernel to test the Ext4 driver. However, the hole apparently appeared in v6.17 and does not affect v6.8.
-
Nice one. Thanks. The process used for BtrFS is reliable but slowish as it does one block at a time. Handling contiguous void blocks at once is better as long as properly detected. Please run the attached to confirm nothing's been broken with this optimisation.
-
Nice one. Thanks. The process used for BtrFS used is reliable but slowish as it does one block at a time. The attached tries to handle contiguous void blocks at once. Please run the attached (BtrFS) to confirm nothing's been broken with this optimisation.
-
That 01A works. Test procedure was to use the current rEFInd ext4 driver and verify that a cp vmlinuz... fs1:\ fails with I/O error as in the prior test, then do the exact same thing with the 01A driver and confirm it succeeds (screenshot attached). For sanity, loading the kernel from ext4 with 01A also works.
-
@scotteai ... Please give the attached a try.
-
Alexei S. posted a comment on discussion General Discussion
Not sure if this is something that's supposed to work or not. I have a MacPro 1,1 and I wanted to use refind to boot from Win10 installer USB stick that I made on a PC with Microsoft tool for that. I used ExtFat. Refind does show the USB stick as legacy OS, but after selecting it, gives a Not found error.
-
Thanks. Will get round to building one with an attempted fix presently. Will ping you when ready as might take some time.
-
I get "IO Error" with the rEFInd 0.14.2 ext4 driver trying to cp a kernel (same ones that were our btrfs test case) from ext4. For sanity, copying one from btrfs to the same partition succeeds (so it's not a destination partition error).
-
Seems @scotteai has checked out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from the FSW_EFI code in the driver, despite the lower order items (at least FSW_BTRFS) apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this...
-
Seems @scotteai has checked out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from the FSW_EFI code in the driver, despite the lower order items (at least FSW_BTRFS) apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this...
-
Seems @scotteai has checked out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from the FSW_EFI code in the driver, despite the lower order items (at least FSW_BTRFS) apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this...
-
Seems @scotteai has checked out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from the FSW_EFI code in the driver, despite the lower order items (at least FSW_BTRFS) apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this...
-
Thanks ... Use the current driver from rEFInd as baseline if/when you are able.
-
I do not - only FAT32 and BTRFS here. If I get some cycles I'll try making an Ext4 partition and see if I can recreate the problem. Using the driver from the latest RefindPlus release should show the symptom?
-
@scotteai ... You wouldn't happen to have an Ext4 implementation with the problem kernel version(s) sitting around, would you? Basically tried to migrate the fix across from BtrFS but given the differences between the two fs types, it would be nice to confirm it works.
-
@scotteai ... You wouldn't happen to have an Ext4 implementation with the problem kernel version(s) sitting around, would you? Basically tried to migrate the fix across from BtrFS but how the given the differences between the two fs types, it would be nice to confirm it works.
-
Brilliant ... Let's take the win. The log output was useful. While there were some other items found and handled along the way, the issue was ultimately that the driver could not handle holes in the file. I note that the commit to the kernel identified seemed to be one where some section was added to the build and was marked to be stripped out later. Perhaps this introduced a hole. Likely affects the other FS drivers. Will clean up and roll into RefindPlus later. Can then see about backporting to...
-
The bad news is that I can't get a screenshot of errors from 5B-2. The good news is that I can't get a screenshot because it actually loads the kernel properly (which then clears the UEFI console). :-) Attached is the tail of the cp fs2:\boot\vmlinuz fs0:\ output. Likely not interesting.
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Only one is relevant to our...
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Only one is relevant to this...
-
The 5A run "fails different" to an extent. Please give the attached a go.
-
The 5A run "fails different" to an extent. Please give the attached a go.
-
I did a quick test of installing a kernel into /boot (BTRFS) with compress=zstd (what I normally use) vs compress=none (via remaount before cp'ing over the new kernel image) and the same kernel errors out the same way with 5A. I'm not savvy enough to know how to check that there are legitimately no extents compressed in the file, but if I trust that the filesystem is doing the right thing with the mount options then indeed zstd seems not the culprit.
-
The console buffer filled up quickly, so here's the last part of the 5A log. All the earlier parts are similar (only the "failure" at the end is interesting :-) ). Nonetheless, still failed. :-(
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Only one is relevant to this...
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Only one is relevant to this...
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Only one is relevant to this...
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Needs looking into whether porting...
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Needs looking into whether porting...
1 >
