+make AR_TARGET=mok -C $(MOK_DIR) -f Make.tiano
+make BUILDME=refind DLL_TARGET=refind -C $(LOADER_DIR) -f Make.tiano
+make -C $(GPTSYNC_DIR) -f Make.tiano
+ +make -C $(FS_DIR)
clean:
make -C $(LIBEG_DIR) clean
-0.7.0 (?/??/2013):
+0.7.0 (6/27/2013):
------------------
-- Added a cache to all the filesystem drivers except for ext2fs. This cache
- greatly improves performance in VirtualBox, and offers modest performance
- improvements on a few "real" computers. The ext2fs driver loads blocks in
- a strange non-linear fashion that causes the cache to degrade
- performance, so I've disabled the cache for ext2fs. (Ext4fs doesn't
- suffer from this problem.)
+- Added Btrfs signature to rEFInd, so that it can identify the filesystem
+ type for volumes that lack labels.
+
+- Changed some critical filesystem driver pointers from 32-bit to 64-bit.
+ This *SHOULD* enable use of over-2TiB filesystems (for those filesystems
+ that support such large volumes). This capability is largely untested,
+ though.
+
+- Added a cache to the filesystem driver core, and therefore to all the
+ filesystem drivers. This cache greatly improves performance in
+ VirtualBox, and offers modest performance improvements on a few "real"
+ computers. The most dramatic improvement is on ext2/3fs under VirtualBox:
+ Loading a kernel and initrd used to take ~200 seconds on my system, but
+ now takes ~3 seconds! On most "real" hardware, the improvement is much
+ less dramatic -- an improvement of a second or less, presumably because
+ of cacheing within the EFI or on the hard disk itself.
- Filter boot loaders based on a test of their validity; keeps out Linux
kernels without EFI stub loader code, loaders for the wrong architecture,
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>\r
\r
<p>Originally written: 3/14/2012; last Web page update:\r
-6/18/2013, referencing rEFInd 0.6.12</p>\r
+6/27/2013, referencing rEFInd 0.7.0</p>\r
\r
\r
<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>\r
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 3/14/2012; last Web page update:
-6/18/2013, referencing rEFInd 0.6.12</p>
+6/27/2013, referencing rEFInd 0.7.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>
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 4/19/2012; last Web page update:
-6/18/2013, referencing rEFInd 0.6.12</p>
+6/27/2013, referencing rEFInd 0.7.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>
<p>Note that most of these uses are theoretical, at least to me; I don't know of any specific examples of EFI drivers (available as separate files) for disk controller hardware, network cards, or video cards. Such drivers are often embedded in the firmware of the devices themselves, and should be loaded automatically by the EFI. Chances are good that a few such drivers are available, unknown to me, and more may become available in the future. If you happen to have a device and need support for it under EFI, searching for drivers is certainly worth doing.</p>
-<p>To the best of my knowledge, the best reason to want EFI driver support in rEFInd is to provide access to filesystems. Although EFI filesystem driver choices are currently limited, those that are available can help to improve your installation and configuration options, particularly if you've found yourself "boxed in" by awkward installation or bugs, such as the dinky ESP that Ubuntu creates by default or the bug that prevents a Linux kernel with <a href="http://www.rodsbooks.com/efi-bootloaders/efistub.html">EFI stub loader support</a> from booting from the ESP of at least some Macs.</p>
+<p>To the best of my knowledge, the best reason to want EFI driver support in rEFInd is to provide access to filesystems. Although EFI filesystem driver choices are currently
somewhat limited, those that are available can help to improve your installation and configuration options, particularly if you've found yourself "boxed in" by awkward installation or bugs, such as the dinky ESP that Ubuntu creates by default or the bug that prevents a Linux kernel with <a href="http://www.rodsbooks.com/efi-bootloaders/efistub.html">EFI stub loader support</a> from booting from the ESP of at least some Macs.</p>
<p>As a side note, using an ISO-9660 driver can theoretically help you keep the size of a custom Linux boot CD/DVD down to a reasonable value. This is because EFI systems normally boot from optical discs by reading a FAT image file in El Torito format and treating that file as an ESP. If you need to store the kernel both in that file and directly in the ISO-9660 filesystem (to maintain bootability on BIOS systems), that can represent an unwanted extra space requirement. Placing rEFInd and an ISO-9660 driver in the FAT image file should enable you to store the kernel on the disc only once. Unfortunately, this doesn't work in practice. When the ISO-9660 driver is loaded from the El Torito image, the driver discovers that the optical disc is in use and refuses to access it. It's possible to use EFI shell commands to give the ISO-9660 driver access to the shell device, but this causes the El Torito access to go away, which means that anything loaded from the El Torito image (such as rEFInd) is likely to malfunction. Also, some EFI implementations include ISO-9660 drivers, so you might not need a separate ISO-9660 driver if you're building a disc for a particular computer.</p>
changing <tt class="userinput"><i>/dev/sda2</i></tt> to your
filesystem's device.</li>
+<li><b>Btrfs</b>—</b>Samuel Liao contributed this driver, which is
+ based on the rEFIt/rEFInd driver framework and algorithms from the GRUB
+ 2.0 Btrfs driver. As of rEFInd 0.7.0, this driver is new and should be
+ considered experimental. I've tested this driver with a simple
+ one-partition filesystem and with a filesystem that spans two physical
+ devices (although I've made no attempt to ensure that the driver can
+ actually read files written to both devices). Lamuel Liao has used the
+ driver with a compressed Btrfs volume. I don't know if the driver will
+ handle other advanced Btrfs features, such as snapshots and
+ subvolumes.</li>
+
<li><b>ISO-9660</b>—This driver originated with rEFIt's author, but
he never released a final version. Its code was improved by Oracle for
use in its VirtualBox product, and then further modified by the authors
</ul>
-<p>All of these drivers rely on filesystem wrapper code written by rEFIt's author, Christoph Phisterer. They all suffer from speed problems on some systems, as described later in <a href="#notes">"Notes on Specific Drivers;"</a> however, these problems are very minor on most systems.</p>
+<p>All of these drivers rely on filesystem wrapper code written by rEFIt's author, Christoph Phisterer.</p>
<p class="sidebar"><b>Note:</b> rEFInd's <tt>install.sh</tt> script does not install drivers by default on OS X, but on Linux, it installs the driver required to read the <tt>/boot</tt> directory, if one is available. The script installs all the available drivers if you pass it the <tt>--drivers</tt> option. See the <a href="installing.html">Installing rEFInd</a> page for details.</p>
<ul>
-<li><b><a href="http://refit.sourceforge.net">rEFIt's ext2fs and ReiserFS drivers</a></b>—You can gain read-only access to ext2fs, ext3fs, and ReiserFS volumes with these drivers, originally written by Christoph Pfisterer. You can use the binaries in the <tt>refit-bin-0.14/efi/tools/drivers</tt> directory of the binary package directly on a Mac. On a UEFI-based PC, though, you'll need to break the Mac-style "fat" binary into its 32- and 64-bit components. You can use my <a href="http://www.rodsbooks.com/thin/index.html"><tt>thin</tt></a> program for this job.</li>
+<li><b><a href="http://refit.sourceforge.net">rEFIt's ext2fs and ReiserFS drivers</a></b>—You can gain read-only access to ext2fs, ext3fs, and ReiserFS volumes with these drivers, originally written by Christoph Pfisterer. You can use the binaries in the <tt>refit-bin-0.14/efi/tools/drivers</tt> directory of the binary package directly on a Mac. On a UEFI-based PC, though, you'll need to break the Mac-style "fat" binary into its 32- and 64-bit components. You can use my <a href="http://www.rodsbooks.com/thin/index.html"><tt>thin</tt></a> program for this job. As a practical matter, there's no advantage to using these drivers over rEFInd's drivers, since the latter are updated versions of the former.</li>
-<li><b><a href="https://sourceforge.net/projects/cloverefiboot/">Clover EFI's ISO-9660, ext2fs, and HFS+ drivers</a></b>—This project is an offshoot of TianoCore, the main UEFI project. It's primarily a Hackintosh boot loader, but it includes drivers for <a href="http://cloverefiboot.svn.sourceforge.net/viewvc/cloverefiboot/VBoxFsDxe/">ISO-9660, ext2fs, and HFS+;</a> however, building them requires a fair amount of expertise. These drivers served as a starting point for rEFInd's drivers.</li>
+<li><b><a href="https://sourceforge.net/projects/cloverefiboot/">Clover EFI's ISO-9660, ext2fs, ext4fs, and HFS+ drivers</a></b>—This project is an offshoot of TianoCore, the main UEFI project. It's primarily a Hackintosh boot loader, but it includes drivers for <a href="http://cloverefiboot.svn.sourceforge.net/viewvc/cloverefiboot/VBoxFsDxe/">ISO-9660, ext2fs, ext4fs, and HFS+;</a> however, building them requires a fair amount of expertise. These drivers served as a starting point for rEFInd's drivers, except for the ext4fs driver, which the Clover developers based on rEFInd's ext4fs driver. Thus, as with the rEFIt drivers, there's likely to be no advantage to using the Clover drivers over the rEFInd drivers.</li>
-<li><b><a href="http://www.osx86.net/view/2571-clover_v2_r384__efi_bootloader_pkg_+_gpt_efi_tools.html">Clover's EFI Tools package</a></b>—This osx86.net thread includes links to a package called <tt>EFI_Tools_Clover_v2_r447_EFI_x32_x64_EN.zip</tt>, which holds an OS X application (a directory with a <tt>.app</tt> extension, as seen from other platforms) with a number of drivers in the <tt>Contents/Resources/EFI/drivers64</tt> directory (and an equivalent for 32-bit binaries). Some of these, such as keyboard drivers, are unlikely to be useful unless your system is badly broken as delivered. Three that caught my eye, however, are <tt>VBoxExt2-64.efi</tt>, <tt>NTFS-64.efi</tt>, and <tt>VBoxIso9600-64.efi</tt>.</li>
+<li><b><a href="http://www.osx86.net/view/2571-clover_v2_r384__efi_bootloader_pkg_+_gpt_efi_tools.html">Clover's EFI Tools package</a></b>—This osx86.net thread includes links to a package called <tt> EFI_Tools_Clover_v2_r1888_EN.zip</tt>, which holds an OS X application (a directory with a <tt>.app</tt> extension, as seen from other platforms) with a number of drivers in the <tt>Contents/Resources/EFI/drivers64</tt> directory (and an equivalent for 32-bit binaries). Some of these, such as keyboard drivers, are unlikely to be useful unless your system is badly broken as delivered. Three that caught my eye, however, are <tt>VBoxExt2-64.efi</tt>, <tt>VBoxIso9600-64.efi</tt>, and <tt>NTFS-64.efi</tt>. The first two of those are presumably variants on rEFInd's drivers, but the NTFS driver is not. I don't know this driver's provenance, so I'm reluctant to recommend its use, but it bears mentioning.</li>
-<li><b><a href="https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/EFI/Firmware2/VBoxPkg/VBoxFsDxe">VirtualBox's HFS+ and ISO-9660 drivers</a></b>—These drivers are available in source code form, and come with VirtualBox binaries. I've not attempted to compile them myself, but I've seen a report that suggests they may include assumptions that require use of <a href="http://www.mingw.org/">MinGW,</a> a GCC-based compiler for Windows (and cross-compiler to build Windows executables under Linux). I don't know of a source for binaries suitable for use on EFI-based computers; if you want to use them, you'll need to figure out how to compile them yourself.</li>
+<li><b><a href="https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/EFI/Firmware2/VBoxPkg/VBoxFsDxe">VirtualBox's HFS+ and ISO-9660 drivers</a></b>—These drivers are available in source code form, and come with VirtualBox binaries. I've not attempted to compile them myself, but I've seen a report that suggests they may include assumptions that require use of <a href="http://www.mingw.org/">MinGW,</a> a GCC-based compiler for Windows (and cross-compiler to build Windows executables under Linux). I don't know of a source for binaries suitable for use on EFI-based computers; if you want to use them, you'll need to figure out how to compile them yourself. As noted earlier, rEFInd's drivers are closely related to these.</li>
<li><b>Ext2Pkg</b>—This driver, based on <a href="https://bitbucket.org/alinrus/ext2pkg">bitbucket</a> and with a backup on <a href="https://github.com/the-ridikulus-rat/Tianocore_Ext2Pkg">github,</a> appears to be an ext2fs/ext3fs driver built independently of the driver written by Christoph Pfisterer. The linked-to sites provide access to source code via <tt>git</tt> but do not provide binaries. When I built binaries, they failed to work. Under VirtualBox, the driver loaded but then hung when I tried to access an ext2 filesystem. On a 32-bit Mac Mini, I got error messages when I tried to access an ext2 filesystem. As I write, the code was last updated in March of 2012. If you check the project and it's been updated more recently, it might be worth trying. Otherwise, I can't recommend this driver. I mention it here only in case it improves in the future.</li>
</ul>
-<p>Most of these cross-project drivers appear to be related, and most of them have fed into rEFInd's drivers. I used the Clover package, which in turn was based on the VirtualBox drivers, as a starting point. Everybody else has dropped rEFIt's original ReiserFS driver, but I added that back. Of these drivers, only the Clover EFI Tools NTFS driver is missing from rEFInd. Specific versions can have their own quirks, though. For instance, the Clover (and I suspect VirtualBox) drivers don't return volume labels, which causes rEFInd to display loaders on those volumes as being on a disk called <tt>Unknown</tt>. (I fixed that bug for rEFInd's version, and it wasn't present in the original rEFIt drivers.)</p>
+<p>Most of these cross-project drivers appear to be related, and most of them have fed into rEFInd's drivers. I used the Clover package, which in turn was based on the VirtualBox drivers, as a starting point. Everybody else has dropped rEFIt's original ReiserFS driver, but I added that back. Of these drivers, only the Clover EFI Tools NTFS driver is missing from rEFInd. Specific versions can have their own quirks, though. For instance, the Clover (and I suspect VirtualBox) drivers don't return volume labels, which causes rEFInd to display loaders on those volumes as being on a disk called <tt>Unknown</tt>. (I fixed that bug for rEFInd's version, and it wasn't present in the original rEFIt drivers.) Most of these drivers also suffer from speed problems on some computers. This is worst with the ext2fs drivers under VirtualBox; on my main computer, that combination takes 3 minutes to load a Linux kernel and initial RAM disk file! Most real computers don't suffer nearly so badly, but some can take an extra five seconds or so to boot a kernel. I've fixed the speed problems in rEFInd's drivers as of version 0.7.0.</p>
<p>Driver availability could increase in the future. Source code to a wide variety of filesystems is available in GRUB Legacy, GRUB 2, Linux, various BSD kernels, and in other projects. Sooner or later somebody's likely to begin porting those drivers to EFI. If you do so, or if you know of additional EFI drivers, please <a href="mailto:rodsmith@rodsbooks.com">tell me about it,</a> so I can share the information here. Likewise if you know of a source for other EFI drivers—say, for a video card or disk controller card.</p>
<h2>Notes on Specific Drivers</h2>
</a>
-<p>I've tested several of the drivers described on this page on a handful of systems. The Pfisterer ext2fs driver (from any source) works on both ext2fs and ext3fs, but not on ext4fs—but Agner's derivative ext4fs driver handles ext4fs, so that's not a problem. The ReiserFS driver is obviously useful only on ReiserFS partitions. (Reiser4 is not supported, as far as I know.) Given that ext2fs, ext3fs, and ReiserFS are getting a bit on in age by Linux standards, you might do well to use them on a separate Linux <tt>/boot</tt> partition; however, if you're willing to use ext3fs, ext4fs, or ReiserFS on your root (<tt>/</tt>) filesystem, you can use the EFI drivers to read your kernel from it. Note that this assumes you use conventional partitions; to the best of my knowledge, there's no EFI driver for Linux's Logical Volume Manager (LVM) or Redundant Array of Independent Disks (RAID) configurations, so the EFI can't access filesystems stored in these ways.</p>
-
-<p>The Pfisterer ReiserFS and ext2fs drivers work, but they are a bit sluggish—particularly the ext2fs driver. The Agner ext4fs driver, when handling an actual ext4 filesystem, is in-between these two drivers in speed. The extent of the problem depends on the computer. In my tests so far, VirtualBox has fared the worst. On it, loading a Linux kernel with EFI stub loader from a FAT partition takes 2 seconds, from the moment of selecting the OS in rEFInd to the moment the kernel messages begin to appear. The equivalent time using ReiserFS or HFS+ is 20 seconds, with ext4fs it's 75 seconds, and with ext2fs it's 200 seconds (that is, 3 minutes and 20 seconds). On a 32-bit Mac Mini, though, the speed problem is much less pronounced—my kernel loads in just 3 seconds from a ReiserFS partition and in 13 seconds from an ext2 filesystem. Speeds were similar with my newest computer, an ASUS P8H77-I board. Times with ext2fs on a UEFI PC with an Intel motherboard are in the 2–4 second range. If you try the ext2fs driver and it seems to hang, be patient; it may finally boot up. If so, and if the delay is too great for you to accept, you might consider using ext4fs or ReiserFS instead of ext2fs or ext3fs, at least if a change is practical. (For a <tt>/boot</tt> partition, it almost certainly is practical; you can back it up quite easily, create a fresh filesystem on it, and restore it. You may need to adjust your <tt>/etc/fstab</tt> entry for a new UUID value, though. As noted earlier, be sure to use <tt>notail</tt> as an option in <tt>/etc/fstab</tt> for ReiserFS if you want to read it from EFI.) You can even use HFS+ on a Linux <tt>/boot</tt> partition, although this makes the most sense on a Mac, which has its own EFI HFS+ driver. Of course, you can also create a FAT <tt>/boot</tt> partition and not deal with drivers at all. Mounting your ESP at <tt>/boot</tt> is a practical solution for many users.</p>
+<p>I've tested several of the drivers described on this page on a handful of systems. The Pfisterer ext2fs driver (from any source) works on both ext2fs and ext3fs, but not on ext4fs—but Agner's derivative ext4fs driver handles ext4fs, so that's not a problem. The ReiserFS driver is obviously useful only on ReiserFS partitions. (Reiser4 is not supported, as far as I know.) The Btrfs driver is the newest of the lot, and so I've tested it the least, but it's worked for me on two test systems. Given that ext2fs, ext3fs, and ReiserFS are getting a bit on in age by Linux standards, you might do well to use them on a separate Linux <tt>/boot</tt> partition; however, if you're willing to use ext3fs, ext4fs, Btrfs, or ReiserFS on your root (<tt>/</tt>) filesystem, you can use the EFI drivers to read your kernel from it. Note that this assumes you use conventional partitions; to the best of my knowledge, there's no EFI driver for Linux's Logical Volume Manager (LVM) or Redundant Array of Independent Disks (RAID) configurations, so the EFI can't access filesystems stored in these ways.</p>
-<p>Since the ext2fs and ReiserFS drivers share a common origin, it should come as no surprise that they perform in much the same way no matter which version (rEFIt, Clover, or rEFInd) you use. The NTFS driver from the Clover Tools package is nice and speedy, so if for some reason you need to place a boot loader on an NTFS volume, this driver might be worth tracking down.</p>
+<p>As noted earlier, rEFInd's drivers prior to version 0.7.0, as well as related drivers from rEFIt, Clover, and VirtualBox, suffer from speed problems. These problems are mostly minor, adding a second or two to boot times; but on some computers, the speed problems can be dramatic, boosting kernel-load times up to as much as three minutes (under VirtualBox). If you run into excessive boot times with such a driver, try switching to the latest rEFInd driver instead.</p>
<p>Although ext2fs, ext3fs, ext4fs, and ReiserFS are all case-sensitive, these drivers treat them in a case-insensitive way. Symbolic links work; however, rEFInd 0.6.11 and later ignore symbolic links, since many distributions use them in a way that creates redundant or non-functional entries in the rEFInd menu. You should be able to use hard links if you want to use a single kernel file in multiple ways (say for two distributions).</p>
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 3/14/2012; last Web page update:
-6/18/2013, referencing rEFInd 0.6.12</p>
+6/27/2013, referencing rEFInd 0.7.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>
<li>Inclusion of drivers for the Linux ReiserFS and ext2 filesystems in the
main package. (These drivers are absent from rEFInd prior to version
- 0.4.0. See below concerning an ext4fs driver.)</li>
+ 0.4.0. See below concerning drivers for additional filesystems.)</li>
</ul>
<li>An "exit" option (disabled by default), so that you can return to whatever shell or boot manager you used to launch rEFInd, should this ability be desirable. (This feature first appeared in rEFInd 0.2.4.)</li>
-<li>Drivers for ISO-9660, HFS+, and ext4fs, which are not included in rEFIt. (The ISO-9660 driver is based on code from the rEFIt project, but was never completed by its original author. It was completed by Oracle for VirtualBox. The ext4fs driver is derived from the rEFIt ext2fs driver.)</li>
+<li>Drivers for ISO-9660, HFS+, ext4fs, and Btrfs, which are not included in rEFIt. (The ISO-9660 driver is based on code from the rEFIt project, but was never completed by its original author. It was completed by Oracle for VirtualBox. The ext4fs driver is derived from the rEFIt ext2fs driver, and the Btrfs driver is derived from the rEFIt and GRUB 2.0 driver code.)</li>
<li>Beginning with version 0.5.0, the ability to "talk" to the <a href="http://mjg59.dreamwidth.org/20303.html">shim boot loader</a> to validate binaries supported by shim or its machine owner key (MOK) list when booting with Secure Boot active. As of version 0.6.0, this support is still crude and buggy; it should be considered an alpha-level feature at the moment.</li>
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 3/14/2012; last Web page update:
-6/18/2013, referencing rEFInd 0.6.12</p>
+6/27/2013, referencing rEFInd 0.7.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>
<ul>
<li><b><a
- href="http://sourceforge.net/projects/refind/files/0.6.12/refind-bin-0.6.12.zip/download">A
+ href="http://sourceforge.net/projects/refind/files/0.7.0/refind-bin-0.7.0.zip/download">A
binary zip file</a></b>—Download this if you want to install
rEFInd and/or its filesystem drivers on an <i>x</i>86 or <i>x</i>86-64
computer and have no need to test rEFInd first by booting it on an
href="installing.html">Installing rEFInd</a> page. Some users of Arch
Linux have reported problems booting some specific Arch Linux kernels
with rEFInd and some other tools. For them, a <a
- href="http://sourceforge.net/projects/refind/files/0.6.12/refind-bin-gnuefi-0.6.12.zip/download">variant
+ href="http://sourceforge.net/projects/refind/files/0.7.0/refind-bin-gnuefi-0.7.0.zip/download">variant
package</a> exists in which the <i>x</i>86-64 binary was compiled with
GNU-EFI rather than the usual TianoCore EDK2. This change helps some
users with this problem; but using GNU-EFI also means that this version
can't launch BIOS-mode OSes.</li>
<li><b><a
- href="http://sourceforge.net/projects/refind/files/0.6.12/refind-0.6.12-1.x86_64.rpm/download">A
+ href="http://sourceforge.net/projects/refind/files/0.7.0/refind-0.7.0-1.x86_64.rpm/download">A
binary RPM file</a></b>—If you use an RPM-based <i>x</i>86-64
Linux system such as Fedora or openSUSE, you can install the binary RPM
package rather than use the binary zip file. (I don't provide an
rEFInd</a> page) as part of the installation process. Distribution
maintainers can examine the <tt>refind.spec</tt> file in the source
package and tweak it to their needs. The <a
- href="http://sourceforge.net/projects/refind/files/0.6.12/refind-0.6.12-1.src.rpm/download">source
+ href="http://sourceforge.net/projects/refind/files/0.7.0/refind-0.7.0-1.src.rpm/download">source
RPM file</a> might or might not build on your system as-is; it relies
on assumptions about the locations of the GNU-EFI development
files.</li>
<li><b><a
- href="http://sourceforge.net/projects/refind/files/0.6.12/refind_0.6.12-1_amd64.deb/download">A
+ href="http://sourceforge.net/projects/refind/files/0.7.0/refind_0.7.0-1_amd64.deb/download">A
binary Debian package</a></b>—If you use an <i>x</i>86-64 version
of Debian, Ubuntu, Mint, or another Debian-based distribution, you can
install from this package, which was converted from the binary RPM
<p class="sidebar"><b>Note:</b> At the moment, neither the bootable CD-R image file nor the bootable USB flash drive image file supports booting with Secure Boot active.</p>
<li><b><a
- href="http://sourceforge.net/projects/refind/files/0.6.12/refind-cd-0.6.12.zip/download">A
+ href="http://sourceforge.net/projects/refind/files/0.7.0/refind-cd-0.7.0.zip/download">A
CD-R image file</a></b>—This download contains the same files as
the binary zip file, but you can burn it to a CD-R to test rEFInd
(and its filesystem drivers) without installing it first. (It boots on
computer.</p>
<li><b><a
- href="http://sourceforge.net/projects/refind/files/0.6.12/refind-flashdrive-0.6.12.zip/download">A
+ href="http://sourceforge.net/projects/refind/files/0.7.0/refind-flashdrive-0.7.0.zip/download">A
USB flash drive image file</a></b>—Although you can create
your own rEFInd USB flash drive, you may find it easier to download
this version and copy it to your USB drive with <tt>dd</tt> or some
other low-level disk copying utility.</li>
<li><b><a
- href="http://sourceforge.net/projects/refind/files/0.6.12/refind-src-0.6.12.zip/download">A
+ href="http://sourceforge.net/projects/refind/files/0.7.0/refind-src-0.7.0.zip/download">A
source code zip file</a></b>—This is useful if you want to compile
the software locally. Note that I use Linux with the <a
href="https://sourceforge.net/projects/tianocore/">TianoCore EFI
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 3/14/2012; last Web page update:
-6/18/2013, referencing rEFInd 0.6.12</p>
+6/27/2013, referencing rEFInd 0.7.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>
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 3/19/2012; last Web page update:
-6/18/2013, referencing rEFInd 0.6.12</p>
+6/27/2013, referencing rEFInd 0.7.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>
<h3>For Those With Foresight or Luck: The Easiest Method</h3>
</a>
-<p>This method requires that your <tt>/boot</tt> directory, whether it's on a separate partition or is a regular directory in your root (<tt>/</tt>) filesystem, be readable by the EFI. At the moment, all EFI implementations can read FAT and Macs can read HFS+. By using <a href="drivers.html">drivers,</a> you can make any EFI read HFS+, ISO-9660, ReiserFS, ext2fs, ext3fs, or ext4fs. Thus, if you use any of these filesystems on a regular partition (not an LVM or RAID configuration) that holds your kernels in <tt>/boot</tt>, you qualify for this easy method. The default partition layouts used by Ubuntu, Fedora, and many other distributions qualify, because they use one of these filesystems (usually ext4fs) in a normal partition or on a separate <tt>/boot</tt> partition. You must also have a 3.3.0 or later Linux kernel with EFI stub support, of course.</p>
+<p>This method requires that your <tt>/boot</tt> directory, whether it's on a separate partition or is a regular directory in your root (<tt>/</tt>) filesystem, be readable by the EFI. At the moment, all EFI implementations can read FAT and Macs can read HFS+. By using <a href="drivers.html">drivers,</a> you can make any EFI read HFS+, ISO-9660, ReiserFS, ext2fs, ext3fs, ext4fs, or Btrfs. Thus, if you use any of these filesystems on a regular partition (not an LVM or RAID configuration) that holds your kernels in <tt>/boot</tt>, you qualify for this easy method. The default partition layouts used by Ubuntu, Fedora, and many other distributions qualify, because they use one of these filesystems (usually ext4fs) in a normal partition or on a separate <tt>/boot</tt> partition. You must also have a 3.3.0 or later Linux kernel with EFI stub support, of course.</p>
<p>If you installed rEFInd 0.6.0 or later with its <tt>install.sh</tt> script from your regular Linux installation, chances are everything's set up; you should be able to reboot and see your Linux kernels as boot options. If you installed manually, from OS X, or from an emergency system, though, you may need to do a couple of things manually:
<h3>If You Need to Reconfigure Your Partitions....</h3>
</a>
-<p>If your <tt>/boot</tt> directory happens to be on an XFS
, JFS, or Btrfs partition that the EFI can't read, or it's tucked away in an LVM or RAID configuration that the EFI can't read, you won't be able to use the <a href="#easiest">easiest solution.</a> Fortunately, this problem can be overcome with relatively little fuss. Several variant procedures are possible, but I begin by describing one that will almost always work, although it's got some important caveats (described at the end). You should perform the following steps as <tt>root</tt>, or precede each of these commands with <tt>sudo</tt>:</p>
+<p>If your <tt>/boot</tt> directory happens to be on an XFS
or JFS partition that the EFI can't read, or it's tucked away in an LVM or RAID configuration that the EFI can't read, you won't be able to use the <a href="#easiest">easiest solution.</a> Fortunately, this problem can be overcome with relatively little fuss. Several variant procedures are possible, but I begin by describing one that will almost always work, although it's got some important caveats (described at the end). You should perform the following steps as <tt>root</tt>, or precede each of these commands with <tt>sudo</tt>:</p>
<ol>
<p>Once this task is done, updates to your kernel will automatically be stored in the root directory of your ESP, where rEFInd will automatically detect them. Thus, the boot configuration becomes maintenance-free. The procedure as just described has some drawbacks, though. By placing your kernels in the root directory of your ESP, you render them vulnerable to any other OS with which you might be dual-booting. Your ESP must also be large enough to hold all your kernels. If you dual-boot with multiple Linux distributions, they might conceivably overwrite each others' kernels, and distinguishing one from another becomes more difficult.</p>
-<p>For these reasons, a variant of this procedure is desirable on some systems. Most of the steps are similar, but in this variant, you create a separate <tt>/boot</tt> partition that's independent of the ESP. This partition can use FAT, HFS+, ReiserFS, ext2fs, ext3fs, or ext4fs; but if you use any of the last five filesystems (four on Macs), you must install the matching EFI filesystem driver that ships with rEFInd. Creating the filesystem will normally require you to shrink an existing partition by a suitable amount (200–500MiB). Mount your new <tt>/boot</tt> partition at a temporary location, copy or move the current <tt>/boot</tt> files into it, unmount it, and add it to <tt>/etc/fstab</tt> as <tt>/boot</tt>.</p>
+<p>For these reasons, a variant of this procedure is desirable on some systems. Most of the steps are similar, but in this variant, you create a separate <tt>/boot</tt> partition that's independent of the ESP. This partition can use FAT, HFS+, ReiserFS, ext2fs, ext3fs, ext4fs, or Btrfs; but if you use any of the last six filesystems (five on Macs), you must install the matching EFI filesystem driver that ships with rEFInd. Creating the filesystem will normally require you to shrink an existing partition by a suitable amount (200–500MiB). Mount your new <tt>/boot</tt> partition at a temporary location, copy or move the current <tt>/boot</tt> files into it, unmount it, and add it to <tt>/etc/fstab</tt> as <tt>/boot</tt>.</p>
-<p>If your distribution already uses a separate <tt>/boot</tt> partition, but if it uses XFS or some other unsuitable filesystem, you can back it up, create a fresh FAT, HFS+, ReiserFS, ext2, ext3, or ext4 filesystem on it, and restore the original files. You'll probably need to adjust the UUID value in <tt>/etc/fstab</tt> to ensure that the computer mounts the new filesystem when you boot. If you use a separate non-ESP <tt>/boot</tt> partition, you'll probably want to continue mounting the ESP at <tt>/boot/efi</tt>.</p>
+<p>If your distribution already uses a separate <tt>/boot</tt> partition, but if it uses XFS or some other unsuitable filesystem, you can back it up, create a fresh FAT, HFS+, ReiserFS, Btrfs, ext2, ext3, or ext4 filesystem on it, and restore the original files. You'll probably need to adjust the UUID value in <tt>/etc/fstab</tt> to ensure that the computer mounts the new filesystem when you boot. If you use a separate non-ESP <tt>/boot</tt> partition, you'll probably want to continue mounting the ESP at <tt>/boot/efi</tt>.</p>
<a name="efistub">
<h2>EFI Stub Loader Support Technical Details</h2>
</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>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 good (ext2fs/ext3fs, ext4fs, ReiserFS, Btrfs, ISO-9660, and HFS+), so chances are you'll be able to use this method to boot your kernel from your root (<tt>/</tt>) partition or from a <tt>/boot</tt> partition.</p>
<p>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. One caveat you should keep in mind is that the EFI and Windows interpret the hardware clock as local time, whereas Mac OS X uses <a href="http://en.wikipedia.org/wiki/Coordinated_Universal_Time">Coordinated Universal Time (UTC)</a>. Linux can work either way. Thus, time stamps for boot loaders can be skewed by several hours depending on the environment in which they were created or last modified.</p>
<p class="subhead">by Roderick W. Smith, <a
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
-<p>Last Web page update: 6/18/2013</p>
+<p>Last Web page update: 6/27/2013</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>
<ul>
+<li><b>0.7.0 (6/27/2013)</b>—Improvements to the filesystem drivers dominate this version. The biggest change is a new Btrfs driver, created by Samuel Liao and based in part on the GRUB 2.0 Btrfs support. The drivers also now include a read cache to improve their speed. This has only a tiny effect on most computers, but on some it can speed boot times by a few seconds, and under VirtualBox the effect is dramatic—the ext2fs driver goes from a sluggish three <i>minutes</i> to load a kernel and initrd to three <i>seconds</i>. I've also changed some critical filesystem driver pointers from 32-bit to 64-bit, which may enable some of them to work with larger filesystems, although this isn't yet tested. The main rEFInd binary sports only two changes: It can now identify Btrfs volumes as such for labelling purposes and it can now filter out invalid loaders (those for the wrong architecture or Linux kernels that lack EFI stub loader support, for instance).</li>
+
<li><b>0.6.12 (6/18/2013)</b>—This version changes relatively little code, but it adds one feature that will simplify rEFInd installation for some users: The program can now deduce minimal Linux boot options based on an <tt>/etc/fstab</tt> file <i>if</i> that file is on the same partition as the kernel (in other words, if you do <i>not</i> use a separate <tt>/boot</tt> partition). Put another way, <tt>refind_linux.conf</tt> is no longer required for some installations, although it's still desirable. If you're already using rEFInd, this isn't likely to be important, but it can help when you're just starting out. In addition, this version adds support for the Linux Foundation's PreBootloader in the <tt>install.sh</tt> script. I've also changed the default 64-bit shell included on the CD-R and USB flash drive images to a modified version 2 shell, so as to enable use of the <tt>bcfg</tt> command to help install rEFInd (or make other changes to the firmware's boot manager configuration).</li>
<li><b>0.6.11 (5/13/2013)</b>—Two new features may have a noticeable affect for many users: First, rEFInd now ignores symbolic links on filesystems that support them. I've implemented this change because I've been receiving too many reports from users who want to remove redundant or non-functional Linux boot entries caused by symbolic links created by distributions. Although this is possible by editing the <tt>dont_scan_dirs</tt> or <tt>dont_scan_files</tt> options in <tt>refind.conf</tt>, telling users how to do this has become tedious. If you <i>want</i> to use links to create multiple entries for one kernel or boot loader, use hard links instead of symbolic links. The second major user-visible change is that rEFInd now tries to guess the distribution type based on the naming of the kernel file (effective only for Fedora and RHEL) or the contents of the <tt>/etc/os-release</tt> file (effective only if the installation does <i>not</i> have a separate </tt>/boot</tt> partition or if <tt>/etc/os-release</tt> is copied to that location on the partition that holds the kernel). There are several other minor cosmetic issues that some users may notice, including icons for Lubuntu and Kubuntu and a change in the name of the "Reboot to Firmware User Interface" option to "Reboot to Computer Setup Utility." I've also fixed a bug in <tt>gptsync</tt> that could cause it to hang if the disk had too few GPT partitions. Finally, I've improved the <tt>install.sh</tt> script so that it works better from a path with directory names that include spaces.</li>
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 11/13/2012; last Web page update:
-6/18/2013, referencing rEFInd 0.6.12</p>
+6/27/2013, referencing rEFInd 0.7.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>
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 4/19/2012; last Web page update:
-6/18/2013, referencing rEFInd 0.6.12</p>
+6/27/2013, referencing rEFInd 0.7.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>
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 3/14/2012; last Web page update:
-6/18/2013, referencing rEFInd 0.6.12</p>
+6/27/2013, referencing rEFInd 0.7.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>
<ul>
- <li>Drivers for additional filesystems are desirable. Given the talk of
- shifting to Btrfs, that should be the priority; however, other
- Linux filesystems, UDF, and perhaps others would all be welcome
- additions. Also along these lines, adding drivers for Linux LVM and
- RAID setups would be useful, too.</li>
-
- <li>As detailed on the <a href="drivers.html">drivers page,</a> there
- are performance issues with the drivers on some systems. I suspect
- that most "real" computers aren't greatly affected (in my tests,
- the problem is worst with VirtualBox, and the next worst is a
- system that uses <a
- href="http://www.rodsbooks.com/bios2uefi/">DUET</a>). Nonetheless,
- I'd like to track down the cause and fix it.</li>
+ <li>Drivers for additional filesystems are desirable. Only XFS and JFS
+ are missing from the major Linux filesystems. UDF would also be a
+ welcome addition, as might drivers for other OSes (say, for the
+ BSDs, especially if BSD developers create a boot loader similar to
+ Linux's EFI stub loader). Also along these lines, adding drivers
+ for Linux LVM and RAID setups would be useful.</li>
<li>The HFS+ driver returns a volume label of "HFS+ volume", no matter
what the volume's real label is.</li>
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 3/14/2012; last Web page update:
-6/18/2013, referencing rEFInd 0.6.12</p>
+6/27/2013, referencing rEFInd 0.7.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>
LD_CODE = elf_x86_64
endif
-LOCAL_CPPFLAGS = -DCACHE=$(CACHE) -DFSTYPE=$(DRIVERNAME) $(ARCH_C_FLAGS) -I$(SRCDIR) -I$(SRCDIR)/../include -I$(SRCDIR)/../libeg
+LOCAL_CPPFLAGS = -DFSTYPE=$(DRIVERNAME) $(ARCH_C_FLAGS) -I$(SRCDIR) -I$(SRCDIR)/../include -I$(SRCDIR)/../libeg
OBJS = fsw_core.o fsw_efi.o fsw_efi_lib.o fsw_lib.o fsw_$(DRIVERNAME).o
TARGET = $(DRIVERNAME)_$(FILENAME_CODE).efi
--entry _ModuleEntryPoint -u _ModuleEntryPoint -m $(LD_CODE)
%.obj: %.c
- $(CC) $(ARCH_C_FLAGS) $(CFLAGS) $(INCLUDE_DIRS) -DCACHE=$(CACHE) -DFSTYPE=$(DRIVERNAME) -DNO_BUILTIN_VA_FUNCS -c $< -o $@
+ $(CC) $(ARCH_C_FLAGS) $(CFLAGS) $(INCLUDE_DIRS) -DFSTYPE=$(DRIVERNAME) -DNO_BUILTIN_VA_FUNCS -c $< -o $@
ifneq (,$(filter %.efi,$(BUILDME)))
ext2:
rm -f fsw_efi.obj
- +make DRIVERNAME=ext2 CACHE=0 -f Make.tiano
+ +make DRIVERNAME=ext2 -f Make.tiano
ext4:
rm -f fsw_efi.obj
- +make DRIVERNAME=ext4 CACHE=1 -f Make.tiano
+ +make DRIVERNAME=ext4 -f Make.tiano
reiserfs:
rm -f fsw_efi.obj
- +make DRIVERNAME=reiserfs CACHE=1 -f Make.tiano
+ +make DRIVERNAME=reiserfs -f Make.tiano
iso9660:
rm -f fsw_efi.obj
- +make DRIVERNAME=iso9660 CACHE=1 -f Make.tiano
+ +make DRIVERNAME=iso9660 -f Make.tiano
hfs:
rm -f fsw_efi.obj
- +make DRIVERNAME=hfs CACHE=1 -f Make.tiano
+ +make DRIVERNAME=hfs -f Make.tiano
btrfs:
rm -f fsw_efi.obj
- +make DRIVERNAME=btrfs CACHE=1 -f Make.tiano
+ +make DRIVERNAME=btrfs -f Make.tiano
# Build the drivers with GNU-EFI....
ext2_gnuefi:
rm -f fsw_efi.o
- +make DRIVERNAME=ext2 CACHE=0 -f Make.gnuefi
+ +make DRIVERNAME=ext2 -f Make.gnuefi
ext4_gnuefi:
rm -f fsw_efi.o
- +make DRIVERNAME=ext4 CACHE=1 -f Make.gnuefi
+ +make DRIVERNAME=ext4 -f Make.gnuefi
reiserfs_gnuefi:
rm -f fsw_efi.o
- +make DRIVERNAME=reiserfs CACHE=1 -f Make.gnuefi
+ +make DRIVERNAME=reiserfs -f Make.gnuefi
iso9660_gnuefi:
rm -f fsw_efi.o
- +make DRIVERNAME=iso9660 CACHE=1 -f Make.gnuefi
+ +make DRIVERNAME=iso9660 -f Make.gnuefi
hfs_gnuefi:
rm -f fsw_efi.o
- +make DRIVERNAME=hfs CACHE=1 -f Make.gnuefi
+ +make DRIVERNAME=hfs -f Make.gnuefi
btrfs_gnuefi:
rm -f fsw_efi.o
- +make DRIVERNAME=btrfs CACHE=1 -f Make.gnuefi
+ +make DRIVERNAME=btrfs -f Make.gnuefi
# utility rules
#include "scandisk.c"
#define BTRFS_DEFAULT_BLOCK_SIZE 4096
-//#define BTRFS_DEFAULT_BLOCK_SIZE 8192
#define BTRFS_INITIAL_BCACHE_SIZE 1024
#define GRUB_BTRFS_SIGNATURE "_BHRfS_M"
* caller calls fsw_block_release.
*/
-fsw_status_t fsw_block_get(struct VOLSTRUCTNAME *vol, fsw_u32 phys_bno, fsw_u32 cache_level, void **buffer_out)
+fsw_status_t fsw_block_get(struct VOLSTRUCTNAME *vol, fsw_u64 phys_bno, fsw_u32 cache_level, void **buffer_out)
{
fsw_status_t status;
fsw_u32 i, discard_level, new_bcache_size;
for (i = 0; i < vol->bcache_size; i++) {
vol->bcache[i].refcount = 0;
vol->bcache[i].cache_level = 0;
- vol->bcache[i].phys_bno = (fsw_u32)FSW_INVALID_BNO;
+ vol->bcache[i].phys_bno = (fsw_u64)FSW_INVALID_BNO;
vol->bcache[i].data = NULL;
}
i = 0;
// find a free entry in the cache table
for (i = 0; i < vol->bcache_size; i++) {
- if (vol->bcache[i].phys_bno == (fsw_u32)FSW_INVALID_BNO)
+ if (vol->bcache[i].phys_bno == (fsw_u64)FSW_INVALID_BNO)
break;
}
if (i >= vol->bcache_size) {
for (i = vol->bcache_size; i < new_bcache_size; i++) {
new_bcache[i].refcount = 0;
new_bcache[i].cache_level = 0;
- new_bcache[i].phys_bno = (fsw_u32)FSW_INVALID_BNO;
+ new_bcache[i].phys_bno = (fsw_u64)FSW_INVALID_BNO;
new_bcache[i].data = NULL;
}
i = vol->bcache_size;
vol->bcache = new_bcache;
vol->bcache_size = new_bcache_size;
}
- vol->bcache[i].phys_bno = (fsw_u32)FSW_INVALID_BNO;
+ vol->bcache[i].phys_bno = (fsw_u64)FSW_INVALID_BNO;
miss:
// read the data
* from fsw_block_get.
*/
-void fsw_block_release(struct VOLSTRUCTNAME *vol, fsw_u32 phys_bno, void *buffer)
+void fsw_block_release(struct VOLSTRUCTNAME *vol, fsw_u64 phys_bno, void *buffer)
{
fsw_u32 i;
struct fsw_dnode *dno = shand->dnode;
struct fsw_volume *vol = dno->vol;
fsw_u8 *buffer, *block_buffer;
- fsw_u32 buflen, copylen, pos;
- fsw_u32 log_bno, pos_in_extent, phys_bno, pos_in_physblock;
+ fsw_u64 buflen, copylen, pos;
+ fsw_u64 log_bno, pos_in_extent, phys_bno, pos_in_physblock;
fsw_u32 cache_level;
if (shand->pos >= dno->size) { // already at EOF
while (buflen > 0) {
// get extent for the current logical block
- log_bno = pos / vol->log_blocksize;
+ log_bno = FSW_U64_DIV(pos, vol->log_blocksize);
if (shand->extent.type == FSW_EXTENT_TYPE_INVALID ||
log_bno < shand->extent.log_start ||
log_bno >= shand->extent.log_start + shand->extent.log_count) {
// dispatch by extent type
if (shand->extent.type == FSW_EXTENT_TYPE_PHYSBLOCK) {
// convert to physical block number and offset
- phys_bno = shand->extent.phys_start + pos_in_extent / vol->phys_blocksize;
+ phys_bno = shand->extent.phys_start + FSW_U64_DIV(pos_in_extent, vol->phys_blocksize);
pos_in_physblock = pos_in_extent & (vol->phys_blocksize - 1);
copylen = vol->phys_blocksize - pos_in_physblock;
if (copylen > buflen)
#define FSW_FSTYPE_TABLE_NAME(t) FSW_CONCAT3(fsw_,t,_table)
/** Indicates that the block cache entry is empty. */
-#define FSW_INVALID_BNO (~0UL)
+#define FSW_INVALID_BNO 0xFFFFFFFFFFFFFFFF
//
struct fsw_blockcache {
fsw_u32 refcount; //!< Reference count
fsw_u32 cache_level; //!< Level of importance of this block
- fsw_u32 phys_bno; //!< Physical block number
+ fsw_u64 phys_bno; //!< Physical block number
void *data; //!< Block data buffer
};
struct fsw_extent {
fsw_u32 type; //!< Type of extent specification
- fsw_u32 log_start; //!< Starting logical block number
+ fsw_u64 log_start; //!< Starting logical block number
fsw_u32 log_count; //!< Logical block count
- fsw_u32 phys_start; //!< Starting physical block number (for FSW_EXTENT_TYPE_PHYSBLOCK only)
+ fsw_u64 phys_start; //!< Starting physical block number (for FSW_EXTENT_TYPE_PHYSBLOCK only)
void *buffer; //!< Allocated buffer pointer (for FSW_EXTENT_TYPE_BUFFER only)
};
void (*change_blocksize)(struct fsw_volume *vol,
fsw_u32 old_phys_blocksize, fsw_u32 old_log_blocksize,
fsw_u32 new_phys_blocksize, fsw_u32 new_log_blocksize);
- fsw_status_t (*read_block)(struct fsw_volume *vol, fsw_u32 phys_bno, void *buffer);
+ fsw_status_t (*read_block)(struct fsw_volume *vol, fsw_u64 phys_bno, void *buffer);
};
/**
fsw_status_t fsw_volume_stat(struct fsw_volume *vol, struct fsw_volume_stat *sb);
void fsw_set_blocksize(struct VOLSTRUCTNAME *vol, fsw_u32 phys_blocksize, fsw_u32 log_blocksize);
-fsw_status_t fsw_block_get(struct VOLSTRUCTNAME *vol, fsw_u32 phys_bno, fsw_u32 cache_level, void **buffer_out);
-void fsw_block_release(struct VOLSTRUCTNAME *vol, fsw_u32 phys_bno, void *buffer);
+fsw_status_t fsw_block_get(struct VOLSTRUCTNAME *vol, fsw_u64 phys_bno, fsw_u32 cache_level, void **buffer_out);
+void fsw_block_release(struct VOLSTRUCTNAME *vol, fsw_u64 phys_bno, void *buffer);
/*@}*/
/** Helper macro for stringification. */
#define FSW_EFI_STRINGIFY(x) #x
/** Expands to the EFI driver name given the file system type name. */
-#define FSW_EFI_DRIVER_NAME(t) L"rEFInd 0.6.12.2 " FSW_EFI_STRINGIFY(t) L" File System Driver"
+#define FSW_EFI_DRIVER_NAME(t) L"rEFInd 0.7.0 " FSW_EFI_STRINGIFY(t) L" File System Driver"
// function prototypes
void fsw_efi_change_blocksize(struct fsw_volume *vol,
fsw_u32 old_phys_blocksize, fsw_u32 old_log_blocksize,
fsw_u32 new_phys_blocksize, fsw_u32 new_log_blocksize);
-fsw_status_t fsw_efi_read_block(struct fsw_volume *vol, fsw_u32 phys_bno, void *buffer);
+fsw_status_t fsw_efi_read_block(struct fsw_volume *vol, fsw_u64 phys_bno, void *buffer);
EFI_STATUS fsw_efi_map_status(fsw_status_t fsw_status, FSW_VOLUME_DATA *Volume);
IN OUT UINTN *BufferSize,
OUT VOID *Buffer);
+/**
+ * Structure for holding disk cache data.
+ */
+
+#define CACHE_SIZE 131072 /* 128KiB */
+struct cache_data {
+ fsw_u8 *Cache;
+ fsw_u64 CacheStart;
+ BOOLEAN CacheValid;
+ FSW_VOLUME_DATA *Volume; // NOTE: Do not deallocate; copied here to ID volume
+};
+
+#define NUM_CACHES 2 /* Don't increase without modifying fsw_efi_read_block() */
+static struct cache_data Caches[NUM_CACHES];
+
/**
* Interface structure for the EFI Driver Binding protocol.
*/
EFI_STATUS Status;
EFI_FILE_IO_INTERFACE *FileSystem;
FSW_VOLUME_DATA *Volume;
+ int i;
#if DEBUG_LEVEL
Print(L"fsw_efi_DriverBinding_Stop\n");
This->DriverBindingHandle,
ControllerHandle);
+ // clear the cache
+ for (i = 0; i < NUM_CACHES; i++) {
+ if (Caches[i].Cache != NULL) {
+ FreePool(Caches[i].Cache);
+ Caches[i].Cache = NULL;
+ } // if
+ }
return Status;
}
/**
* FSW interface function to read data blocks. This function is called by the FSW core
* to read a block of data from the device. The buffer is allocated by the core code.
+ * Two caches are maintained, so as to improve performance on some systems. (VirtualBox
+ * is particularly susceptible to performance problems with an uncached driver -- the
+ * ext2 driver can take 200 seconds to load a Linux kernel under VirtualBox, whereas
+ * the time is more like 3 seconds with a cache!) Two independent caches are maintained
+ * because the ext2fs driver tends to alternate between accessing two parts of the
+ * disk.
*/
-
-#if CACHE != 0
-/**
- * This version implements a primitive cache that greatly improves performance of most
- * filesystems under VirtualBox, and slightly improves it on a handful of other systems.
- */
-#define CACHE_SIZE 131072 /* 128KiB */
-fsw_status_t fsw_efi_read_block(struct fsw_volume *vol, fsw_u32 phys_bno, void *buffer)
-{
- EFI_STATUS Status = EFI_SUCCESS;
- FSW_VOLUME_DATA *Volume = (FSW_VOLUME_DATA *)vol->host_data;
- static fsw_u8 *Cache = NULL;
- static fsw_u64 CacheStart = 0;
- static BOOLEAN CacheValid = FALSE;
- static FSW_VOLUME_DATA *PrevVol = NULL;
- fsw_u64 StartRead = (fsw_u64) phys_bno * vol->phys_blocksize;
-
-// FSW_MSG_DEBUGV((FSW_MSGSTR("fsw_efi_read_block: %d (%d)\n"), phys_bno, vol->phys_blocksize));
-
- if (Cache == NULL) {
- Cache = AllocatePool(CACHE_SIZE);
- }
-
- if ((PrevVol != Volume) || (StartRead < CacheStart) || ((StartRead + vol->phys_blocksize) > CacheStart + CACHE_SIZE)) {
- CacheStart = StartRead;
- CacheValid = FALSE;
- PrevVol = Volume;
- }
-
- // read from disk
- if (!CacheValid && (Cache != NULL)) {
- Status = refit_call5_wrapper(Volume->DiskIo->ReadDisk, Volume->DiskIo, Volume->MediaId,
- StartRead, CACHE_SIZE, Cache);
- if (!EFI_ERROR(Status))
- CacheValid = TRUE;
- } // if (!CacheValid)
-
- if (CacheValid) {
- if (buffer != NULL) {
- CopyMem(buffer, &Cache[StartRead - CacheStart], vol->phys_blocksize);
- } else {
- Status = EFI_BAD_BUFFER_SIZE;
- } // if/else buffer OK
- } else {
- // Unable to use cache; load without cache....
- Status = refit_call5_wrapper(Volume->DiskIo->ReadDisk, Volume->DiskIo, Volume->MediaId,
- (UINT64)phys_bno * vol->phys_blocksize,
- vol->phys_blocksize,
- buffer);
- } // if/else CacheValid
-
- Volume->LastIOStatus = Status;
- if (EFI_ERROR(Status))
- return FSW_IO_ERROR;
- return FSW_SUCCESS;
-}
-#else
-/**
- * This version is the original, which does NOT implement a cache. It performs badly under
- * VirtualBox, but I'm still using it for ext2fs because there seems to be a glitch in the
- * ext2fs driver that causes a loop that repeatedly re-reads pairs of sectors, and the
- * primitive cache in the preceding code just makes that worse.
- */
-fsw_status_t fsw_efi_read_block(struct fsw_volume *vol, fsw_u32 phys_bno, void *buffer)
-{
- EFI_STATUS Status;
- FSW_VOLUME_DATA *Volume = (FSW_VOLUME_DATA *)vol->host_data;
-
-// FSW_MSG_DEBUGV((FSW_MSGSTR("fsw_efi_read_block: %d (%d)\n"), phys_bno, vol->phys_blocksize));
-
- // read from disk
- Status = refit_call5_wrapper(Volume->DiskIo->ReadDisk, Volume->DiskIo, Volume->MediaId,
- (UINT64)phys_bno * vol->phys_blocksize,
- vol->phys_blocksize,
- buffer);
- Volume->LastIOStatus = Status;
- if (EFI_ERROR(Status))
- return FSW_IO_ERROR;
- return FSW_SUCCESS;
-}
-#endif
+fsw_status_t fsw_efi_read_block(struct fsw_volume *vol, fsw_u64 phys_bno, void *buffer) {
+ static int LastRead = -1;
+ int i, ReadCache = -1;
+ FSW_VOLUME_DATA *Volume = (FSW_VOLUME_DATA *)vol->host_data;
+ EFI_STATUS Status = EFI_SUCCESS;
+ BOOLEAN ReadOneBlock = FALSE;
+ fsw_u64 StartRead = phys_bno * vol->phys_blocksize;
+
+ if (buffer == NULL)
+ return (fsw_status_t) EFI_BAD_BUFFER_SIZE;
+
+ // Initialize static data structures, if necessary....
+ if (LastRead < 0) {
+ for (i = 0; i < NUM_CACHES; i++) {
+ Caches[i].Cache = NULL;
+ Caches[i].CacheStart = 0;
+ Caches[i].CacheValid = FALSE;
+ Caches[i].Volume = NULL;
+ } // for
+ } // if
+
+ // Look for a cache hit on the current query....
+ i = 0;
+ do {
+ if ((Caches[i].Volume == Volume) &&
+ (StartRead >= Caches[i].CacheStart) &&
+ ((StartRead + vol->phys_blocksize) <= (Caches[i].CacheStart + CACHE_SIZE))) {
+ ReadCache = i;
+ }
+ i++;
+ } while ((i < NUM_CACHES) && (ReadCache < 0));
+
+ // No cache hit found; load new cache and pass it on....
+ if (ReadCache < 0) {
+ if (LastRead == -1)
+ LastRead = 1;
+ ReadCache = 1 - LastRead; // NOTE: If NUM_CACHES > 2, this must become more complex
+ if (Caches[ReadCache].Cache == NULL)
+ Caches[ReadCache].Cache = AllocatePool(CACHE_SIZE);
+ if (Caches[ReadCache].Cache != NULL) {
+ Status = refit_call5_wrapper(Volume->DiskIo->ReadDisk, Volume->DiskIo, Volume->MediaId,
+ StartRead, CACHE_SIZE, Caches[ReadCache].Cache);
+ if (!EFI_ERROR(Status)) {
+ Caches[ReadCache].CacheStart = StartRead;
+ Caches[ReadCache].CacheValid = TRUE;
+ Caches[ReadCache].Volume = Volume;
+ LastRead = ReadCache;
+ } else {
+ ReadOneBlock = TRUE;
+ }
+ } else {
+ ReadOneBlock = TRUE;
+ } // if cache memory allocated
+ } // if (ReadCache < 0)
+
+ if (Caches[ReadCache].Cache != NULL) {
+ CopyMem(buffer, &Caches[ReadCache].Cache[StartRead - Caches[ReadCache].CacheStart], vol->phys_blocksize);
+ } else {
+ ReadOneBlock = TRUE;
+ }
+
+ if (ReadOneBlock) { // Something's failed, so try a simple disk read of one block....
+ Status = refit_call5_wrapper(Volume->DiskIo->ReadDisk, Volume->DiskIo, Volume->MediaId,
+ phys_bno * vol->phys_blocksize,
+ vol->phys_blocksize,
+ buffer);
+ }
+
+ return Status;
+} // fsw_status_t *fsw_efi_read_block()
/**
* Map FSW status codes to EFI status codes. The FSW_IO_ERROR code is only produced
struct fsw_extent *extent)
{
fsw_status_t status;
- fsw_u32 bno, release_bno, buf_offset, file_bcnt;
+ fsw_u32 bno, buf_offset;
int ext_cnt;
void *buffer;
struct iso9660_dirrec rootdir;
int sua_pos;
char *sig;
- int skip;
struct fsw_rock_ridge_susp_entry *entry;
// read through the Volume Descriptor Set
#if 1
status = fsw_block_get(vol, ISOINT(rootdir.extent_location), 0, &buffer);
sig = (char *)buffer + sua_pos;
- skip = 0;
entry = (struct fsw_rock_ridge_susp_entry *)sig;
if ( entry->sig[0] == 'S'
&& entry->sig[1] == 'P')
// FSW_MSG_DEBUG((FSW_MSGSTR("fsw_iso9660_volume_mount: SP magic isn't valid\n")));
// DBG("fsw_iso9660_volume_mount: SP magic isn't valid\n");
}
- skip = sp->skip;
}
#endif
// release volume descriptors
{
fsw_status_t status;
fsw_u32 dir_id, objectid;
- fsw_u64 offset;
fsw_u32 tree_bno, next_tree_bno, tree_level, nr_item, nr_ptr_item;
fsw_u8 *buffer;
struct block_head *bhead;
dir_id = item->ih.ih_key.k_dir_id;
objectid = item->ih.ih_key.k_objectid;
- offset = item->item_offset;
- FSW_MSG_DEBUG((FSW_MSGSTR("fsw_reiserfs_item_next: next for %d/%d/%lld\n"), dir_id, objectid, offset));
+ FSW_MSG_DEBUG((FSW_MSGSTR("fsw_reiserfs_item_next: next for %d/%d/%lld\n"), dir_id, objectid, item->item_offset));
// find a node that has more items, moving up until we find one
#
# Revision history:
#
+# 0.7.0 -- Added support for the new Btrfs driver
# 0.6.12 -- Added support for PreLoader as well as for shim
# 0.6.11 -- Improvements in script's ability to handle directories with spaces
# in their names
;;
reiserfs) DriverType="reiserfs"
;;
+ btrfs) DriverType="btrfs"
+ ;;
hfsplus) DriverType="hfs"
;;
*) BootFS=""
# Build the IA32 binaries
cd refind-$1
-ARCH=ia32 make -j4
+ARCH=ia32 make -j1
ARCH=ia32 make fs
mkdir -p refind-bin-$1/refind/drivers_ia32
cp --preserve=timestamps drivers_ia32/*_ia32.efi refind-bin-$1/refind/drivers_ia32/
# Build the X64 binaries
make clean
-make -j4
+make -j1
make fs
mkdir -p refind-bin-$1/refind/drivers_x64
cp -a icons refind-bin-$1/refind/
# Prepare a variant with the x86-64 version built with GNU-EFI....
make clean
-make -j4 gnuefi
+make -j1 gnuefi
if [[ $SignIt == 1 ]] ; then
$SBSign --key $KeysDir/refind.key --cert $KeysDir/refind.crt --output refind-bin-$1/refind/refind_x64.efi refind/refind_x64.efi
else
Summary: EFI boot manager software
Name: refind
-Version: 0.6.12
+Version: 0.7.0
Release: 1%{?dist}
Summary: EFI boot manager software
License: GPLv3
# wiping out the just-updated files.
%changelog
-* Tue Jun 18 2013 R Smith <rodsmith@rodsbooks.com> - 0.6.12
-- Created spec file for 0.6.12 release
+* Thu Jun 27 2013 R Smith <rodsmith@rodsbooks.com> - 0.7.0
+- Created spec file for 0.7.0 release
#define FS_TYPE_EXT4 4
#define FS_TYPE_HFSPLUS 5
#define FS_TYPE_REISERFS 6
-#define FS_TYPE_ISO9660 7
+#define FS_TYPE_BTRFS 7
+#define FS_TYPE_ISO9660 8
// Names of binaries that can manage MOKs....
#define MOK_NAMES L"MokManager.efi,HashTool.efi,HashTool-signed.efi"
#define REISERFS_SUPER_MAGIC_STRING "ReIsErFs"
#define REISER2FS_SUPER_MAGIC_STRING "ReIsEr2Fs"
#define REISER2FS_JR_SUPER_MAGIC_STRING "ReIsEr3Fs"
+#define BTRFS_SIGNATURE "_BHRfS_M"
// variables
case FS_TYPE_REISERFS:
retval = L" ReiserFS";
break;
+ case FS_TYPE_BTRFS:
+ retval = L" Btrfs";
+ break;
case FS_TYPE_ISO9660:
retval = L" ISO-9660";
break;
} // if
} // search for ReiserFS magic
+ if (BufferSize >= (65536 + 64 + 8)) {
+ MagicString = (char*) (Buffer + 65536 + 64);
+ if (CompareMem(MagicString, BTRFS_SIGNATURE, 8) == 0)
+ return FS_TYPE_BTRFS;
+ } // search for Btrfs magic
+
if (BufferSize >= (1024 + 2)) {
Magic16 = (UINT16*) (Buffer + 1024);
if ((*Magic16 == HFSPLUS_MAGIC1) || (*Magic16 == HFSPLUS_MAGIC2)) {
} // if (Buffer != NULL)
return FoundType;
-}
+} // UINT32 IdentifyFilesystemType()
static VOID ScanVolumeBootcode(REFIT_VOLUME *Volume, BOOLEAN *Bootable)
{
if (AboutMenu.EntryCount == 0) {
AboutMenu.TitleImage = BuiltinIcon(BUILTIN_ICON_FUNC_ABOUT);
- AddMenuInfoLine(&AboutMenu, L"rEFInd Version 0.6.12.1");
+ AddMenuInfoLine(&AboutMenu, L"rEFInd Version 0.7.0");
AddMenuInfoLine(&AboutMenu, L"");
AddMenuInfoLine(&AboutMenu, L"Copyright (c) 2006-2010 Christoph Pfisterer");
AddMenuInfoLine(&AboutMenu, L"Copyright (c) 2012-2013 Roderick W. Smith");