X-Git-Url: https://code.delx.au/refind/blobdiff_plain/4f05f12b4a34cfbef8deb341168a212edb225ad4..2a6ed1155086a30aaa01ced44b559183e7521083:/docs/refind/installing.html diff --git a/docs/refind/installing.html b/docs/refind/installing.html index d3b5424..d22af01 100644 --- a/docs/refind/installing.html +++ b/docs/refind/installing.html @@ -15,10 +15,10 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

Originally written: 3/14/2012; last Web page update: -5/5/2013, referencing rEFInd 0.6.10

+5/15/2014, referencing rEFInd 0.8.1

-

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!

+

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!

@@ -168,6 +168,8 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

  • Installing rEFInd Manually Using an EFI Shell
    • +
  • Using OS X Whole-Disk Encryption
    • +
  • Alternative Naming Options
    • + + + + @@ -380,8 +390,8 @@ install.sh [--esp | --usedefault device-file | --root - - + + @@ -431,7 +441,7 @@ Filesystem 1K-blocks Used Available Use% Mounted on
  • Rename the configuration file by typing mv refind.conf-sample refind.conf. Consult the Editing the rEFInd Configuration File page for information on how to adjust your options.
    • -

    Weird: A bug exists in some Lenovo computers (and perhaps in some others, too) that causes the firmware's boot manager to refuse to boot any boot loader that doesn't have the name Windows Boot Manager or Red Hat Enterprise Linux. If you have such a system, you must pass one of those names (in quotes) rather than rEFInd to efibootmgr via its -L option. This bug was reported to Lenovo in mid-November 2012, so with any luck updated firmware without this bug will be available later this year or early in 2013. I can make no promises about this, though.

    +

    Weird: A bug exists in some Lenovo computers (and perhaps in some others, too) that causes the firmware's boot manager to refuse to boot any boot loader that doesn't have the name Windows Boot Manager or Red Hat Enterprise Linux. If you have such a system, you must pass one of those names (in quotes) rather than rEFInd to efibootmgr via its -L option. This bug was reported to Lenovo in mid-November 2012, and by late 2013, at least some Lenovos were mercifully free of this bug.

  • On a UEFI-based system, type efibootmgr -c -l \\EFI\\refind\\refind_x64.efi -L rEFInd 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 also need to include additional options if your ESP isn't on /dev/sda1 or if your configuration is otherwise unusual; consult the efibootmgr man page for details. You may need to install this program on some systems; it's a standard part of most distributions' repositories. Also, if you're installing in Secure Boot mode, you must normally register shim.efi rather than the rEFInd binary, and rename refind_x64.efi to grubx64.efi.
    • @@ -592,6 +602,8 @@ $ ioreg -l -p IODeviceTree | grep firmware-abi

    Installing rEFInd Manually Using an EFI Shell

     +

    Warning: Do not attempt to use the procedure described in this section on a Macintosh. Macs have a strange EFI implementation that does not use the EFI variables that this procedure manipulates. Therefore, chances are this procedure simply won't work. It's conceivable that this procedure will actually cause problems, but I'm not curious enough to try it and risk damaging my Mac!

    +

    If you can't currently boot any OS (say, because a firmware update has wiped your NVRAM entries), you may find it convenient to install rEFInd using an EFI version 2 shell. Unfortunately, the bcfg command described here is not available in the EFI version 1 shell, and the version 2 shell is unusable on many firmware implementations prior to 2.3.1. Thus, this procedure won't work for all systems.

    In addition to emergency situations, using bcfg can be desirable if efibootmgr or other OS-hosted tools don't do the job. This happens under VirtualBox, for instance. An alternative in such cases can be to use alternative names for rEFInd.

    @@ -604,9 +616,11 @@ $ ioreg -l -p IODeviceTree | grep firmware-abi
  • x86 (32-bit) shell 2
    • +
  • Alternate x86-64 (64-bit) shell 2 for older EFIs
    • + -

    Note that the shell included in rEFInd's CD-R image version is a version 1 shell, so you can't use it for this purpose. You can, however, copy rEFInd's files from the CD-R. You can even launch the version 1 shell included with rEFInd and then use that to launch a version 2 shell. Once you've booted the shell, you can proceed as follows:

    +

    Note that the IA32 shell included in rEFInd's CD-R image version is a version 1 shell, so you can't use it for this purpose. You can, however, copy rEFInd's files from the CD-R. You can even launch the version 1 shell included with rEFInd and then use that to launch a version 2 shell. The x86-64 shell on the CD-R is the alternate shell, which should work on any x86-64 computer. Once you've booted the shell, you can proceed as follows:

      @@ -689,6 +703,20 @@ $ ioreg -l -p IODeviceTree | grep firmware-abi

      With any luck, rEFInd will start up at this point. If not, you can check your settings using a shell or an emergency system for your OS of choice. In an EFI shell, you might type bcfg boot dump -b to view your boot loader entries and verify that rEFInd appears at the top of the list. Be sure to check the pathname for typos. If you continue to have problems, you might look into giving rEFInd a fallback filename that your firmware will recognize.

      + +

      Using OS X Whole-Disk Encryption

      +       + +

      If you're using OS X's Whole-Disk Encryption (WDE) feature, you must do two extra things:

      + + +

      Alternative Naming Options

       @@ -832,7 +860,7 @@ $ ioreg -l -p IODeviceTree | grep firmware-abi
    1. shell.efi—This - file, placed in the ESP's efi/tools directory, adds the + file, placed in the ESP's EFI/tools directory, adds the ability to launch a text-mode EFI shell from rEFInd. Note that the download link is to a 64-bit binary that must be renamed before rEFInd will recognize it. Additional shell download links appear on the ioreg -l -p IODeviceTree | grep firmware-abi Linux wiki, and on other sites; try a Web search if the shell you find doesn't work to your satisfaction.
      2. +
    2. Memtest86—This + is a popular tool for performing basic hardware tests, and especially + memory tests. rEFInd recognizes this program when it is stored in the + EFI/tools, EFI/tools/memtest, + EFI/tools/memtest86, EFI/memtest, or + EFI/memtest86 directory, with a program filename of + memtest86.efi, memtest86_x64.efi, + memtest86x64.efi, or bootx64.efi. (Change + x64 to ia32 on IA-32 systems.) Be sure to download + the EFI version of the program. If you get the USB flash drive version, + you should mount the flash drive's ESP (partition 2) and copy the + EFI/BOOT directory to your own ESP's + EFI/tools/memtest or other Memtest86 directory name, as just + specified. rEFInd should then recognize it, provided the + showtools line includes the memtest or + memtest86 token.
      3. +
    3. gptsync.efi or gptsync_arch.efi—This program creates a hybrid MBR from @@ -900,13 +946,17 @@ $ ioreg -l -p IODeviceTree | grep firmware-abi

      Most of the reports of sluggish Macintosh boots I've seen note that the user installed rEFInd to the ESP rather than to the OS X root partition. Some users have reported that re-installing rEFInd to the OS X root partition clears up the problem. This is obviously a straightforward solution to the problem, if it works. Note that rEFInd can launch boot loaders that are stored on any partition that the EFI can read no matter where it's installed; therefore, you'll still be able to launch boot loaders stored on the ESP (or elsewhere) if you install it in this way.

      -

      The biggest drawback to this approach is that you won't be able to edit the rEFInd configuration file or move rEFInd-related binaries from an EFI shell if you install it in this way, since Apple's HFS+ driver for EFI is read-only. (The same is true of rEFInd's HFS+ driver, so it won't help you overcome this limitation.) You may also be limited in making changes to your rEFInd configuration from Linux or other OSes, too, since Linux's HFS+ drivers disable write support by default on volumes with an active journal. You can force write access by using the force option to mount; however, this procedure is noted as being risky in the Linux HFS+ documentation, so I don't recommend doing this on a regular basis. As a compromise, you might try creating a small non-journaled HFS+ volume that's dedicated to holding rEFInd. You could even mount it as the Linux /boot partition, in which case it would also hold the Linux kernel and related files. You'll need to install rEFInd manually if you try this.

      +

      A variant of this solution is to create a small (~100MiB) HFS+ volume to be used exclusively by rEFInd. You can then install rEFInd to that volume with the --ownhfs option to install.sh, as in ./install.sh --ownhfs /dev/disk0s6 if the volume is /dev/disk0s6. This approach has the advantage that it can be managed via OS X's own Startup Disk tool in System Preferences.

      + +

      The biggest drawback to storing rEFInd on an HFS+ volume is that you won't be able to edit the rEFInd configuration file or move rEFInd-related binaries from an EFI shell if you install it in this way, since Apple's HFS+ driver for EFI is read-only. (The same is true of rEFInd's HFS+ driver, so it won't help you overcome this limitation.) You may also be limited in making changes to your rEFInd configuration from Linux or other OSes, too, since Linux's HFS+ drivers disable write support by default on volumes with an active journal. You can force write access by using the force option to mount; however, this procedure is noted as being risky in the Linux HFS+ documentation, so I don't recommend doing this on a regular basis on the OS X boot volume. This isn't as risky if you use a dedicated HFS+ rEFInd partition, though. You could even mount it as the Linux /boot partition, in which case it would also hold the Linux kernel and related files. If you use disk encryption, you can't store rEFInd on the OS X root (/) partition, but you could still use an (unencrypted) separate HFS+ partition.

      + +

      A variant of this solution is suggested in this blog post, which recommends placing rEFInd on an HFS+ volume on the first SATA channel. (In the blogger's case, that channel used to hold an optical drive, but that drive was replaced by a hard disk.)

      Using the Fallback Filename

       -

      I've received one report that installing rEFInd to the ESP using the fallback filename (EFI/BOOT/bootx64.efi on most systems, or EFI/BOOT/bootia32.efi on very old Macs) can work around the problem.

      +

      I've received a few reports that installing rEFInd to the ESP using the fallback filename (EFI/BOOT/bootx64.efi on most systems, or EFI/BOOT/bootia32.efi on very old Macs) can work around the problem.

      Clearing the NVRAM Entries

      @@ -973,7 +1023,7 @@ Boot0007* CD/DVD Drive
      -

      copyright © 2012–2013 by Roderick W. Smith

      +

      copyright © 2012–2014 by Roderick W. Smith

      This document is licensed under the terms of the GNU Free Documentation License (FDL), version 1.3.

    --usedefault device-file You can install rEFInd to a disk using the default/fallback filename of EFI/BOOT/bootx64.efi (and EFI/BOOT/bootia32.efi, if the 32-bit build is available) using this option. The device-file should be an unmounted ESP, or at least a FAT partition, as in --usedefault /dev/sdc1. Your computer's NVRAM entries will not be modified when installing in this way. The intent is that you can create a bootable USB flash drive or install rEFInd on a computer that tends to "forget" its NVRAM settings with this option. This option is mutually exclusive with --esp and --root (except for implicit use of --esp on Linux).
    --ownhfs device-fileThis option should be used only under OS X. It's used to install rEFInd to an HFS+ volume other than a standard Mac boot volume. The result should be that rEFInd will show up in the Mac's own boot manager. More importantly, suspend-to-RAM operations may work correctly. Note that this option requires an HFS+ volume that is not currently an OS X boot volume. This can be a data volume or a dedicated rEFInd partition. The ESP might also work, if it's converted to use HFS+.
    --root /mount-point This option is intended to help install rEFInd from a "live CD" or other emergency system. To use it, you should mount your regular installation at /mount-point, including your /boot directory (if it's separate) at /mount-point/boot and (on Linux) your ESP at that location or at /mount-point/boot/efi. The install.sh script then installs rEFInd to the appropriate location—on Linux, /mount-point/boot/EFI/refind or /mount-point/boot/efi/EFI/refind, depending on where you've mounted your ESP; or on OS X, to /mount-point/EFI/refind. The script also adds an entry to your NVRAM for rEFInd at this location. You cannot use this option with either --esp or --usedefault, except for implicit use of --esp on Linux. Note that this option is not needed when doing a dual-boot Linux/OS X installation; just install normally in OS X.When you specify this option, install.sh copies all the driver files for your architecture. You may want to remove unused driver files after you use this option, especially if your computer uses Secure Boot.
    --shim shim-filenameIf you pass this option to install.sh, the script will copy the specified shim program file to the target directory, copy the MokManager.efi file from the shim program file's directory to the target directory, copy the 64-bit version of rEFInd as grubx64.efi, and register shim with the firmware. (If you also specify --usedefault, the NVRAM registration is skipped.) The intent is to simplify rEFInd installation on a computer that uses Secure Boot; when so set up, rEFInd will boot in Secure Boot mode, with one caveat: The first time you boot, MokManager will launch, and you must use it to locate and install a public key. This key file will be located in the rEFInd directory's keys subdirectory under the name refind.cer. Note that I'm not providing a shim binary myself, but you can download one from here. In the not-too-distant future, most distributions will provide their own shim programs, so you'll be able to point to them—for instance, in /boot/efi/EFI/fedora/shim.efi.--shim shim-filename or --preloader preloader-filenameIf you pass this option to install.sh, the script will copy the specified shim program file to the target directory, copy the MokManager.efi file from the shim program file's directory to the target directory, copy the 64-bit version of rEFInd as grubx64.efi, and register shim with the firmware. (If you also specify --usedefault, the NVRAM registration is skipped.) When the target file is identified as PreLoader, much the same thing happens, but install.sh copies HashTool.efi instead of MokManager.efi and copies rEFInd as loader.efi rather than as grubx64.efi. The intent is to simplify rEFInd installation on a computer that uses Secure Boot; when so set up, rEFInd will boot in Secure Boot mode, with one caveat: The first time you boot, MokManager/HashTool will launch, and you must use it to locate and install a public key or register rEFInd as a trusted application. The rEFInd public key file will be located in the rEFInd directory's keys subdirectory under the name refind.cer. Note that I'm not providing a shim binary myself, but you can download one from here. Some distributions also provide their own shim programs, so can point to them—for instance, in /boot/efi/EFI/fedora/shim.efi.
    --localkeys