From: Stefan Agner Date: Thu, 20 Dec 2012 18:39:07 +0000 (+0100) Subject: Merge branch 'master' of git://git.code.sf.net/p/refind/code X-Git-Url: https://code.delx.au/refind/commitdiff_plain/d2370de648f795ccdf7fe76786c9516568cbe529?hp=04c467b8a01b0780621d63dafb9ac898a62cf824 Merge branch 'master' of git://git.code.sf.net/p/refind/code --- diff --git a/BUILDING.txt b/BUILDING.txt index e5501c2..b69df9b 100644 --- a/BUILDING.txt +++ b/BUILDING.txt @@ -310,7 +310,8 @@ To build all the drivers, you can type "make fs" from the main directory, which builds the drivers and places copies in both the filesystems and drivers_{arch} subdirectories. If you want to build just one driver, you can change into the "filesystems" directory and type "make {fsname}", where -{fsname} is a filesystem name -- "ext2", "reiserfs", "iso9660", or "hfs". +{fsname} is a filesystem name -- "ext2", "ext4", "reiserfs", "iso9660", +or "hfs". To install drivers, you can type "make install" in the "filesystems" directory. This copies all the drivers to the diff --git a/CREDITS.txt b/CREDITS.txt index d8efcde..469d663 100644 --- a/CREDITS.txt +++ b/CREDITS.txt @@ -52,3 +52,6 @@ I've incorporated into the current version. Specifically: * The code for editing boot options (cursor_left(), cursor_right(), and line_edit() in screen.c) is taken from gummiboot. + +* Stefan Agner (stefan@agner.ch) turned the original ext2fs/ext3fs driver + into one that can read ext4fs. diff --git a/NEWS.txt b/NEWS.txt index c927700..e249ef8 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -1,6 +1,118 @@ -0.5.1 (??/??/201?): +0.6.1 (12/??/2012): ------------------- +- Added the "words" that make up a filesystem's label (delimited by spaces, + dashes, or underscores) to the list of bases used to search for OS icons. + For instance, if the filesystem's label is "Arch", rEFInd searches for + os_Arch.icns; if it's "Fedora 17", it searches for os_Fedora.icns and + os_17.icns; and if it's "NEW_GENTOO", it searches for os_NEW.icns and + os_GENTOO.icns. + +- Refined hints displays to be more context-sensitive, particularly in text + mode. + +- Instead of displaying a blank filesystem label when a filesystem has + none, rEFInd now displays the size and/or type of the filesystem, as in + "boot EFI\foo\bar.efi from 200 MiB ext3 volume" rather than "boot + EFI\foo\bar.efi from". + +- Fixed a bug that caused the screen to clear after displaying an error + message but before displaying the "Hit any key to continue" message when + a boot loader launch failed. + +0.6.0 (12/16/2012): +------------------- + +- Fixed a memory allocation bug that could cause a program crash when + specifying certain values with the "also_scan_dirs", "dont_scan_volumes", + "dont_scan_dirs", "dont_scan_files", and "scan_driver_dirs" refind.conf + options. + +- Modified Linux kernel initrd-finding code so that if an initrd is + specified in refind_linux.conf, rEFInd will not add any initrd it finds. + This enables an override of the default initrd, and is likely to be + particularly helpful to Arch Linux users. + +- Added ext4fs driver! + +- Made "boot" the default value for "also_scan_dirs". + +- Added identifying screen header to line editor. + +- Fixed bug that caused rEFInd's display to be mis-sized upon return + from a program that set the resolution itself. + +- Adjusted "resolution" refind.conf parameter so that it can accept EITHER + a resolution as width and height OR a single digit as a UEFI mode number + (which is system-specific). This is done because some systems present the + same mode twice in their mode lists, perhaps varying in refresh rate, + monitor output, or some other salient characteristics; specifying the + mode number enables selecting the higher-numbered mode, whereas using + horizontal and vertical resolution values selects the lowest-numbered + mode. + +- Added "textmode" refind.conf parameter to set the text mode used in + text-only displays, and for the line editor and boot-time handoff + display even in graphics mode. + +- Fixed bug that caused tools (shell, etc.) to launch when they were + highlighted and F2 or Insert was pressed. + +- Added "editor" option to the "hideui" token in refind.conf, which + disables the boot options editor. + +- Added hints text to rEFInd main menu and sub-menus. This can be disabled + by setting the new "hints" option to the "hideui" token in refind.conf. + +- Added "boot with minimal options" entry to refind_linux.conf file + generated by install.sh. This entry boots without the options extracted + from the /etc/default/grub file. + +- Added keys subdirectory to main distribution, to hold public Secure + Boot/shim keys from known sources. + +- Changed install.sh --drivers option to --alldrivers, added new + --nodrivers option, and made the default on Linux to install the one + driver that's used on /boot (or the root filesystem if /boot isn't a + separate partition). Of course, this won't install a non-existent driver, + and it also won't work properly if run from an emergency disk unless you + mount a separate /boot partition at that location. + +- Fixed bug in install.sh that prevented creation of refind_linux.conf file + on Linux systems. + +0.5.1.1 (12/12/2012): +--------------------- + +- Fixed bug in install.sh that prevented it from working on OS X. + +0.5.1 (12/11/2012): +------------------- + +- Added support for "0" options to "textonly" and "scan_all_linux_kernels" + to reverse the usual meaning of these tokens. This is useful for + including these options in a secondary configuration file called with the + new "include" token to override a setting set in the main file. + +- Added "include" token for refind.conf, to enable including a secondary + configuration file from a primary one. + +- Modified install.sh so that it creates a simple refind_linux.conf file in + /boot, if that file doesn't already exist and if install.sh is run from + Linux. If that directory happens to be on a FAT, HFS+, ext2fs, ext3fs, or + ReiserFS volume, and if the necessary drivers are installed, the result + is that rEFInd will detect the Linux installation with no further + configuration on many systems. (Some may still require tweaking of kernel + options, though; for instance, adding "dolvm" on Gentoo systems that use + LVM.) + +- Added --shim and --localkeys options to install.sh to help simplify setup + on systems with Secure Boot active. + +- Fixed (maybe) bug that caused resolution options to not be displayed on + recent Macs with GOP graphics when specifying an invalid resolution in + refind.conf. + - Fixed bug that caused some programs (EFI shells, in particular) to hang when launching on some systems (DUET, in particular). diff --git a/docs/refind/bootmode.html b/docs/refind/bootmode.html index 15e5218..07fb6ea 100644 --- a/docs/refind/bootmode.html +++ b/docs/refind/bootmode.html @@ -15,7 +15,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

