From 65b6176beb6171976d044fc17cc7ab6f98e458a1 Mon Sep 17 00:00:00 2001
From: srs5694
Originally written: 3/19/2012; last Web page update: -12/11/2012, referencing rEFInd 0.5.1
+12/12/2012, referencing rEFInd 0.5.1I'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!
@@ -152,7 +152,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.comThe ideal configuration for use of the EFI stub loader involves giving rEFInd the ability to load your kernels directly from /boot. 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 root, or precede each of these commands with sudo:
+The ideal configuration for use of the EFI stub loader involves giving rEFInd the ability to load your kernels directly from /boot. 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 root, or precede each of these commands with sudo:
Recall that in step #4, you copied the contents of /boot (as a safety measure), but you did not move them. Therefore, you ended up with two copies of your kernels and other /boot directory contents, with one copy hiding the other when you mounted the ESP at /boot. Once you've booted successfully and are sure all is working well, you can recover some disk space by unmounting /boot and deleting the contents of the underlying /boot directory on your root (/) filesystem. Be sure that the /boot partition is unmounted before you do this, though! Also, be sure to leave the /boot directory itself in place, even if it has no contents; the directory is needed as a mount point for the /boot partition. Note that GRUB 2 may stop working if you delete its files from the root filesystem's /boot/grub directory, so if you want to keep GRUB around, you should re-install it with the separate /boot partition mounted.
+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.
-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 /boot 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 /boot partition at a temporary location, copy or move the current /boot files into it, unmount it, and add it to /etc/fstab as /boot.
+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 /boot 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 /boot partition at a temporary location, copy or move the current /boot files into it, unmount it, and add it to /etc/fstab as /boot.
-If your distribution already uses a separate /boot 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 /boot partition, you'll probably want to continue mounting the ESP at /boot/efi.
+If your distribution already uses a separate /boot 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 /etc/fstab to ensure that the computer mounts the new filesystem when you boot. If you use a separate non-ESP /boot partition, you'll probably want to continue mounting the ESP at /boot/efi.
Originally written: 11/13/2012; last Web page update: -12/11/2012, referencing rEFInd 0.5.1
+12/12/2012, referencing rEFInd 0.5.1I'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!
@@ -232,7 +232,7 @@ described on this page currently supports only x86-64, notAt 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 About rEFInd tool in the main menu. Check the Platform 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 showtools in refind.conf, you must be sure to include mok_tool as an option in order to gain access to it.)
-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.
+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 shim_0~20120906.bcd0a4e8-0ubuntu4.debian.tar.gz tarball, as canonical-uefi-ca.der. (The filename extensions .cer and .der are interchangeable for most purposes.) To use it, copy canonical-uefi-ca.der to your ESP and enroll it with MokManager. See this blog post 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.