For the moment, the RPM and Debian packages I build do not use this new naming feature, since I can't be sure what version of Shim might be picked up. The advantage, of course, is that rEFInd needn't "lie" about its name, which makes for less confusion in filenames. This works, but is likely to be more delicate than using the default Shim follow-on name of grub圆4.efi. (Actually, Shim 0.4 supported this, but it required a broken path specification.) I've added support for this feature to install.sh: Adding the -keepname option to install.sh causes the script to preserve rEFInd's regular filename and to register the approprirate follow-on parameters to have Shim launch rEFInd by that name. This version also introduces a new feature, which is also Shim-related: Since version 0.7, Shim has supported launching binaries other than grub圆4.efi by passing them on the command line. I want to release this workaround version to head off further problems in the near term, though. As such, the workaround in this release may break with a future Shim. I consider this a "band-aid" patch, though, because it relies on a quirk of Shim's logic to bypass its de-registration. I quickly discovered a workaround, which I've implemented in this release.
Refind boot manager configuration drivers#
Since rEFInd's drivers are binaries, if you use a single driver, that means that you won't be able to launch anything that requires validation via Shim. This creates a new problem, though: rEFInd can validate just one binary before it's "cut off" from Shim. This is done to avoid problems in a boot path in which Shim launches fallback.efi, which in turn launches another Shim. Specifically, Shim 0.8 now de-registers itself from the EFI after a follow-on program launches another one. (See this thread for one such report.) It turns out that the problem was not a new bug in rEFInd, but rather a change from Shim 0.7 to Shim 0.8 that made it next to useless with rEFInd.
0 kommentar(er)
