sort entries within each directory by time stamp.
-0.3.0 (?/??/2012):
+0.3.1 (?/??/2012):
+------------------
+
+- Modified loader scanning code to sort boot loader entries within a
+ directory by modification time, so that the most recently-modified loader
+ is first among those in a given directory. Thus, if you specify a
+ directory name (or volume name, for loaders stored in the root directory
+ of a volume) as the default_selection, the most recent of those loaders
+ will be the default. This is intended to help with Linux kernel
+ maintenance when using the EFI stub loader; set up this way, the most
+ recent kernel copied to your kernel directory will be the default,
+ obviating the need to adjust the refind.conf file when adding a new
+ kernel. If you want to change the default among those in the default
+ directory, you can use "touch" to adjust the modification timestamp.
+
+- Tweaked code to find loader-specific .icns file so that it finds files
+ for Linux kernels without .efi extensions. In this case, files should be
+ named the same as the kernels they match, but with .icns extensions. For
+ instance, bzImage-3.3.2 should have an icon called bzImage-3.3.2.icns.
+ (The old code would have looked for an icon called bzImage-3.3.icns.)
+
+- Eliminated bogus OS loader tags for filenames that end in ".icns" when
+ the scan_all_linux_kernels option is set.
+
+0.3.0 (4/22/2012):
------------------
- I'm officially upgrading this project's status from "alpha" to "beta" and
</tr>
<tr>
<td><tt>default_selection</tt></td>
- <td>A substring of a boot loader's title</td>
- <td>Sets the default boot OS based on the loader's title, which appears in the main menu when you select the loader; the text reads <tt>Boot <i>Title</i> from <i>Disk</i></tt>. You can enter any substring of <tt><i>Title</i></tt> as the <tt>default_selection</tt>, so long as it's two or more characters in length. Be sure you enter a unique substring, though; rEFInd stops searching when it finds the first match. One-character entries are matched against the first character of the title, except for digits, which refer to the numeric order of the boot loader entries. (Note: In version 0.2.0, only the first character of this entry was used, and was matched against the first character of the title.)</td>
+ <td>A substring of a boot loader's title; or a numeric position</td>
+ <td>Sets the default boot OS based on the loader's title, which appears in the main menu beneath the icons when you select the loader. You can enter any substring of the title as the <tt>default_selection</tt>, so long as it's two or more characters in length. It's best to use a unique substring, since rEFInd stops searching when it finds the first match. Because rEFInd sorts entries within a directory in descending order by file modification time, if you specify a directory (or volume name, for loaders in a partition's root directory) as the <tt>default_selection</tt>, the most recent loader in that directory will be the default. One-character entries are matched against the first character of the title, except for digits, which refer to the numeric order of the boot loader entries. (Note: In version 0.2.0, only the first character of this entry was used, and was matched against the first character of the title.)</td>
</tr>
</table>
<p class="subhead">by Roderick W. Smith, <a
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
- <p>Originally written: 3/14/2012; last Web page update: 4/22/2012, referencing rEFInd 0.3.0</p>
+ <p>Originally written: 3/14/2012; last Web page update: 4/24/2012, referencing rEFInd 0.3.0</p>
<p>I'm a technical writer and consultant specializing in Linux technologies. This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!</p>
/dev/sda1 191284 16604 174681 9% /boot/efi
</pre>
+<p class="sidebar"><b>Warning:</b> If you're running Linux on a Mac, I recommend you install rEFInd under OS X. The Mac's boot process deviates a bit from EFI standards, so you'll probably have to use a tool called <tt>bless</tt> under MacOS to do the job. Alternatively, there's a new Linux program, <tt>hfs-bless</tt>, part of the <a href="http://www.codon.org.uk/~mjg59/mactel-boot/"><tt>mactel-boot</tt></a> package, that's supposed to work with <tt>efibootmgr</tt> to make a Mac HFS partition bootable. I've not yet tried it, though. There are also reports that the <tt>efibootmgr</tt> tool used under Linux can corrupt some Macs' firmware. Although I've seen some vague suggestions that this problem has been fixed under 3.<i>x</i> kernels, I haven't tested this claim.</p>
+
<p>This example shows that <tt>/dev/sda1</tt> is mounted at <tt>/boot/efi</tt>, which is a typical configuration. (The ESP can be on another disk or partition, but <tt>/dev/sda1</tt> is the most common place for an ESP.) If your output shows <tt>/boot</tt> or <tt>/</tt> under the <tt>Mounted on</tt> column, then your ESP isn't mounted. If you get a <tt>df: `/boot/efi': No such file or directory</tt> error message, then the <tt>/boot/efi</tt> directory doesn't even exist. In such cases, you may need to jump through some extra hoops, as described on my <a href="http://www.rodsbooks.com/efi-bootloaders/installation.html">EFI Boot Loader Installation</a> page.</p>
<p>Assuming the ESP is mounted at <tt>/boot/efi</tt>, you can install the rEFInd files as follows (you must be <tt>root</tt> to issue these commands, or precede each of them with <tt><b>sudo</b></tt>):</p>
<li>Rename the configuration file by typing <tt><b>mv refind.conf-sample refind.conf</b></tt>. Consult the <a href="configfile.html">Editing the rEFInd Configuration File</a> page for information on how to adjust your options.</li>
-<p class="sidebar"><b>Warning:</b> I've seen reports that Linux's <tt>efibootmgr</tt> utility can damage some Macs' firmware, necessitating re-flashing it. I've also seen some vague suggestions that this problem has been fixed with the 3.0 kernels, but I haven't been able to substantiate this suggestion. In either event, <tt>efibootmgr</tt> by itself can't completely change the EFI boot loader on Macs. Therefore, I recommend using <tt>bless</tt> from OS X to do this job on Apple hardware. Alternatively, there's a new Linux program, <tt>hfs-bless</tt>, part of the <a href="http://www.codon.org.uk/~mjg59/mactel-boot/"><tt>mactel-boot</tt></a> package, that's supposed to work with <tt>efibootmgr</tt> to make a Mac HFS partition bootable. I've not yet tried it, though.</p>
-
<a name="efibootmgr">
<li>On a UEFI-based system, type <tt><b>efibootmgr -c -l \\EFI\\refind\\refind_x64.efi -L rEFInd</b></tt> to add rEFInd to your EFI's list of available boot loaders, which it stores in NVRAM. (Adjust the path to the binary as required if you install somewhere else.) You may need to install this program on some systems; it's a standard part of most distributions' repositories.</li>
</a>
<h2>Installing rEFInd Using Mac OS X</h2>
</a>
-<p class="sidebar">One of the reasons I've abandoned rEFIt's GUI installation tools for Mac OS X is that there are several bug reports (such as <a href="https://sourceforge.net/tracker/index.php?func=detail&aid=3147364&group_id=161917&atid=821764">this one</a> and <a href="https://sourceforge.net/tracker/?func=detail&aid=3218104&group_id=161917&atid=821764">this one</a>) that the rEFIt installer may be causing filesystem corruption on disks over about 500 MiB. I don't have such a disk on my Mac, so I can't test solutions. Rather than risk other peoples' hard disks, I thought it best to revert to a manual installation proceudure that will, I hope, be less likely to cause problems. I've received reports that rEFInd doesn't have rEFIt's disk-corruption problems, so the manual installation procedure, although less convenient, seems to have paid dividends in the form of safety.</p>
+<p class="sidebar"><b>Warning:</b> One of the reasons I've abandoned rEFIt's GUI installation tools for Mac OS X is that there are several bug reports (such as <a href="https://sourceforge.net/tracker/index.php?func=detail&aid=3147364&group_id=161917&atid=821764">this one</a> and <a href="https://sourceforge.net/tracker/?func=detail&aid=3218104&group_id=161917&atid=821764">this one</a>) that the rEFIt installer may be causing filesystem corruption on disks over about 500 MiB. <a href="https://sourceforge.net/tracker/?func=detail&aid=3218104&group_id=161917&atid=821764">This</a> report on the problem, and particularly the post by mic-marchen, suggests that the problem is related to a bug in OS X's <tt>bless</tt> utility, and particularly its <tt>--info</tt> option, that causes it to corrupt data on disks with 4 KiB sectors. These <i>Advanced Format</i> disks are becoming increasingly common, particularly at larger disk sizes. Therefore, I <i>strongly</i> recommend that you <i>not</i> type <tt class="userinput">sudo bless --info</tt> to check the status of your installation if you have such a disk, or even if you suspect you might have such a disk. (I've seen Advanced Format disks as small as 320 GB.)</p>
<p>The procedure for installing rEFInd on a Mac is similar to that for installing it under Linux, except that you can (and probably should) install it to OS X's system partition or some other HFS+ partition rather than to the ESP, and you must use the <tt>bless</tt> utility rather than <tt>efibootmgr</tt>. To be precise, you should follow these steps:</p>
<ol>
-<li>Open a Terminal window in which you'll type the following commands.</li>
-
-<li>If you want to install rEFInd on your ESP, you must first mount it. You can do this by typing <b><tt>mkdir /Volumes/esp</tt></b> followed by <b><tt>sudo mount_msdos /dev/disk0s1 /Volumes/esp</tt></b>. Note that this step is optional, and in fact I've had problems blessing a boot loader on the ESP, so I don't recommend doing this. Also, you may need to change <tt>/dev/disk0s1</tt> to something else if your ESP is at an unusual location. Use a tool such as my <a href="http://www.rodsbooks.com/gdisk/">GPT fdisk (<tt>gdisk</tt>)</a> to examine your partition table to find your ESP if necessary.</li>
-
-<li>Type <b><tt>sudo mkdir -p /efi/refind</tt></b> to create a suitable directory for rEFInd. If you want to place rEFInd on the ESP or some other partition, you should adjust the pathname appropriately, as in <tt>/Volumes/esp/efi/refind</tt>. Alternatively, you can use the Finder to create the directory.</li>
-
-<li>Copy the files in the <tt>refind</tt> subdirectory of the rEFInd binary package to the like-named directory you've just created. You can do this in the Finder or by typing <b><tt>sudo cp -r refind/* /efi/refind/</tt></b> in your Terminal window after changing into the rEFInd package's main directory.</li>
-
-<li>Remove the file for the version of rEFInd you're not using, as in <b><tt>sudo rm /efi/refind/refind_ia32.efi</tt></b> on a Mac with a 64-bit EFI or <b><tt>sudo rm /efi/refind/refind_x64.efi</tt></b> on a Mac with a 32-bit EFI.</li>
-
-<li>If this is your first installation, type <b><tt>sudo mv /efi/refind/refind.conf-sample /efi/refind/refind.conf</tt></b> (adjusting the path as necessary) to rename the sample configuration file so that it will serve as a real configuration file. (Again, you can do this with the Finder, if you prefer.)</li>
-
-<li>Type <b><tt>sudo bless --setBoot --folder /efi/refind --file /efi/refind/refind_x64.efi</tt></b> to tell the computer to use rEFInd as the primary boot program. (Adjust the path and filename as necessary if you're placing rEFInd somewhere else or using the 32-bit version.) In theory, you can bless a boot file on an ESP by adding <b><tt>--mount <i>/Volumes/mounpoint</i></tt></b> to the command, where <tt><i>/Volumes/mounpoint</i></tt> is the location where you've mounted the partition. In practice, though, I've never gotten this to work. (If you know the trick to blessing a boot program on an ESP, please <a href="mailto:rodsmith@rodsbooks.com">drop me a line</a>.)</li>
+<li>Open a Terminal window in which you'll type the following
+ commands.</li>
+
+<li>If you want to install rEFInd on your ESP, you must first mount it. You
+ can do this by typing <b><tt>mkdir /Volumes/esp</tt></b> followed by
+ <b><tt>sudo mount -t msdos /dev/disk0s1 /Volumes/esp</tt></b>. Note
+ that this step is usually optional, and it makes the procedure a bit
+ more complex, so you might want to forego it. On the other hand,
+ installing to the ESP is required if you're using the whole-disk
+ encryption feature of OS X 10.7. Note that you may need to change
+ <tt>/dev/disk0s1</tt> to something else if your ESP is at an unusual
+ location. Use a tool such as my <a
+ href="http://www.rodsbooks.com/gdisk/">GPT fdisk (<tt>gdisk</tt>)</a>
+ to examine your partition table to find your ESP if necessary.</li>
+
+<li>Type <b><tt>sudo mkdir -p /efi/refind</tt></b> to create a suitable
+ directory for rEFInd. If you want to place rEFInd on the ESP or some
+ other partition, you should adjust the pathname appropriately, as in
+ <tt>/Volumes/esp/efi/refind</tt>. Alternatively, you can use the Finder
+ to create the directory.</li>
+
+<li>Copy the files in the <tt>refind</tt> subdirectory of the rEFInd binary
+ package to the like-named directory you've just created. You can do
+ this in the Finder or by typing <b><tt>sudo cp -r refind/*
+ /efi/refind/</tt></b> in your Terminal window after changing into the
+ rEFInd package's main directory.</li>
+
+<li>Remove the file for the version of rEFInd you're not using, as in
+ <b><tt>sudo rm /efi/refind/refind_ia32.efi</tt></b> on a Mac with a
+ 64-bit EFI or <b><tt>sudo rm /efi/refind/refind_x64.efi</tt></b> on a
+ Mac with a 32-bit EFI.</li>
+
+<li>If this is your first installation, type <b><tt>sudo mv
+ /efi/refind/refind.conf-sample /efi/refind/refind.conf</tt></b>
+ (adjusting the path as necessary) to rename the sample configuration
+ file so that it will serve as a real configuration file. (Again, you
+ can do this with the Finder, if you prefer.)</li>
+
+<li>"Bless" rEFInd by typing one of the following two commands:
+ <ul>
+ <li>If you're installing rEFInd to an ordinary HFS+ volume, type <tt
+ class="userinput">sudo bless --setBoot --folder /efi/refind --file
+ /efi/refind/refind_x64.efi</tt>. (Adjust the path and filename as
+ necessary if you're placing rEFInd somewhere else or using the
+ 32-bit version.)</li>
+ <li>If you're installing rEFInd on the ESP, type <tt
+ class="userinput">sudo bless --mount /Volumes/esp --setBoot --file
+ /Volumes/esp/efi/refind/refind_x64.efi</tt>, adjusting the mount
+ point and exact path to the file as appropriate for your
+ installation.</li>
+ </ul>
+ As per the Warning earlier, <i>do not</i> use <tt>bless</tt>'s
+ <tt>--info</tt> option to try to confirm the change to the boot status
+ unless you're certain you do <i>not</i> have an Advanced Format hard
+ disk.</li>
</ol>
protective MBR. You can obtain the file from the <a
href="http://refit.sourceforge.net">original rEFIt package.</a></li>
+<li><b>Drivers</b>—You can install drivers to extend the capabilities
+ of the EFI. Most notably, filesystem drivers for ext2fs and ReiserFS
+ are available. These can enable you to boot a Linux kernel with EFI
+ stub support from an ext2fs, ext3fs, or ReiserFS partition. See the <a
+ href="drivers.html">Using EFI Drivers</a> page for more on this
+ topic.</li>
+
</ul>
<p>I've seen links to other versions of these tools from time to time on the Web, so if you try one of these programs and it crashes or behaves strangely, try performing a Web search; you may turn up something that works better for you than the one to which I've linked.</p>
<ol>
-<li>rEFInd looks for boot loaders whose names include the strings <tt>bzImage</tt> or <tt>vmlinuz</tt> and that end in <tt>.efi</tt>. For instance, <tt>bzImage-3.3.0.efi</tt> or <tt>vmlinuz-3.3.0-fc17.efi</tt> would match, and trigger subsequent steps in this procedure. Note that to use this system, you <i>must</i> give your kernel file a <tt>.efi</tt> extension, at least on the ESP (or other boot loader partition)!</li>
+<li>rEFInd looks for boot loaders whose names include the strings
+ <tt>bzImage</tt> or <tt>vmlinuz</tt> and that end in <tt>.efi</tt>. For
+ instance, <tt>bzImage-3.3.0.efi</tt> or <tt>vmlinuz-3.3.0-fc17.efi</tt>
+ would match, and trigger subsequent steps in this procedure. Beginning
+ with version 0.3.0, if you uncomment the
+ <tt>scan_all_linux_kernels</tt> option in <tt>refind.conf</tt>, rEFInd
+ will also scan for kernels <i>without</i> a <tt>.efi</tt> filename
+ extension. This option is not the default, though, because it can pick
+ up old kernels that lack EFI stub loader support and even non-kernel
+ files, such as icon files named to give a kernel a unique icon.</li>
<p class="sidebar">A kernel whose filename lacks a version string matches an initial RAM disk that also lacks a version string in its filename. Note that you can reliably use only <i>one</i> kernel and initial RAM disk per directory that lack version numbers in their filenames.</p>
-<li>rEFInd looks for an initial RAM disk in the same directory as the kernel file. A matching initial RAM disk has a name that begins with <tt>init</tt> and that includes the same version string as the kernel. The version string is defined as the part of the filename from the first digit to the last digit, inclusive. Note that the version string can include non-digits. For instance, the version string for <tt>bzImage-3.3.0.efi</tt> is <tt>3.3.0</tt>, which matches <tt>initramfs-3.3.0.bz</tt>; and <tt>vmlinuz-3.3.0-fc17.efi</tt>'s version string is <tt>3.3.0-fc17</tt>, which matches <tt>initrd-3.3.0-fc17.img</tt>. Many other matches are possible. If an initial RAM disk is identified, rEFInd passes a suitable <tt>initrd=</tt> option to the kernel when it boots.</li>
+<li>rEFInd looks for an initial RAM disk in the same directory as the
+ kernel file. A matching initial RAM disk has a name that begins with
+ <tt>init</tt> and that includes the same version string as the kernel.
+ The version string is defined as the part of the filename from the
+ first digit to the last digit, inclusive. Note that the version string
+ can include non-digits. For instance, the version string for
+ <tt>bzImage-3.3.0.efi</tt> is <tt>3.3.0</tt>, which matches
+ <tt>initramfs-3.3.0.bz</tt>; and <tt>vmlinuz-3.3.0-fc17.efi</tt>'s
+ version string is <tt>3.3.0-fc17</tt>, which matches
+ <tt>initrd-3.3.0-fc17.img</tt>. Many other matches are possible. If an
+ initial RAM disk is identified, rEFInd passes a suitable
+ <tt>initrd=</tt> option to the kernel when it boots.</li>
<p class="sidebar">rEFInd 0.2.1 and 0.2.2 used a filename of <tt>linux.conf</tt> to hold Linux kernel options; however, the Linux kernel developers plan to use this name themselves, so I've switched to <tt>refind_linux.conf</tt> as of rEFInd 0.2.3. For the moment, rEFInd still supports the <tt>linux.conf</tt> filename as a backup to <tt>refind_linux.conf</tt>, but <tt>linux.conf</tt> is now officially deprecated as a rEFInd configuration file, so you should rename your <tt>linux.conf</tt> file to <tt>refind_linux.conf</tt> if you're upgrading.</p>
-<li>rEFInd looks for a file called <tt>refind_linux.conf</tt> in the same directory as the kernel file. This file is a practical requirement for booting from an auto-detected kernel. It consists of a series of lines, each of which consists of a label followed by a series of kernel options. The first line sets default options, and subsequent lines set options that are accessible from the main menu tag's submenu screen.</li>
+<li>rEFInd looks for a file called <tt>refind_linux.conf</tt> in the same
+ directory as the kernel file. This file is a practical requirement for
+ booting from an auto-detected kernel. It consists of a series of lines,
+ each of which consists of a label followed by a series of kernel
+ options. The first line sets default options, and subsequent lines set
+ options that are accessible from the main menu tag's submenu
+ screen.</li>
</ol>
<p>The intent of this system is that distribution maintainers can place their kernels, initial RAM disks, and a <tt>refind_linux.conf</tt> file in their own subdirectory on the ESP. rEFInd will detect their kernels and create one main menu entry for each kernel. Each entry will implement as many options as there are lines in the <tt>refind_linux.conf</tt> file. In this way, two or more distributions can each maintain their boot loader entries, without being too concerned about who maintains rEFInd as a whole.</p>
+<p>The <tt>scan_all_linux_kernels</tt> option is intended to help users and distribution maintainers when rEFInd is used in conjunction with a Linux filesystem driver for EFI or when the ESP is mounted as the Linux <tt>/boot</tt> partition. In these cases, if all the kernels in Linux's <tt>/boot</tt> directory include EFI stub loader support, rEFInd will automatically detect and use kernels installed in the usual way, such as via an automatic system update. You won't even need to move or rename your kernels. You will need to set up a <tt>refind_linux.conf</tt> file and you may need to install a driver or set the <tt>also_scan_dirs</tt> option in <tt>refind.conf</tt>; but these are one-time requirements. Set up in this way, ongoing maintenance to handle kernel updates drops to zero!</p>
+
<p>As an example, consider the following file configuration:</p>
<pre class="listing">
<li>Your kernels must be compiled with EFI stub loader support.</li>
-<li>You can't set a submenu option to boot via a different boot loader, such as ELILO or GRUB; all the submenu options apply to a single boot loader—that is, a single kernel. (rEFInd will still detect other boot loaders and provide separate main-menu tags for them, though.)</li>
+<li>You can't set a submenu option to boot via a different boot loader,
+ such as ELILO or GRUB; all the submenu options apply to a single boot
+ loader—that is, a single kernel. (rEFInd will still detect other
+ boot loaders and provide separate main-menu tags for them,
+ though.)</li>
-<li>If an installation includes two or more kernel files, each one receives its own main-menu entry; you can't combine them together in one menu item. This is essentially a corollary of the preceding limitation. The result can be an overburdened main menu if your system has many kernels.</li>
+<li>If an installation includes two or more kernel files, each one receives
+ its own main-menu entry; you can't combine them together in one menu
+ item. This is essentially a corollary of the preceding limitation. The
+ result can be an overburdened main menu if your system has many
+ kernels.</li>
-<li>All the kernels in a given directory use the same <tt>refind_linux.conf</tt> file. If you need to set different options for different kernels, you'll need to place those kernels in different directories.</li>
+<li>All the kernels in a given directory use the same
+ <tt>refind_linux.conf</tt> file. If you need to set different options
+ for different kernels, you'll need to place those kernels in different
+ directories.</li>
-<li>You must place your kernels in a directory other than the one that holds the main rEFInd <tt>.efi</tt> file. This is because rEFInd does not scan its own directory for boot loaders.</li>
+<li>You must place your kernels in a directory other than the one that
+ holds the main rEFInd <tt>.efi</tt> file. This is because rEFInd does
+ not scan its own directory for boot loaders.</li>
</ul>
<p>Ordinarily, a kernel booted in this way must reside on the ESP, or at least on another FAT partition. On a Macintosh, though, you can use HFS+ to house your kernel files. In fact, that may be necessary; my Mac Mini hangs when I try to boot a Linux kernel via an EFI stub loader from the computer's ESP, but it works fine when booting from an HFS+ partition. If you use <a href="drivers.html">EFI drivers,</a> though, you can place your kernel on any filesystem for which an EFI driver exists. This list is currently rather limited (ext2fs/ext3fs, ReiserFS, ISO-9660, and HFS+), but even just one or two options might help a lot if you've got an undersized ESP or if copying your kernel file to the ESP is a hassle you'd rather avoid.</p>
+<p>Beginning with version 0.3.1, rEFInd sorts boot loader entries <i>within each directory</i> by time stamp, so that the most recent entry comes first. Thus, if you specify a directory name (or a volume label, for loaders stored in a volume's root directory) as the <tt>default_selection</tt>, rEFInd will make the most recent loader in the directory the default. This can obviate the need to adjust this configuration parameter when you add a new kernel; chances are you want the most recently-added kernel to be the default, and rEFInd makes it so when you set the <tt>default_selection</tt> in this way. If you <i>don't</i> want the latest kernel to become the default, you can use <tt>touch</tt> to give the desired kernel (or other boot loader) in the directory a more recent time stamp, or you can set <tt>default_selection</tt> to a value that uniquely identifies your desired default loader.</p>
+
<p class="sidebar"><b>Tip for distribution maintainers:</b> If you maintain an <tt>EFI/<tt class="variable">distname</tt></tt> directory for your kernels, you can place your version of rEFInd in a directory called <tt>EFI/<tt class="variable">distname</tt>/refind</tt>. This will avoid collisions with duplicate rEFInd installations from other distributions.</p>
<p>On the whole, this method of configuration has a lot going for it. For distribution maintainers, if you place your Linux kernel files (with EFI stub support) on the ESP, with suitable filenames, matching initial RAM disk files, and a <tt>refind_linux.conf</tt> file, then any rEFInd 0.2.3 or later installation should detect your files, even if the user installs another distribution with another rEFInd that takes over from yours. (If the user, or this other rEFInd installation, disables auto-detection, this won't work.)</p>
<ul>
-<li>Testing! rEFIt was complex enough that changes such as the ones I've made have the potential to disrupt the program's operation in unexpected ways. Since the initial 0.2.0 release, I've continued to add features to rEFInd, and every new feature is another way for bugs to get into the program. I can only test on a handful of systems with a limited number of configurations. Therefore, if you try rEFInd and run into bugs, please report them to me!</li>
-
-<li>Currently, rEFInd can detect whether it's compiled for <i>x</i>86 or <i>x</i>86-64 systems and displays this information in its "About" screen (AboutrEFInd() in main.c). I'd like to add detection for Itanium and ARM systems, but I have no way to test such changes.</li>
-
-<li>I have little talent with graphics manipulation programs, so rEFInd's boot logo, such as it is, is pretty weak. If you have artistic talent and would like to create a rEFInd logo, please feel free to send it to me. I won't make any final decision about changes until at least June 30 of 2012.</li>
+<li>Testing! rEFIt was complex enough that changes such as the ones I've
+ made have the potential to disrupt the program's operation in
+ unexpected ways. Since the initial 0.2.0 release, I've continued to add
+ features to rEFInd, and every new feature is another way for bugs to
+ get into the program. I can only test on a handful of systems with a
+ limited number of configurations. Therefore, if you try rEFInd and run
+ into bugs, please report them to me!</li>
+
+<li>Currently, rEFInd can detect whether it's compiled for <i>x</i>86 or
+ <i>x</i>86-64 systems and displays this information in its "About"
+ screen (AboutrEFInd() in main.c). I'd like to add detection for Itanium
+ and ARM systems, but I have no way to test such changes.</li>
+
+<li>I have little talent with graphics manipulation programs, so rEFInd's
+ boot logo, such as it is, is pretty weak. If you have artistic talent
+ and would like to create a rEFInd logo, please feel free to send it to
+ me. I won't make any final decision about changes until at least June
+ 30 of 2012.</li>
<li>rEFIt's original design, and hence rEFInd's design, enables easy
-theming by replacing icon files. If you'd like to design a new theme for
-rEFInd, feel free to submit it. I might or might not replace the icons it
-uses now (most of which come from the Oxygen Icons package), but I may
-provide a way to make selecting a theme from one of several installed
-themes easy, and provide links to themes on this Web site (or even host
-them on the project's Sourceforge page). For more information on designing themes for rEFInd, see the <a href="themes.html">Theming rEFInd</a> page.</li>
-
-<li>The code could be more flexible in its handling of the sizes of various graphical elements, and particularly drawn text. Prior to version 0.2.2, submenu text was invisible on UEFI-based PCs with 800x600 and smaller displays because of an inability to properly crop the graphics fields that hold the text. With version 0.2.2, I've put a band-aid on this problem by reducing the field size so that it now works on 800x600 displays, but smaller displays still suffer from this problem. This is just an example of the inflexibility of certain layout issues within rEFInd.</li>
-
-<li>Text mode has a known display glitch: Not all loaders are shown until you use the cursor keys to move down the list, effectively "drawing" the "invisible" tags. This obviously needs to be fixed.</li>
-
-<li>Although the ICNS file format used by rEFInd supports multiple image sizes, if a size that rEFInd needs isn't present in the file, rEFInd can't use the icon. The ability to scale images to the desired size would be useful.</li>
-
-<li>EFI supports network boots. rEFInd doesn't, but it would be nice if it would.</li>
-
-<li>I would like to be able to specify the volume on which a boot loader resides using a partition GUID value, but extracting a GUID from the partition data is harder than extracting the volume's label or counting up the filesystem numbers.</li>
-
-<li>It would be useful to be able to specify paths to boot loaders and/or initial RAM disks relative to the rEFInd directory (or the boot loader's directory, in the case of initrds).</li>
-
-<li>There's currently no way to create a manual boot stanza for a BIOS-booted OS. This isn't a big priority for me personally, but I can see how it could be for some people.</li>
-
-<li>I'd like to find a way to get rEFInd to launch BIOS boot loaders on UEFI-based systems. This option currently works only on Macs—or at least, I've not gotten it to work on any of my UEFI-based PCs. (I have an idea about this, but haven't yet investigated it in detail. If you'd like to help on this, <a href="mailto:rodsmith@rodsbooks.com">e-mail me</a> for my thoughts.)</li>
-
-<li>The <a href="http://www.rodsbooks.com/gb-hybrid-efi/">Gigabyte Hybrid EFI</a> has a bug that causes the allegedly case-insensitive <tt>StriCmp()</tt> function to perform a case-sensitive comparison. This causes any number of bugs in file matching. For instance: Changing the case of icon filename extensions (or various other parts of icon filenames) causes icons to be replaced by ugly "generic" ones; and rEFInd sometimes appears in its own menu (the firmware sometimes returns an all-caps version of the filename, but other times returns the filename with the correct case, causing a mismatch if the path includes lowercase elements). Some of these problems can be overcome by converting both strings to be compared to one case before doing the comparison, but others aren't so easy, since I think <tt>StriCmp()</tt> is being called internally to the EFI. In any event, it'd be nice to fix some of these problems. OTOH, this is a workaround for a bug on just one EFI implementation, and a dismal one at that, so I'm inclined to just let it go.</li>
-
-<li>I've received queries about rEFInd's ability to work with Apple's whole-disk encryption scheme that's new with OS X 10.7. Unfortunately, I lack the hardware to test this.</li>
-
-<li>The Page Up and Page Down keys work in a rather strange way—a result of an admittedly quick fix on my part to a problem with a data structure that makes implementation of scrolling harder than it ought to be.</li>
-
-<li>I'd like to find a way to enable users to enter customizations for boot options and then save them to the <tt>refind.conf</tt> file.</li>
-
-<li>Auto-detected boot loaders are currently displayed in an arbitrary order, aside from the crude internal/external/optical distinctions, which can be affected by the order of options in <tt>scanfor</tt>. I'd like to sort entries by file timestamp within each directory, with the newest entry first. This will be beneficial because using the directory name as the entry in <tt>default_selection</tt> will then return the most recent boot loader in that directory, which is most likely the desired result when you upgrade a Linux kernel with an EFI stub loader. (As it is, to guarantee use of the most recent kernel, you must update <tt>refind.conf</tt>.) There might also be other ways to sort entries to some beneficial end, but I haven't thought of any.</li>
-
-<li>It should be possible to override specific auto-detected boot loader settings—say, to disable one specific boot loader or change its icon.</li>
-
-<li>A way to read boot options set via <tt>efibootmgr</tt>, <tt>bless</tt>, or similar options from NVRAM to add to the boot set would be useful.</li>
-
-<li>A way to examine and change the NVRAM settings could be useful. This would enable a CD-based boot of rEFInd to fix a broken disk boot. Perhaps this could be done via a separate tool that could be launched much like the shell or <tt>gptsync</tt>.</li>
-
-<li>I'd like to find a way to have rEFInd re-scan removable media when they're inserted.</li>
-
-<li>The code is in need of review to search for memory leaks and similar problems.</p>
+ theming by replacing icon files. If you'd like to design a new theme
+ for rEFInd, feel free to submit it. I might or might not replace the
+ icons it uses now (most of which come from the Oxygen Icons package),
+ but I may provide a way to make selecting a theme from one of several
+ installed themes easy, and provide links to themes on this Web site (or
+ even host them on the project's Sourceforge page). For more information
+ on designing themes for rEFInd, see the <a href="themes.html">Theming
+ rEFInd</a> page.</li>
+
+<li>The code could be more flexible in its handling of the sizes of various
+ graphical elements, and particularly drawn text. Prior to version
+ 0.2.2, submenu text was invisible on UEFI-based PCs with 800x600 and
+ smaller displays because of an inability to properly crop the graphics
+ fields that hold the text. With version 0.2.2, I've put a band-aid on
+ this problem by reducing the field size so that it now works on 800x600
+ displays, but smaller displays still suffer from this problem. This is
+ just an example of the inflexibility of certain layout issues within
+ rEFInd.</li>
+
+<li>Text mode has a known display glitch: Not all loaders are shown until
+ you use the cursor keys to move down the list, effectively "drawing"
+ the "invisible" tags. This obviously needs to be fixed.</li>
+
+<li>Although the ICNS file format used by rEFInd supports multiple image
+ sizes, if a size that rEFInd needs isn't present in the file, rEFInd
+ can't use the icon. The ability to scale images to the desired size
+ would be useful.</li>
+
+<li>EFI supports network boots. rEFInd doesn't, but it would be nice if it
+ would.</li>
+
+<li>I would like to be able to specify the volume on which a boot loader
+ resides using a partition GUID value, but extracting a GUID from the
+ partition data is harder than extracting the volume's label or counting
+ up the filesystem numbers.</li>
+
+<li>It would be useful to be able to specify paths to boot loaders and/or
+ initial RAM disks relative to the rEFInd directory (or the boot
+ loader's directory, in the case of initrds).</li>
+
+<li>There's currently no way to create a manual boot stanza for a
+ BIOS-booted OS. This isn't a big priority for me personally, but I can
+ see how it could be for some people.</li>
+
+<li>I'd like to find a way to get rEFInd to launch BIOS boot loaders on
+ UEFI-based systems. This option currently works only on Macs—or
+ at least, I've not gotten it to work on any of my UEFI-based PCs. (I
+ have an idea about this, but haven't yet investigated it in detail. If
+ you'd like to help on this, <a
+ href="mailto:rodsmith@rodsbooks.com">e-mail me</a> for my
+ thoughts.)</li>
+
+<li>The <a href="http://www.rodsbooks.com/gb-hybrid-efi/">Gigabyte Hybrid
+ EFI</a> has a bug that causes the allegedly case-insensitive
+ <tt>StriCmp()</tt> function to perform a case-sensitive comparison.
+ This causes any number of bugs in file matching. For instance: Changing
+ the case of icon filename extensions (or various other parts of icon
+ filenames) causes icons to be replaced by ugly "generic" ones; and
+ rEFInd sometimes appears in its own menu (the firmware sometimes
+ returns an all-caps version of the filename, but other times returns
+ the filename with the correct case, causing a mismatch if the path
+ includes lowercase elements). Some of these problems can be overcome by
+ converting both strings to be compared to one case before doing the
+ comparison, but others aren't so easy, since I think <tt>StriCmp()</tt>
+ is being called internally to the EFI. In any event, it'd be nice to
+ fix some of these problems. OTOH, this is a workaround for a bug on
+ just one EFI implementation, and a dismal one at that, so I'm inclined
+ to just let it go.</li>
+
+<li>I've received queries about rEFInd's ability to work with Apple's
+ whole-disk encryption scheme that's new with OS X 10.7. Unfortunately,
+ I lack the hardware to test this.</li>
+
+<li>The Page Up and Page Down keys work in a rather strange way—a
+ result of an admittedly quick fix on my part to a problem with a data
+ structure that makes implementation of scrolling harder than it ought
+ to be.</li>
+
+<li>The Shutdown option works correctly on Macs, but not on UEFI-based PCs.
+ On such systems, Shutdown reboots the computer. This should be
+ fixed.</li>
+
+<li>I'd like to find a way to enable users to enter customizations for boot
+ options and then save them to the <tt>refind.conf</tt> file.</li>
+
+<li>It should be possible to override specific auto-detected boot loader
+ settings—say, to disable one specific boot loader or change its
+ icon.</li>
+
+<li>A way to read boot options set via <tt>efibootmgr</tt>, <tt>bless</tt>,
+ or similar options from NVRAM to add to the boot set would be
+ useful.</li>
+
+<li>A way to examine and change the NVRAM settings could be useful. This
+ would enable a CD-based boot of rEFInd to fix a broken disk boot.
+ Perhaps this could be done via a separate tool that could be launched
+ much like the shell or <tt>gptsync</tt>.</li>
+
+<li>I'd like to find a way to have rEFInd re-scan removable media when
+ they're inserted.</li>
+
+<li>I'd like to give the user the ability to set custom options on a
+ per-boot basis, similar to what's possible in GRUB.</li>
+
+<li>The code is in need of review to search for memory leaks and similar
+ problems.</p>
</ul>
return FileName;
}
-VOID ReplaceExtension(IN OUT CHAR16 *Path, IN CHAR16 *Extension)
+// Replaces a filename extension of ".efi" with the specified string
+// (Extension). If the input Path doesn't end in ".efi", Extension
+// is added to the existing filename.
+VOID ReplaceEfiExtension(IN OUT CHAR16 *Path, IN CHAR16 *Extension)
{
- UINTN i;
+ UINTN PathLen;
- for (i = StrLen(Path); i >= 0; i--) {
- if (Path[i] == '.') {
- Path[i] = 0;
- break;
- }
- if (Path[i] == '\\' || Path[i] == '/')
- break;
- }
+ PathLen = StrLen(Path);
+ // Note: Do StriCmp() twice to work around Gigabyte Hybrid EFI case-sensitivity bug....
+ if ((PathLen >= 4) && ((StriCmp(&Path[PathLen - 4], L".efi") == 0) || (StriCmp(&Path[PathLen - 4], L".EFI") == 0))) {
+ Path[PathLen - 4] = 0;
+ } // if
StrCat(Path, Extension);
-}
+} // VOID ReplaceEfiExtension()
//
// memory string search
} // if/else
} // static CHAR16* MergeStrings()
+// Takes an input pathname (*Path) and returns the part of the filename from
+// the final dot onwards, converted to lowercase. If the filename includes
+// no dots, or if the input is NULL, returns an empty (but allocated) string.
+// The calling function is responsible for freeing the memory associated with
+// the return value.
+CHAR16 *FindExtension(IN CHAR16 *Path) {
+ CHAR16 *Extension;
+ BOOLEAN Found = FALSE, FoundSlash = FALSE;
+ UINTN i;
+
+ Extension = AllocateZeroPool(sizeof(CHAR16));
+ if (Path) {
+ i = StrLen(Path);
+ while ((!Found) && (!FoundSlash) && (i >= 0)) {
+ if (Path[i] == L'.')
+ Found = TRUE;
+ else if ((Path[i] == L'/') || (Path[i] == L'\\'))
+ FoundSlash = TRUE;
+ if (!Found)
+ i--;
+ } // while
+ if (Found) {
+ MergeStrings(&Extension, &Path[i], 0);
+ StrLwr(Extension);
+ } // if (Found)
+ } // if
+ return (Extension);
+} // CHAR16 *FindExtension
+
// Takes an input pathname (*Path) and locates the final directory component
// of that name. For instance, if the input path is 'EFI\foo\bar.efi', this
// function returns the string 'foo'.
EFI_STATUS DirIterClose(IN OUT REFIT_DIR_ITER *DirIter);
CHAR16 * Basename(IN CHAR16 *Path);
-VOID ReplaceExtension(IN OUT CHAR16 *Path, IN CHAR16 *Extension);
+VOID ReplaceEfiExtension(IN OUT CHAR16 *Path, IN CHAR16 *Extension);
INTN FindMem(IN VOID *Buffer, IN UINTN BufferLength, IN VOID *SearchString, IN UINTN SearchStringLength);
VOID ReinitVolumes(VOID);
BOOLEAN StriSubCmp(IN CHAR16 *TargetStr, IN CHAR16 *BigStr);
VOID MergeStrings(IN OUT CHAR16 **First, IN CHAR16 *Second, CHAR16 AddChar);
+CHAR16 *FindExtension(IN CHAR16 *Path);
CHAR16 *FindLastDirName(IN CHAR16 *Path);
CHAR16 *FindPath(IN CHAR16* FullPath);
CHAR16 *FindNumbers(IN CHAR16 *InString);
REFIT_CONFIG GlobalConfig = { FALSE, FALSE, 0, 0, 20, 0, 0, NULL, NULL, NULL, NULL, NULL, NULL,
{TAG_SHELL, TAG_ABOUT, TAG_SHUTDOWN, TAG_REBOOT, 0, 0, 0, 0, 0 }};
+// Structure used to hold boot loader filenames and time stamps in
+// a linked list; used to sort entries within a directory.
+struct LOADER_LIST {
+ CHAR16 *FileName;
+ EFI_TIME TimeStamp;
+ struct LOADER_LIST *NextEntry;
+};
+
//
// misc functions
//
{
if (AboutMenu.EntryCount == 0) {
AboutMenu.TitleImage = BuiltinIcon(BUILTIN_ICON_FUNC_ABOUT);
- AddMenuInfoLine(&AboutMenu, L"rEFInd Version 0.3.0");
+ AddMenuInfoLine(&AboutMenu, L"rEFInd Version 0.3.0.2");
AddMenuInfoLine(&AboutMenu, L"");
AddMenuInfoLine(&AboutMenu, L"Copyright (c) 2006-2010 Christoph Pfisterer");
AddMenuInfoLine(&AboutMenu, L"Copyright (c) 2012 Roderick W. Smith");
// locate a custom icon for the loader
StrCpy(IconFileName, LoaderPath);
- ReplaceExtension(IconFileName, L".icns");
+ ReplaceEfiExtension(IconFileName, L".icns");
if (FileExists(Volume->RootDir, IconFileName)) {
Entry->me.Image = LoadIcns(Volume->RootDir, IconFileName, 128);
} else if ((StrLen(PathOnly) == 0) && (Volume->VolIconImage != NULL)) {
CleanUpPathNameSlashes(LoaderPath);
Entry = InitializeLoaderEntry(NULL);
if (Entry != NULL) {
- Entry->Title = StrDuplicate(LoaderTitle);
+ Entry->Title = StrDuplicate((LoaderTitle != NULL) ? LoaderTitle : LoaderPath);
+// Entry->Title = StrDuplicate(LoaderTitle);
Entry->me.Title = PoolPrint(L"Boot %s from %s", (LoaderTitle != NULL) ? LoaderTitle : LoaderPath, Volume->VolName);
Entry->me.Row = 0;
Entry->me.BadgeImage = Volume->VolBadgeImage;
return(Entry);
} // LOADER_ENTRY * AddLoaderEntry()
+// Returns -1 if (Time1 < Time2), +1 if (Time1 > Time2), or 0 if
+// (Time1 == Time2). Precision is only to the nearest second; since
+// this is used for sorting boot loader entries, differences smaller
+// than this are likely to be meaningless (and unlikely!).
+INTN TimeComp(EFI_TIME *Time1, EFI_TIME *Time2) {
+ INT64 Time1InSeconds, Time2InSeconds;
+
+ // Following values are overestimates; I'm assuming 31 days in every month.
+ // This is fine for the purpose of this function, which has a limited
+ // purpose.
+ Time1InSeconds = Time1->Second + (Time1->Minute * 60) + (Time1->Hour * 3600) + (Time1->Day * 86400) +
+ (Time1->Month * 2678400) + ((Time1->Year - 1998) * 32140800);
+ Time2InSeconds = Time2->Second + (Time2->Minute * 60) + (Time2->Hour * 3600) + (Time2->Day * 86400) +
+ (Time2->Month * 2678400) + ((Time2->Year - 1998) * 32140800);
+ if (Time1InSeconds < Time2InSeconds)
+ return (-1);
+ else if (Time1InSeconds > Time2InSeconds)
+ return (1);
+
+ return 0;
+} // INTN TimeComp()
+
+// Adds a loader list element, keeping it sorted by date. Returns the new
+// first element (the one with the most recent date).
+static struct LOADER_LIST * AddLoaderListEntry(struct LOADER_LIST *LoaderList, struct LOADER_LIST *NewEntry) {
+ struct LOADER_LIST *LatestEntry, *CurrentEntry, *PrevEntry = NULL;
+
+ LatestEntry = CurrentEntry = LoaderList;
+ if (LoaderList == NULL) {
+ LatestEntry = NewEntry;
+ } else {
+ while ((CurrentEntry != NULL) && (TimeComp(&(NewEntry->TimeStamp), &(CurrentEntry->TimeStamp)) < 0)) {
+ PrevEntry = CurrentEntry;
+ CurrentEntry = CurrentEntry->NextEntry;
+ } // while
+ NewEntry->NextEntry = CurrentEntry;
+ if (PrevEntry == NULL) {
+ LatestEntry = NewEntry;
+ } else {
+ PrevEntry->NextEntry = NewEntry;
+ } // if/else
+ } // if/else
+ return (LatestEntry);
+} // static VOID AddLoaderListEntry()
+
+// Delete the LOADER_LIST linked list
+static VOID CleanUpLoaderList(struct LOADER_LIST *LoaderList) {
+ struct LOADER_LIST *Temp;
+
+ while (LoaderList != NULL) {
+ Temp = LoaderList;
+ LoaderList = LoaderList->NextEntry;
+ FreePool(Temp->FileName);
+ FreePool(Temp);
+ } // while
+} // static VOID CleanUpLoaderList()
+
// Scan an individual directory for EFI boot loader files and, if found,
-// add them to the list.
+// add them to the list. Sorts the entries within the loader directory
+// so that the most recent one appears first in the list.
static VOID ScanLoaderDir(IN REFIT_VOLUME *Volume, IN CHAR16 *Path, IN CHAR16 *Pattern)
{
EFI_STATUS Status;
REFIT_DIR_ITER DirIter;
EFI_FILE_INFO *DirEntry;
- CHAR16 FileName[256];
+ CHAR16 FileName[256], *Extension;
+ struct LOADER_LIST *LoaderList = NULL, *NewLoader;
if (!SelfDirPath || !Path || ((StriCmp(Path, SelfDirPath) == 0) && Volume != SelfVolume) ||
(StriCmp(Path, SelfDirPath) != 0)) {
// look through contents of the directory
DirIterOpen(Volume->RootDir, Path, &DirIter);
while (DirIterNext(&DirIter, 2, Pattern, &DirEntry)) {
+ Extension = FindExtension(DirEntry->FileName);
if (DirEntry->FileName[0] == '.' ||
StriCmp(DirEntry->FileName, L"TextMode.efi") == 0 ||
StriCmp(DirEntry->FileName, L"ebounce.efi") == 0 ||
StriCmp(DirEntry->FileName, L"GraphicsConsole.efi") == 0 ||
+ StriCmp(Extension, L".icns") == 0 ||
StriSubCmp(L"shell", DirEntry->FileName))
continue; // skip this
SPrint(FileName, 255, L"\\%s\\%s", Path, DirEntry->FileName);
else
SPrint(FileName, 255, L"\\%s", DirEntry->FileName);
- AddLoaderEntry(FileName, NULL, Volume);
- }
+ NewLoader = AllocateZeroPool(sizeof(struct LOADER_LIST));
+ if (NewLoader != NULL) {
+ NewLoader->FileName = StrDuplicate(FileName);
+ NewLoader->TimeStamp = DirEntry->ModificationTime;
+ LoaderList = AddLoaderListEntry(LoaderList, NewLoader);
+ } // if
+ FreePool(Extension);
+ } // while
+ NewLoader = LoaderList;
+ while (NewLoader != NULL) {
+ AddLoaderEntry(NewLoader->FileName, NULL, Volume);
+ NewLoader = NewLoader->NextEntry;
+ } // while
+ CleanUpLoaderList(LoaderList);
Status = DirIterClose(&DirIter);
if (Status != EFI_NOT_FOUND) {
if (Path)
// Scan user-specified (or additional default) directories....
i = 0;
while ((Directory = FindCommaDelimited(GlobalConfig.AlsoScan, i++)) != NULL) {
+ CleanUpPathNameSlashes(Directory);
Length = StrLen(Directory);
- // Some EFI implementations won't read a directory if the path ends in
- // a backslash, so eliminate this character, if it's present....
- while ((Length > 0) && (Directory[Length - 1] == L'\\')) {
- Directory[--Length] = 0;
- } // while
if (Length > 0)
ScanLoaderDir(Volume, Directory, MatchPatterns);
FreePool(Directory);
EFI_FILE_INFO *DirEntry;
CHAR16 FileName[256];
+ CleanUpPathNameSlashes(Path);
// look through contents of the directory
DirIterOpen(SelfRootDir, Path, &DirIter);
while (DirIterNext(&DirIter, 2, LOADER_MATCH_PATTERNS, &DirEntry)) {
return Status;
} /* EFI_STATUS ConnectAllDriversToAllControllers() */
+// Load all EFI drivers from rEFInd's "drivers" subdirectory and from the
+// directories specified by the user in the "scan_driver_dirs" configuration
+// file line.
static VOID LoadDrivers(VOID)
{
CHAR16 *Directory;
// load drivers from the "drivers" subdirectory of rEFInd's home directory
Directory = StrDuplicate(SelfDirPath);
+ CleanUpPathNameSlashes(Directory);
MergeStrings(&Directory, L"drivers", L'\\');
NumFound += ScanDriverDir(Directory);
// Scan additional user-specified driver directories....
while ((Directory = FindCommaDelimited(GlobalConfig.DriverDirs, i++)) != NULL) {
+ CleanUpPathNameSlashes(Directory);
Length = StrLen(Directory);
- // Some EFI implementations won't read a directory if the path ends in
- // a backslash, so eliminate this character, if it's present....
- while ((Length > 0) && (Directory[Length - 1] == L'\\')) {
- Directory[--Length] = 0;
- } // while
if (Length > 0)
NumFound += ScanDriverDir(Directory);
FreePool(Directory);
// connect all devices
if (NumFound > 0)
ConnectAllDriversToAllControllers();
-}
+} /* static VOID LoadDrivers() */
static VOID ScanForBootloaders(VOID) {
UINTN i;
Shortcut[0] -= ('a' - 'A');
if (Shortcut[0]) {
for (i = 0; i < Screen->EntryCount; i++) {
- if (Screen->Entries[i]->ShortcutDigit == Shortcut[0] ||
- Screen->Entries[i]->ShortcutLetter == Shortcut[0]) {
+ if (Screen->Entries[i]->ShortcutDigit == Shortcut[0] || Screen->Entries[i]->ShortcutLetter == Shortcut[0]) {
return i;
} // if
} // for
UINTN RunMenu(IN REFIT_MENU_SCREEN *Screen, OUT REFIT_MENU_ENTRY **ChosenEntry)
{
MENU_STYLE_FUNC Style = TextMenuStyle;
-
+
if (AllowGraphicsMode)
Style = GraphicsMenuStyle;
-
+
return RunGenericMenu(Screen, Style, -1, ChosenEntry);
}
UINTN DefaultEntryIndex = -1;
if (DefaultSelection != NULL) {
- // Find a menu entry whose shortcut is the first character of DefaultSelection, or
- // whose
+ // Find a menu entry that includes *DefaultSelection as a substring
DefaultEntryIndex = FindMenuShortcutEntry(Screen, DefaultSelection);
// If that didn't work, should we scan more characters? For now, no.
}