Originally written: 3/14/2012; last Web page update: -12/6/2012, referencing rEFInd 0.5.0

+12/16/2012, referencing rEFInd 0.6.0

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!

@@ -108,7 +108,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

A casual reader might easily overlook this option, or misinterpret it to mean that the feature is much less important than it is. In fact, this particular motherboard offers very poor control over its EFI vs. BIOS booting features. (See my Web page on this EFI implementation for details.)

-

Some manuals omit even mention of EFI, and instead refer to "legacy boot" or some similar term, referring to BIOS-style booting. Such references may imply that the firmware supports EFI booting if the "legacy boot" mode is disabled or restricted in some way.

+

Some manuals omit even mention of EFI, and instead refer to "legacy boot" or some similar term, referring to BIOS-style booting. The firmware for my ASUS P8H77-I motherboard uses the technical term CSM, which of course will be baffling to the uninitiated. (I referred to it earlier. It's the Compatibility Support Module—in other words, the BIOS support code.) Such references may imply that the firmware supports EFI booting if the "legacy boot" mode is disabled or restricted in some way.

Understated EFI features often indicate a slapdash approach to EFI. Such systems sometimes implement EFI as a layer atop a conventional BIOS. More modern EFIs, though, completely replace the BIOS. Some manufacturers, such as ASUS and its sibling ASRock, are now actively promoting their more advanced EFI implementations. Such products often come with flashy new GUIs in their firmware.

diff --git a/docs/refind/configfile.html b/docs/refind/configfile.html index dcf1fe1..2f33216 100644 --- a/docs/refind/configfile.html +++ b/docs/refind/configfile.html @@ -15,7 +15,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

Originally written: 3/14/2012; last Web page update: -12/6/2012, referencing rEFInd 0.5.0

+12/16/2012, referencing rEFInd 0.6.0

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!

@@ -104,21 +104,25 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

Another way to hide a boot loader is to move it into rEFInd's own directory. In order to keep rEFInd from showing up in its own menu, it ignores boot loaders in its own directory. This obviously includes the rEFInd binary file itself, but also anything else you might store there.

-

In addition to hiding boot loaders, you can adjust their icons. You can do this in any of three ways for auto-detected boot loaders:

+

In addition to hiding boot loaders, you can adjust their icons. You can do this in any of five ways for auto-detected boot loaders:

-

As a special case, rEFInd assigns icons to the Windows and OS X boot loaders based on their conventional locations, so they get suitable icons even though they don't follow these rules.

+

As a special case, rEFInd assigns icons to the Windows and OS X boot loaders based on their conventional locations, so they get suitable icons even if they don't follow these rules.

-

In addition to the main OS tag icon, you can set the badge icon for a volume by creating a file called .VolumeBadge.icns in the root directory of a partition. This icon file must include a 32x32 bitmap. If present, it replaces the disk-type icons that are overlaid on the main OS icon. If you use this feature, the badge is applied to all the boot loaders read from the disk, not just those stored in the root directory or the Apple boot loader location. You could use this feature to set a custom badge for different specific disks or to help differentiate multiple OS X installations on one computer.

+

In addition to the main OS tag icon, you can set the badge icon for a volume by creating a file called .VolumeBadge.icns in the root directory of a partition. This icon file must include a 32x32 bitmap. If present, it replaces the disk-type icons that are overlaid on the main OS icon. If you use this feature, the badge is applied to all the boot loaders read from the disk, not just those stored in the root directory or the Apple boot loader location. You could use this feature to set a custom badge for different specific disks or to help differentiate multiple OS X installations on one computer. If you don't want any badges, you can replace the three badge icons in the rEFInd icons subdirectory (vol_external.icns, vol_internal.icns, and vol_optical.icns) with a completely transparent badge. The transparent.icns file in the rEFInd icons directory may be used for this purpose.

Adjusting the Global Configuration

@@ -145,8 +149,8 @@ timeout 20 hideui - banner, label, singleuser, hwtest, arrows, or all - Removes the specified user interface features. banner removes the banner graphic, label removes the text description of each tag and the countdown timer, singleuser removes the single-user option from the Mac OS sub-menu, hwtest removes the Mac OS hardware test option, arrows removes the arrows to the right or left of the OS tags when rEFInd finds too many OSes to display simultaneously, and all removes all of these options. You can specify multiple parameters with this option. The default is to set none of these values. + banner, label, singleuser, hwtest, arrows, hints, editor, or all + Removes the specified user interface features. banner removes the banner graphic, label removes the text description of each tag and the countdown timer, singleuser removes the single-user option from the Mac OS sub-menu, hwtest removes the Mac OS hardware test option, arrows removes the arrows to the right or left of the OS tags when rEFInd finds too many OSes to display simultaneously, hints removes the brief description of what basic keypressed do, editor disables the options editor, and all removes all of these options. You can specify multiple parameters with this option. The default is to set none of these values. icons_dir @@ -175,13 +179,18 @@ timeout 20 textonly - None - rEFInd defaults to a graphical mode; however, if you prefer to do without the flashy graphics, you can run it in text mode by including this option. + None or 0 + rEFInd defaults to a graphical mode; however, if you prefer to do without the flashy graphics, you can run it in text mode by including this option. Passing any option but 0 causes text mode to be used; passing a 0 causes graphics mode to be used. (This could be useful if you want to override a text-mode setting in an included secondary configuration file.) + + + textmode + text mode number + Sets the text-mode video resolution to be used in conjunction with textonly or for the line editor and program-launch screens. This option takes a single-digit code. Mode 0 is guaranteed to be present and should be 80x25. Mode 1 is supposed to be either invalid or 80x50, but some systems use this number for something else. Higher values are system-specific. If you set this option to an invalid value, rEFInd pauses during startup to tell you of that fact. Note that on some computers, setting this value without also using textonly results in an incorrect graphics video mode being set. Pressing the Esc key corrects the problem. resolution - Two integer values - Sets the video resolution used by rEFInd; takes a width and a height as options. For instance, resolution 1024 768 sets the resolution to 1024x768. If you set a resolution that doesn't work on a UEFI-based system, rEFInd displays a message along with a list of valid modes. On an system built around EFI 1.x (such as a Mac), setting an incorrect resolution fails silently; you'll get the system's default resolution. You'll also get the system's default resolution if you set either resolution value to 0 or if you pass anything but two numbers. (Note that passing a resolution with an x, as in 1024x768, will be interpreted as one option and so will cause the default resolution to be used.) Also, be aware that it is possible to set a valid resolution for your video card that's invalid for your monitor. If you do this, your monitor will go blank until you've booted an OS that resets the video mode. + one or two integer values + Sets the video resolution used by rEFInd; takes either a width and a height or a single UEFI video mode number as options. For instance, resolution 1024 768 sets the resolution to 1024x768. On UEFI systems, resolution 1 sets video mode 1, the resolution of which varies from system to system. If you set a resolution that doesn't work on a UEFI-based system, rEFInd displays a message along with a list of valid modes. On an system built around EFI 1.x (such as a Mac), setting an incorrect resolution fails silently; you'll get the system's default resolution. You'll also get the system's default resolution if you set both resolution values to 0 or if you pass anything but two numbers. (Note that passing a resolution with an x, as in 1024x768, will be interpreted as one option and so will cause the default resolution to be used.) Also, be aware that it is possible to set a valid resolution for your video card that's invalid for your monitor. If you do this, your monitor will go blank until you've booted an OS that resets the video mode. use_graphics_for @@ -200,13 +209,18 @@ timeout 20 scan_delay - Numeric (integer) value + numeric (integer) value Imposes a delay before rEFInd scans for disk devices. Ordinarily this is not necessary, but on some systems, some disks (particularly external drives and optical discs) can take a few seconds to become available. If some of your disks don't appear when rEFInd starts but they do appear when you press the Esc key to re-scan, try uncommenting this option and setting it to a modest value, such as 2, 5, or even 10. The default is 0. also_scan_dirs directory path(s) - Adds the specified directory or directories to the directory list that rEFInd scans for EFI boot loaders when scanfor includes the internal, external, or optical options. Directories are specified relative to the filesystem's root directory. If this option is used, it's applied to all the filesystems that rEFInd scans. If a specified directory doesn't exist, rEFInd ignores it (no error results). + Adds the specified directory or directories to the directory list that rEFInd scans for EFI boot loaders when scanfor includes the internal, external, or optical options. Directories are specified relative to the filesystem's root directory. If this option is used, it's applied to all the filesystems that rEFInd scans. If a specified directory doesn't exist, rEFInd ignores it (no error results). The default value is boot, which is useful for locating Linux kernels when you have an EFI driver for your Linux root (/) filesystem. + + + dont_scan_volumes or don't_scan_volumes + filesystem label(s) + Adds the specified volume or volumes to a volume "blacklist"—these filesystems are not scanned for EFI boot loaders. This may be useful to keep unwanted EFI boot entries, such as for a Macintosh recovery partition, from appearing on the main list of boot loaders. dont_scan_dirs or don't_scan_dirs @@ -220,14 +234,19 @@ timeout 20 scan_all_linux_kernels - None - When set, causes rEFInd to add Linux kernels (files with names that begin with vmlinuz or bzImage) to the list of EFI boot loaders, even if they lack .efi filename extensions. The hope is that this will simplify use of rEFInd on distributions that provide kernels with EFI stub loader support but that don't give those kernels names that end in .efi. Of course, the kernels must still be stored on a filesystem that rEFInd can read, and in a directory that it scans. (Drivers and the also_scan_dirs options can help with those issues.) Note that this option can cause unwanted files to be improperly detected and given loader tags, such as older kernels without EFI stub loader support. Versions of rEFInd prior to 0.5.0 left this option commented out in the refind.conf-sample file, but as of version 0.5.0, this option is enabled in the default configuration file. The program default remains to not scan for such kernels, though, so you can delete or uncomment this option to keep them from appearing in your boot menu. + None or 0 + When set, causes rEFInd to add Linux kernels (files with names that begin with vmlinuz or bzImage) to the list of EFI boot loaders, even if they lack .efi filename extensions. The hope is that this will simplify use of rEFInd on distributions that provide kernels with EFI stub loader support but that don't give those kernels names that end in .efi. Of course, the kernels must still be stored on a filesystem that rEFInd can read, and in a directory that it scans. (Drivers and the also_scan_dirs options can help with those issues.) Note that this option can cause unwanted files to be improperly detected and given loader tags, such as older kernels without EFI stub loader support. Versions of rEFInd prior to 0.5.0 left this option commented out in the refind.conf-sample file, but as of version 0.5.0, this option is enabled in the default configuration file. The program default remains to not scan for such kernels, though, so you can delete or uncomment this option to keep them from appearing in your boot menu. Passing any option but 0 causes scans for all kernels to occur; passing a 0 causes these kernels to not be scanned. (This could be useful if you want to override a setting of scan_all_linux_kernels in an included secondary configuration file.) default_selection A substring of a boot loader's title; or a numeric position Sets the default boot OS based on the loader's title, which appears in the main menu beneath the icons when you select the loader. You can enter any substring of the title as the default_selection, so long as it's two or more characters in length. It's best to use a unique substring, since rEFInd stops searching when it finds the first match. Because rEFInd sorts entries within a directory in descending order by file modification time, if you specify a directory (or volume name, for loaders in a partition's root directory) as the default_selection, the most recent loader in that directory will be the default. One-character entries are matched against the first character of the title, except for digits, which refer to the numeric order of the boot loader entries. + + include + filename + Includes the specified file into the current configuration file. Essentially, the included file replaces the include line, so positioning of this token is important if the included file includes options that contradict those in the main file. The included file must reside in the same directory as the rEFInd binary and the main configuration file. This option is valid only in the main configuration file; included files may not include third-tier configuration files. +

