href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 3/19/2012; last Web page update:
-12/11/2012, referencing rEFInd 0.5.1</p>
+12/12/2012, referencing rEFInd 0.5.1</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>Configuring a Maintenance-Free Setup</h3>
</a>
-<p>The ideal configuration for use of the EFI stub loader involves giving rEFInd the ability to load your kernels directly from <tt>/boot</tt>. The main obstacle to doing so is that this directory is frequently on an XFS, JFS, Btrfs, or ext4 filesystem that the EFI can't read, or it's tucked away in an LVM or RAID configuration that the EFI can't read. 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). If you're currently booting via GRUB 2, it is likely to cease working when you try this, although GRUB should be recoverable by re-installing it. (On the other hand, GRUB will become redundant once this method of booting starts working so you might prefer to remove it completely.) You should perform the following steps as <tt>root</tt>, or precede each of these commands with <tt>sudo</tt>:</p>
+<p>The ideal configuration for use of the EFI stub loader involves giving rEFInd the ability to load your kernels directly from <tt>/boot</tt>. The main obstacle to doing so is that this directory is frequently on an XFS, JFS, Btrfs, or ext4 filesystem that the EFI can't read, or it's tucked away in an LVM or RAID configuration that the EFI can't read. 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>
determine if you can work around the need for such permissions and
ownership.</li>
-<li>Type <tt class="userinput">mv /boot/* /boot/efi</tt>. You'll see an
- error message about being unable to move <tt>/boot/efi</tt> into
+<li>Type <tt class="userinput">cp -r /boot/* /boot/efi</tt>. You'll see an
+ error message about being unable to copy <tt>/boot/efi</tt> into
itself. Ignore this.</li>
<li>Type <tt class="userinput">umount /boot/efi</tt>.</li>
</ol>
+<p>Recall that in step #4, you <i>copied</i> the contents of <tt>/boot</tt> (as a safety measure), but you did not move them. Therefore, you ended up with two copies of your kernels and other <tt>/boot</tt> directory contents, with one copy hiding the other when you mounted the ESP at <tt>/boot</tt>. Once you've booted successfully and are sure all is working well, you can recover some disk space by unmounting <tt>/boot</tt> and deleting the contents of the underlying <tt>/boot</tt> directory on your root (<tt>/</tt>) filesystem. Be sure that the <tt>/boot</tt> partition is unmounted before you do this, though! Also, be sure to leave the <tt>/boot</tt> directory itself in place, even if it has no contents; the directory is needed as a mount point for the <tt>/boot</tt> partition. Note that GRUB 2 may stop working if you delete its files from the root filesystem's <tt>/boot/grub</tt> directory, so if you want to keep GRUB around, you should re-install it with the separate <tt>/boot</tt> partition mounted.</p>
+
<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 may be desirable. 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; but if you use any of the last four filesystems (three 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, or ext3fs; but if you use any of the last four filesystems (three 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 (as Fedora 17 does by default), but if it uses ext4fs or some other unsuitable filesystem, you can back it up, create a fresh FAT, HFS+, ReiserFS, ext2, or ext3 filesystem on it, and restore the original files. 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 (as Fedora 17 does by default), but if it uses ext4fs or some other unsuitable filesystem, you can back it up, create a fresh FAT, HFS+, ReiserFS, ext2, or ext3 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>
href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 11/13/2012; last Web page update:
-12/11/2012, referencing rEFInd 0.5.1</p>
+12/12/2012, referencing rEFInd 0.5.1</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>At this point the computer may boot into its default OS, reboot, or perhaps even hang. When you reboot it, though, rEFInd should start up in Secure Boot mode. (You can verify this by selecting the <i>About rEFInd</i> tool in the main menu. Check the <i>Platform</i> item in the resulting screen; it should verify that Secure Boot is active.) You should now be able to launch any boot loader signed with a key recognized by the firmware or by shim (including any MOKs you've enrolled). If you want to manage keys in the future, rEFInd displays a new icon in the second (tools) row you can use to launch MokManager. (This icon appears by default if MokManager is installed, but if you edit <tt>showtools</tt> in <tt>refind.conf</tt>, you must be sure to include <tt>mok_tool</tt> as an option in order to gain access to it.)</p>
-<p>If you're using Ubuntu 12.10, you can't use its version of shim, but you can replace it with Garrett's shim. The problem is that Ubuntu's GRUB and kernel will then be signed by an unknown key. Unfortunately, I haven't found a suitable public key file on Ubuntu's distribution medium, so you may need to sign GRUB and/or your kernels with your own MOK. In principle, you should be able to use shim 0.2 or later from future distributions that include it; but you must be sure that whatever you use supports MokManager.</p>
+<p>If you're using Ubuntu 12.10, you can't use its version of shim, but you can replace it with Garrett's shim. If you do so, though, you'll have to add Ubuntu's public key as a MOK, at least if you intend to launch Ubuntu's version of GRUB or launch Ubuntu-provided signed kernels. Ubuntu's public key is available in the <a href="http://archive.ubuntu.com/ubuntu/pool/main/s/shim/shim_0~20120906.bcd0a4e8-0ubuntu4.debian.tar.gz">shim_0~20120906.bcd0a4e8-0ubuntu4.debian.tar.gz</a> tarball, as <tt>canonical-uefi-ca.der</tt>. (The filename extensions <tt>.cer</tt> and <tt>.der</tt> are interchangeable for most purposes.) To use it, copy <tt>canonical-uefi-ca.der</tt> to your ESP and enroll it with MokManager. See <a href="http://falstaff.agner.ch/2012/12/12/secure-boot-implementation-of-ubuntu-12-10-quantal-quetzal/">this blog post</a> for further details on Ubuntu 12.10's handling of Secure Boot. In principle, you should be able to use shim 0.2 or later from future distributions that include it; but you must be sure that whatever you use supports MokManager.</p>
<a name="mok">
<h2>Managing Your MOKs</h2>
#
# Revision history:
#
+# 0.5.1.1 -- Fixed bug that caused script failure under OS X
# 0.5.1 -- Added --shim & --localkeys options & create sample refind_linux.conf
# in /boot
# 0.5.0 -- Added --usedefault & --drivers options & changed "esp" option to "--esp"
fi
CheckForFiles
if [[ $OSName == 'Darwin' ]] ; then
- if [[ $ShimDir != "none" ]] ; then
+ if [[ $ShimSource != "none" ]] ; then
echo "The --shim option is not supported on OS X! Exiting!"
exit 1
fi
# Updated 11/8/2012 to do more things automatically
# Updated 12/6/2012 to sign binaries with the rEFInd MOK
#
-# Usage: ./mkdistrib version
+# Usage: ./mkdistrib version [--nosign]
# where "version" is a version number
# MUST be run from an x86-64 system, on which the TianoCore build
# includes both X64 and IA32 build support ("TARGET_ARCH = IA32 X64"
# partition to be mounted via /etc/fstab at /mnt/refind.
+if [[ $2 == "--nosign" ]] ; then
+ SignIt=0
+else
+ SignIt=1
+fi
+
StartDir=`pwd`
SBSign=`which sbsign 2> /dev/null`
KeysDir=/mnt/refind
KeysInfo=`df $KeysDir 2> /dev/null | grep $KeysDir`
-if [[ ! -n $SBSign ]] ; then
+if [[ ! -n $SBSign && $SignIt == 1 ]] ; then
echo "Can't find sbsign binary! Aborting!"
exit 1
fi
-if [[ ! -n $KeysInfo ]] ; then
+if [[ ! -n $KeysInfo && $SignIt == 1 ]] ; then
mount /mnt/refind
-fi
-
-if [[ $? -ne 0 ]] ; then
- echo "Error mounting $KeysDir! Aborting!"
- echo ""
- exit 1
+ if [[ $? -ne 0 ]] ; then
+ echo "Error mounting $KeysDir! Aborting!"
+ echo ""
+ exit 1
+ fi
fi
# From here on, if there's an error, abort immediately.
mkdir -p ../snapshots/$1/refind-$1/icons
cp --preserve=timestamps icons/*icns ../snapshots/$1/refind-$1/icons/
cp -a docs images include EfiLib libeg refind filesystems install.sh mkrlconf.sh CREDITS.txt NEWS.txt BUILDING.txt COPYING.txt LICENSE.txt README.txt refind.inf Make.tiano Make.common Makefile refind.conf-sample ../snapshots/$1/refind-$1
-cp $KeysDir/refind.cer $KeysDir/refind.crt ../snapshots/$1/refind-$1/
+if [[ SignIt == 1 ]] ; then
+ cp $KeysDir/refind.cer $KeysDir/refind.crt ../snapshots/$1/refind-$1/
+fi
# Go there and prepare a souce code zip file....
cd ../snapshots/$1/
make fs
mkdir -p refind-bin-$1/refind/drivers_x64
cp -a icons refind-bin-$1/refind/
-for File in `ls drivers_x64/*_x64.efi` ; do
- $SBSign --key $KeysDir/refind.key --cert $KeysDir/refind.crt --output refind-bin-$1/refind/$File $File
-done
+if [[ $SignIt == 1 ]] ; then
+ for File in `ls drivers_x64/*_x64.efi` ; do
+ $SBSign --key $KeysDir/refind.key --cert $KeysDir/refind.crt --output refind-bin-$1/refind/$File $File
+ done
+else
+ cp --preserve=timestamps drivers_x64/*_x64.efi refind-bin-$1/refind/drivers_x64/
+fi
cp --preserve=timestamps filesystems/LICENSE*txt refind-bin-$1/refind/drivers_x64/
cp --preserve=timestamps refind.conf-sample refind-bin-$1/refind/
-$SBSign --key $KeysDir/refind.key --cert $KeysDir/refind.crt --output refind-bin-$1/refind/refind_x64.efi refind/refind_x64.efi
+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
+ cp refind/refind_x64.efi refind-bin-$1/refind/refind_x64.efi
+fi
cp refind-bin-$1/refind/refind_x64.efi $StartDir
cp -a COPYING.txt LICENSE.txt README.txt docs CREDITS.txt install.sh mkrlconf.sh refind-bin-$1
# Prepare the final .zip file and clean up
-cp $KeysDir/refind.cer $KeysDir/refind.crt refind-bin-$1/
+if [[ $SignIt == 1 ]] ; then
+ cp $KeysDir/refind.cer $KeysDir/refind.crt refind-bin-$1/
+ umount $KeysDir
+fi
zip -9r ../refind-bin-$1.zip refind-bin-$1
cd ..
rm -r refind-$1
cd $StartDir
-umount $KeysDir
\ No newline at end of file
if (AboutMenu.EntryCount == 0) {
AboutMenu.TitleImage = BuiltinIcon(BUILTIN_ICON_FUNC_ABOUT);
- AddMenuInfoLine(&AboutMenu, L"rEFInd Version 0.5.1");
+ AddMenuInfoLine(&AboutMenu, L"rEFInd Version 0.5.1.1");
AddMenuInfoLine(&AboutMenu, L"");
AddMenuInfoLine(&AboutMenu, L"Copyright (c) 2006-2010 Christoph Pfisterer");
AddMenuInfoLine(&AboutMenu, L"Copyright (c) 2012 Roderick W. Smith");