+<li><b>0.9.2 (9/19/2015)</b>—Soon after releasing 0.9.1, I started receiving bug reports about problems with it and Shim 0.8. (See <a href="https://sourceforge.net/p/refind/discussion/general/thread/2c248b11/?limit=25#1324">this thread</a> 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. Specifically, Shim 0.8 now de-registers itself from the EFI after a follow-on program launches another one. This is done to avoid problems in a boot path in which Shim launches <tt>fallback.efi</tt>, which in turn launches <i>another</i> Shim. This creates a new problem, though: rEFInd can validate just one binary before it's "cut off" from Shim. 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. I quickly discovered a workaround, which I've implemented in this release. I consider this a "band-aid" patch, though, because it relies on a quirk of Shim's logic to bypass its de-registration. As such, the workaround in this release may break with a future Shim. A true fix will take longer to develop. I want to release this workaround version to head off further problems in the near term, though. This version also introduces a new feature, which is also Shim-related: Since version 0.7, Shim has supported launching binaries other than <tt>grubx64.efi</tt> by passing them on the command line. (Actually, Shim 0.4 supported this, but it required a broken path specification.) I've added support for this feature to <tt>install.sh</tt>: Adding the <tt>--keepname</tt> 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 works, but is likely to be more delicate than using the default Shim follow-on name of <tt>grubx64.efi</tt>. The advantage, of course, is that rEFInd needn't "lie" about its name, which makes for less confusion in filenames. For the moment, the RPM and Debian packages I build do <i>not</i> use this new naming feature, since I can't be sure what version of Shim might be picked up. These changes do not affect users who do not use Secure Boot.</li>
+