Prior to version 0.2.4, rEFInd supported a token called disable, whose function partially overlapped with hideui. Version 0.2.4 merges many of the features of these two tokens into hideui and creates the new showtools option, which provides the remaining functionality in a more flexible way.

diff --git a/docs/refind/drivers.html b/docs/refind/drivers.html index fb5852f..a881ff2 100644 --- a/docs/refind/drivers.html +++ b/docs/refind/drivers.html @@ -15,7 +15,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

Originally written: 4/19/2012; last Web page update: -12/6/2012, referencing rEFInd 0.5.0

+12/16/2012, referencing rEFInd 0.6.0

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!

@@ -136,6 +136,21 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

used in the same way as the ReiserFS driver. Although it's called an "ext2fs" driver, it also works with ext3fs. +
  • Ext4fs—Stefan Agner modified the rEFIt/rEFInd ext2fs + driver so that it could handle ext4fs. I'm including this as a separate + driver from the ext2fs driver, although the ext4fs version can handle + ext2fs and ext3fs, too. (I may eventually retire the original ext2fs + driver, but I want to be conservative about this in case there's an + undiscovered problem with the new driver.) This driver has some + limitations. Most notably, for various reasons it maxes out at 16TiB + and won't mount any ext4 filesystem that's larger than this. It also + doesn't support the meta_bg option flag; if your filesystem + uses this flag, this driver refuses to read it. You can learn about + your ext2/3/4 filesystem features by typing dumpe2fs /dev/sda2 | grep features, + changing /dev/sda2 to your + filesystem's device.
    • +
  • ISO-9660—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 @@ -160,7 +175,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

    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 "Notes on Specific Drivers;" however, these problems are very minor on most systems.

    -

    Note: rEFInd's install.sh script does not install drivers by default. It does if you pass it the --drivers option, though. If you installed manually, you may also have installed rEFInd's drivers. See the Installing rEFInd page for details.

    +

    Note: rEFInd's install.sh script does not install drivers by default on OS X, but on Linux, it installs the driver required to read the /boot directory, if one is available. The script installs all the available drivers if you pass it the --drivers option. See the Installing rEFInd page for details.

    If you want to use one or more of these drivers, you can install them from the rEFInd binary package from the refind/drivers_arch directory, where arch is a CPU architecture code—x64 or ia32. The files are named after the filesystems they handle, such as ext2_x64.efi for the 64-bit ext2fs driver. You should copy the files for the filesystems you want to use to the drivers or drivers_arch subdirectory of the main rEFInd installation directory. (You may need to create this subdirectory.) Be careful to install drivers only for your own architecture. Attempting to load drivers for the wrong CPU type will cause a small delay at best, or may cause the computer to crash at worst. I've placed rEFInd's drivers in directories that are named to minimize this risk, but you should exercise care when copying driver files.

    @@ -203,13 +218,13 @@ fs0: map -r

    Notes on Specific Drivers

    -

    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—at least, not in my one test. (There may be options you can use when creating an ext4 filesystem that would enable the ext2fs driver to handle it, but if so I don't know what they are.) The ReiserFS driver is obviously useful only on ReiserFS partitions. (Reiser4 is not supported, as far as I know.) Given that these filesystems are getting a bit on in age by Linux standards, you might do well to use them on a separate Linux /boot partition; however, if you're willing to use ext3fs or ReiserFS on your root (/) 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.

    +

    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 /boot partition; however, if you're willing to use ext3fs, ext4fs, or ReiserFS on your root (/) 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.

    -

    The Pfisterer ext2fs and ReiserFS drivers work, but they are a bit sluggish—particularly the ext2fs driver. 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, 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 ReiserFS instead of ext2fs or ext3fs, at least if a change is practical. (For a /boot 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 /etc/fstab entry for a new UUID value, though. As noted earlier, be sure to use notail as an option in /etc/fstab for ReiserFS if you want to read it from EFI.) You can even use HFS+ on a Linux /boot 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 /boot partition and not deal with drivers at all. Mounting your ESP at /boot is a practical solution for many users.

    +

    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 /boot 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 /etc/fstab entry for a new UUID value, though. As noted earlier, be sure to use notail as an option in /etc/fstab for ReiserFS if you want to read it from EFI.) You can even use HFS+ on a Linux /boot 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 /boot partition and not deal with drivers at all. Mounting your ESP at /boot is a practical solution for many users.

    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.

    -

    Although both ext2fs and ReiserFS are case-sensitive, these drivers treat them in a case-insensitive way. Symbolic links work, which opens up possibilities for configuration, such as using a single kernel binary for multiple Linux distributions, with a link in one subdirectory pointing to a file in another directory. (If you try this, though, be sure to use relative links, as in ../otherdist/bzImage.efi, at least if the partition is not Linux's root filesystem.)

    +

    Although ext2fs, ext3fs, ext4fs, and ReiserFS are all case-sensitive, these drivers treat them in a case-insensitive way. Symbolic links work, which opens up possibilities for configuration, such as using a single kernel binary for multiple Linux distributions, with a link in one subdirectory pointing to a file in another directory. (If you try this, though, be sure to use relative links, as in ../otherdist/bzImage.efi, at least if the partition is not Linux's root filesystem.)

    diff --git a/docs/refind/features.html b/docs/refind/features.html index b9f41c3..086c889 100644 --- a/docs/refind/features.html +++ b/docs/refind/features.html @@ -15,7 +15,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

    Originally written: 3/14/2012; last Web page update: -12/6/2012, referencing rEFInd 0.5.0

    +12/16/2012, referencing rEFInd 0.6.0

    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!

    @@ -111,7 +111,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

  • 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; and the rEFInd versions don't work on at least some Macs.)
    • + 0.4.0.) @@ -143,7 +143,7 @@ lack a usable CSM.
  • The ability to specify additional directories to scan for boot loaders and drivers (as of version 0.2.7).
    • -
  • The ability to specify directories to not be scanned for boot loaders, even if they would ordinarily be scanned (as of version 0.4.2).
    • +
  • The ability to specify volumes and directories to not be scanned for boot loaders, even if they would ordinarily be scanned (as of version 0.6.0 for volumes and 0.4.2 for directories).
  • The ability to re-scan boot loaders, to assist when changing removable media or after making a change to the configuration file with an EFI shell (as of version 0.3.5).
    • @@ -151,7 +151,7 @@ lack a usable CSM.
  • The ability to specify an additional icon storage directory, to assist in efforts to customize rEFInd's appearance (as of version 0.3.4).
    • -
  • The ability to set the screen's resolution, within limits imposed by the EFI (as of rEFInd 0.3.0).
    • +
  • The ability to set the screen's graphics resolution, within limits imposed by the EFI (as of rEFInd 0.3.0). Similarly, as of version 0.6.0, you can specify the text-mode resolution.
  • Proper handling of more OS options than can fit on the screen. (rEFIt displays an empty list in graphical mode when it detects too many OSes.)
    • @@ -167,9 +167,9 @@ lack a usable CSM.
  • 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.)
    • -
  • Drivers for ISO-9660 and HFS+, 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.)
    • +
  • 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.)
    • -
  • Beginning with version 0.5.0, the ability to "talk" to the shim boot loader to validate binaries supported by shim or its machine owner key (MOK) list when booting in EFI mode. As of version 0.5.0, this support is still crude and buggy; it should be considered an alpha-level feature at the moment.
    • +
  • Beginning with version 0.5.0, the ability to "talk" to the shim boot loader 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.
    • diff --git a/docs/refind/getting.html b/docs/refind/getting.html index 3da81ee..4d81329 100644 --- a/docs/refind/getting.html +++ b/docs/refind/getting.html @@ -15,7 +15,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

    Originally written: 3/14/2012; last Web page update: -12/6/2012, referencing rEFInd 0.5.0

    +12/18/2012, referencing rEFInd 0.6.0

    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!

    @@ -98,7 +98,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

    In addition to these quirks, you should be aware of some options that install.sh supports to enable you to customize your installation in various ways. The syntax for install.sh is as follows:

    -install.sh [--esp | --usedefault device-file] [--drivers] [--shim shim-filename] \
-           [--localkeys]
+install.sh [--esp | --usedefault device-file] [--nodrivers | --alldrivers] \
+           [--shim shim-filename] [--localkeys]

    The details of the options are summarized in Table 1. Using some of these options in unusual conditions can generate warnings and prompts to confirm your actions. In particular, using --shim or --localkeys when you're not booted in Secure Boot mode, or failing to use --shim when you are booted in Secure Boot mode, will generate a query and a request to confirm your installation. Consult the Managing Secure Boot page for more on this topic.

    @@ -220,8 +244,12 @@ install.sh [--esp | --usedefault device-file] [--drive 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. - --drivers - Ordinarily install.sh does not install drivers; but when you specify this option, it does; it 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. + --nodrivers + Ordinarily install.sh attempts to install the driver required to read /boot on Linux. This attempt works only if you're using ext2fs, ext3fs, or ReiserFS on the relevant partition. If you want to forego this driver installation, pass the --nodrivers option. This option is the default on OS X or when you use --usedefault. + + + --alldrivers + 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-filename @@ -261,7 +289,7 @@ Filesystem 1K-blocks Used Available Use% Mounted on
  • Type rm refind_ia32.efi to remove the IA32 binary if you're using an x86-64 (64-bit) system; or type rm refind_x64.efi to remove the x86-64 binary if you're using an x86 (32-bit) system. You can optionally rename the binary you keep as refind.efi, but this isn't required. (Note that you must keep the version that's the correct bit width for your EFI; if you've installed a 32-bit Linux on a 64-bit PC with a 64-bit EFI, you'd keep refind_x64.efi.
    • -
  • Optionally, type rm -r drivers_ia32 to remove the x86 drivers from an x86-64 system, or rm -r drivers_x64 to remove the x86-64 drivers from a 32-bit x86 system. You may also want to remove some or all of the drivers for the architecture you are using; if you don't need them, they'll slow down the start process. See the page on drivers for more on this topic.
    • +
  • Optionally, type rm -r drivers_ia32 to remove the x86 drivers from an x86-64 system, or rm -r drivers_x64 to remove the x86-64 drivers from a 32-bit x86 system. You may also want to remove some or all of the drivers for the architecture you are using. If you don't need them, they'll slow down the start process, and worse, if you're using Secure Boot, rEFInd can load just one shim/MOK-signed driver. See the page on drivers for more on this topic.
  • 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.
    • @@ -516,7 +544,7 @@ $ ioreg -l -p IODeviceTree | grep firmware-abi
  • Drivers—You can install drivers to extend the capabilities of the EFI. rEFInd ships with filesystem drivers for ext2fs and ReiserFS, which can enable you to boot a Linux kernel with EFI stub - support from an ext2fs, ext3fs, or ReiserFS partition. (rEFInd also + support from an ext2fs, ext3fs, ext4fs, or ReiserFS partition. (rEFInd also provides ISO-9660 and HFS+ drivers.) You can find additional drivers from other sources, although they're still on the scarce side. See the Using EFI Drivers page for more on this @@ -550,6 +578,8 @@ $ ioreg -l -p IODeviceTree | grep firmware-abi +

    Some sources suggest that delayed launches of rEFInd on Macs are more common when installing rEFInd to the ESP, so if you've done this, you could try re-installing it to your OS X boot partition.

    +

    Uninstalling rEFInd

     diff --git a/docs/refind/linux.html b/docs/refind/linux.html index 77cabc0..5e9aa88 100644 --- a/docs/refind/linux.html +++ b/docs/refind/linux.html @@ -15,7 +15,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

    Originally written: 3/19/2012; last Web page update: -12/6/2012, referencing rEFInd 0.5.0

    +12/16/2012, referencing rEFInd 0.6.0

    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!

    @@ -92,17 +92,160 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

    Windows and Mac OS X both provide relatively simple EFI boot loader programs. Launch them, and if they're launched from the correct locations and have the correct files in place, they'll boot their respective OSes. This makes rEFInd's job easy; it just locates the boot loader program files and runs them.

    -

    Under Linux, by contrast, things can get complicated. As detailed on my Managing EFI Boot Loaders for Linux page, several different EFI boot loaders for Linux exist, and all of them require configuration. If you're lucky, your distribution will have set up a Linux boot loader in a sensible way, in which case rEFInd should detect it and it will work as easily as a Windows or Mac OS X boot loader. If you're not lucky, though, you may need to configure it further. rEFInd offers options to help out with this task. Specifically, you can use a traditional Linux boot loader or configure an EFI stub loader.

    +

    Under Linux, by contrast, things can get complicated. As detailed on my Managing EFI Boot Loaders for Linux page, several different EFI boot loaders for Linux exist, and all of them require configuration. If you're lucky, your distribution will have set up a Linux boot loader in a sensible way, in which case rEFInd should detect it and it will work as easily as a Windows or Mac OS X boot loader. If you're not lucky, though, you may need to configure it further. rEFInd offers options to help out with this task. Naturally, rEFInd supports traditional Linux boot loaders. It works even better with the Linux EFI stub loader, so I provide instructions on starting with it. For those interested in manual configuration, I also provide detailed instructions on how the EFI stub support works and how to configure it.

    +

    Using a Traditional Linux Boot Loader

    +     -

    I consider ELILO, GRUB Legacy, and GRUB 2 to be traditional Linux boot loaders. These programs all exist as EFI programs that are independent of the Linux kernel, but that can load a kernel and hand off control to it. All three programs have their own configuration files that reside in the same directory as the boot loader itself (or optionally elsewhere, in the case of GRUB 2).

    +

    I consider ELILO, GRUB Legacy, and GRUB 2 to be traditional Linux boot loaders. These programs all exist independent of the Linux kernel, but they can load a kernel and hand off control to it. All three programs have their own configuration files that reside in the same directory as the boot loader itself (or optionally elsewhere, in the case of GRUB 2).

    Ordinarily, rEFInd will detect these traditional boot loaders and provide main menu entries for them. If the boot loader exists in a directory with a name that matches a Linux distribution's icon filename, you'll automatically get a distribution-specific icon to refer to the boot loader.

    If you prefer, you can disable automatic scanning and create an entry in refind.conf for your distribution, as described on the Configuring the Boot Manager page. This method is harder to set up but can be preferable if you want to customize your options.

    -

    Using the EFI Stub Loader

    + +

    Using the EFI Stub Loader: A Quick Setup Guide

    +     + +

    The EFI stub loader is basic and reliable, but it requires some setup to use it on some computers. I describe three methods of using it: an easiest method for those with compatible partition and filesystem layouts, a quick test configuration for those without such a layout, and a long-term setup for those without the ideal setup.

    + + +

    For Those With Foresight or Luck: The Easiest Method

    +     + +

    This method requires that your /boot directory, whether it's on a separate partition or is a regular directory in your root (/) filesystem, be readable by the EFI. At the moment, all EFI implementations can read FAT and Macs can read HFS+. By using drivers, 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 /boot, 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 /boot partition. You must also have a 3.3.0 or later Linux kernel with EFI stub support, of course.

    + +

    If you installed rEFInd 0.6.0 or later with its install.sh 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: + +

      + +
    1. Copy the relevant driver file for your filesystem and architecture to + the drivers or drivers_arch + subdirectory of the rEFInd installation directory on the ESP. You may + need to create this subdirectory, too.
      2. + +
    2. Create a refind_linux.conf file in your /boot + directory. The mkrlconf.sh script that comes with rEFInd + should do this job, or you can do it manually as described later.
      3. + +
    + +

    When you reboot, you should see rEFInd options for your Linux kernels. If they work, your job is done, although you might want to apply some of the tweaks described in the maintenance-free setup section. If you have problems, you may need to adjust the refind_linux.conf file, as described in the detailed configuration section.

    + + +

    Testing the EFI Stub Loader

    +     + +

    If you're not sure you want to use the EFI stub loader in the long term, you can perform a fairly quick initial test of it. This procedure assumes that you have access to a 3.3.0 or later Linux kernel with EFI stub support compiled into it. (Fedora 17, Ubuntu 12.10, and probably other distributions ship with such kernels.) Creating this configuration poses no risk to your current boot options, provided you don't accidentally delete existing files. The procedure for a quick test is:

    + +
      + +
    1. Copy your kernel file (vmlinuz-*) and matching initial RAM + disk file (init*) from /boot to a subdirectory of + EFI on your ESP. Your distribution's directory there should + work fine. For instance, typing cp + /boot/vmlinuz-3.6.7-4.fc17.x86_64 + /boot/initramfs-3.6.7-4.fc17.x86_64.img /boot/efi/EFI/redhat might + do the trick on a Fedora system, although you'll probably have to + adjust the version numbers. Note that the filename forms vary from one + distribution to another, so don't worry if yours look different from + these. Be sure that you match up the correct files by version number, + though.
      2. + +
    2. Copy the /boot/refind_linux.conf file to the same directory to + which you copied your kernel. If this file doesn't exist, create it by + running (as root) the mkrlconf.sh script that came + with rEFInd.
      3. + +
    3. Reboot. You should now see a new entry for launching the Linux kernel + that you copied. Try the option. If it works, great. If not, you may + need to adjust your refind_linux.conf file. See the detailed configuration section for a description of + this file's format. If the kernel begins to boot but complains that it + couldn't find its root filesystem, double-check the version numbers on + your kernel and initial RAM disk file, and check the root= + option in refind_linux.conf.
      4. + +
    + +

    You can continue to boot your computer with this type of configuration; however, the drawback is that you'll need to copy your kernel whenever it's updated. This can be a hassle. A better way is to configure you system so that the EFI, and therefore rEFInd, can read your Linux /boot directory, where most Linux distributions place their kernels.

    + + +

    Configuring a Maintenance-Free Setup

    +     + +

    If your /boot 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 easiest solution. 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:

    + +
      + +
    1. Begin with your ESP mounted at /boot/efi, which is the most + common location. If it's not mounted there, type mount /dev/sda1 /boot/efi to do so (adjusting + /dev/sda1, if necessary), or mount it elsewhere and adjust the + paths in the following procedure as necessary.
      2. + +
    2. Check the size of the ESP by typing df -h + /boot/efi. The ESP must be large enough to hold several Linux + kernels and initial RAM disk files—100MiB at a bare minimum, and + preferably 200–500MiB.
      3. + +
    3. Check your /boot directory to be sure it contains no links or + other files that rely on Unix/Linux-style permissions or ownership. If + it does, don't proceed, or at least research these files further to + determine if you can work around the need for such permissions and + ownership.
      4. + +
    4. Type cp -r /boot/* /boot/efi. You'll see an + error message about being unable to copy /boot/efi into + itself. Ignore this.
      5. + +
    5. Type umount /boot/efi.
      6. + +
    6. Edit /etc/fstab and change the mount point for + /boot/efi to /boot. If the ESP isn't present in + /etc/fstab, you must create an entry for it, with a mount + point of /boot.
      7. + +
    7. Type mount -a to re-mount everything, + including /boot. Check that your normal /boot files + are all present, along with the new /boot/EFI directory, which + holds what used to be /boot/efi/EFI. If something seems to be + missing (other than /boot/efi with a lowercase efi), + then you should try to correct the problem.
      8. + +
    8. If it doesn't already exist, create a file called + /boot/refind_linux.conf and populate it with kernel options, + as described later. If this file doesn't + already exist, the easiest way to create it is to run the + mkrlconf.sh script that comes with rEFInd 0.5.1 and + later.
      9. + +
    9. Check your refind.conf file (presumably in + /boot/EFI/refind) to be sure that the + scan_all_linux_kernels line is uncommented. If it's not, + uncomment that line.
      10. + +
    10. Optionally, type cp + /boot/EFI/refind/icons/os_name.icns /boot/.VolumeIcon.icns + to give loaders in /boot an icon for your distribution.
      11. + +
    11. Reboot to test that this configuration works.
      12. + +
    + +

    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 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, 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 /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, 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 /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.

    + + +

    EFI Stub Loader Support Technical Details

    +

    The Linux EFI stub loader is a way to turn a Linux kernel into an EFI application. In a sense, the kernel becomes its own boot loader. This approach to booting Linux is very elegant in some ways, but as described on the page to which I just linked, it has its disadvantages, too. One challenge to booting in this way is that modern Linux installations typically require that the kernel be passed a number of options at boot time. These tell the kernel where the Linux root (/) filesystem is, where the initial RAM disk is, and so on. Without these options, Linux won't boot. These options are impossible for a generic boot loader to guess without a little help. It's possible to build a kernel with a default set of options, but this is rather limiting. Thus, rEFInd provides configuration options to help.

    @@ -116,9 +259,9 @@ to modify its own rEFInd configuration; or the one that controls rEFInd might set inappropriate options for another distribution. This is a problem that's been a minor annoyance for years under BIOS, since the same potential for poor configuration applies to LILO, GRUB Legacy, and GRUB 2 -on BIOS. The most reliable solution there is to chainload one boot loader -to another. The same solution is possible under EFI, but rEFInd offers -another possibility.

    +on BIOS. The most reliable solution under BIOS is to chainload one boot +loader to another. The same solution is possible under EFI, but rEFInd +offers another possibility.

    rEFInd 0.2.1 and later supports semi-automatic Linux EFI stub loader detection. This feature works as part of the standard boot loader scan operation, but it extends it as follows:

    @@ -131,9 +274,10 @@ another possibility.

    with version 0.3.0, if you uncomment the scan_all_linux_kernels option in refind.conf, rEFInd will also scan for kernels without a .efi filename - extension. This option is not the default, though, because it can pick - up old kernels that lack EFI stub loader support and even non-kernel - files.
    • + extension. This option is uncommented by default, but if you comment it + out, delete it, or change it to read scan_all_linux_kernels 0, + rEFInd won't scan for kernels that lack .efi filename + extensions.

    A kernel whose filename lacks a version string matches an initial RAM disk that also lacks a version string in its filename. Note that you can reliably use only one kernel and initial RAM disk per directory that lack version numbers in their filenames.

    @@ -157,12 +301,16 @@ another possibility.

    booting from an auto-detected kernel. It consists of a series of lines, each of which consists of a label followed by a series of kernel options. The first line sets default options, and subsequent lines set - options that are accessible from the main menu tag's submenu - screen. + options that are accessible from the main menu tag's submenu screen. If + you installed rEFInd 0.5.1 or later with the install.sh + script, that script created a sample refind_linux.conf file, + customized for your computer, in /boot. This file will work + without changes on many installations, but you may need to tweak it for + some. -

    The intent of this system is that distribution maintainers can place their kernels, initial RAM disks, and a refind_linux.conf file in their own subdirectory on the ESP. rEFInd will detect their kernels and create one main menu entry for each kernel. Each entry will implement as many options as there are lines in the refind_linux.conf file. In this way, two or more distributions can each maintain their boot loader entries, without being too concerned about who maintains rEFInd as a whole.

    +

    The intent of this system is that distribution maintainers can place their kernels, initial RAM disks, and a refind_linux.conf file in their own subdirectories on the ESP, on EFI-accessible /boot partitions, or in /boot directories on EFI-accessible Linux root (/) partitions. rEFInd will detect these kernels and create one main menu entry for each kernel. Each entry will implement as many options as there are lines in the refind_linux.conf file. In this way, two or more distributions can each maintain their boot loader entries, without being too concerned about who maintains rEFInd as a whole.

    The scan_all_linux_kernels option is intended to help users and distribution maintainers when rEFInd is used in conjunction with a Linux filesystem driver for EFI or when the ESP is mounted as the Linux /boot partition. In these cases, if all the kernels in Linux's /boot directory include EFI stub loader support, rEFInd will automatically detect and use kernels installed in the usual way, such as via an automatic system update. You won't even need to move or rename your kernels. You will need to set up a refind_linux.conf file and you may need to install a driver or set the also_scan_dirs option in refind.conf; but these are one-time requirements. Set up in this way, ongoing maintenance to handle kernel updates drops to zero!

    @@ -179,12 +327,14 @@ total 17943

    When rEFInd scans this directory, it will find two EFI boot loaders in EFI/ubuntu: grubx64.EFI and bzImage-3.3.0.efi. rEFInd will create two main-menu tags for these two loaders, one of which will launch Ubuntu's standard GRUB and the other of which will launch the 3.3.0 kernel file directly. The refind_linux.conf file contains a list of labels and options:

    + 
    -"Boot with defaults"         "root=/dev/sda3 ro quiet splash vt.handoff=7"
+"Boot using default options" "root=/dev/sda3 ro quiet splash vt.handoff=7"
 "Boot into single-user mode" "root=UUID=1cd95082-bce0-494c-a290-d2e642dd82b7 ro single"
 "Boot without graphics"      "root=UUID=1cd95082-bce0-494c-a290-d2e642dd82b7 ro"
 # "Boot alternate install"   "root=/dev/sdb9 ro quiet splash vt.handoff=7"
    +

    Ordinarily, both fields in this file must be enclosed in quotes. If you have to pass an option that includes quotes, you can do so by doubling up on them, as in "root=/dev/sdb9 my_opt=""this is it""", which passes root=/dev/sdb9 my_opt="this is it" to the shell. You can include as much white space as you like between options. You can also place comments in the file, or remove an option by commenting it out with a leading hash mark (#), as in the fourth line in this example.

    @@ -195,7 +345,7 @@ total 17943 a refind_linux.conf file in the Linux kernel's directory." border=2>
    -

    Note that the first entry shown here takes a name that's set in rEFInd rather than the one specified in the refind_linux.conf file. The remaining names match those specified in the file, though.

    +

    To assist in initial configuration, rEFInd's install.sh script creates a sample refind_linux.conf file in /boot. This sample file defines three entries, the first two of which use the default GRUB options defined in /etc/default/grub and the last of which uses minimal options. The first entry boots normally and the second boots into single-user mode. If you want to create a new file, you can use the mkrlconf.sh script that comes with rEFInd. If you pass it the --force option, it will overwrite the existing /boot/refind_linux.conf file; otherwise it will create the file only if one doesn't already exist.

    From a user's perspective, the submenus defined in this way work just like submenus defined via the submenuentry options in refind.conf, or like the submenus that rEFInd creates automatically for Mac OS X or ELILO. There are, however, limitations in what you can accomplish with this method:

    diff --git a/docs/refind/revisions.html b/docs/refind/revisions.html index 7ccd1c0..7e1c775 100644 --- a/docs/refind/revisions.html +++ b/docs/refind/revisions.html @@ -14,8 +14,7 @@

    by Roderick W. Smith, rodsmith@rodsbooks.com

    -

    Last Web page update: 12/6/2012

    - +

    Last Web page update: 12/16/2012

    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!

    @@ -93,7 +92,13 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com