X-Git-Url: https://code.delx.au/refind/blobdiff_plain/1f5e6865fb9bf8ebb78b4818a6d54440c7c4004a..12cfc677aad6ab1519212ee74eae05b2d04b8dc6:/docs/refind/linux.html
diff --git a/docs/refind/linux.html b/docs/refind/linux.html
index 939e798..0b56019 100644
--- a/docs/refind/linux.html
+++ b/docs/refind/linux.html
@@ -14,7 +14,8 @@
by Roderick W. Smith, rodsmith@rodsbooks.com
-Originally written: 3/19/2012; last Web page update: 4/9/2012, referencing rEFInd 0.2.5
+Originally written: 3/19/2012; last Web page update:
+6/23/2012, referencing rEFInd 0.4.4
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!
@@ -123,20 +124,48 @@ another possibility.
-- rEFInd looks for boot loaders whose names include the strings bzImage or vmlinuz and that end in .efi. For instance, bzImage-3.3.0.efi or vmlinuz-3.3.0-fc17.efi would match, and trigger subsequent steps in this procedure. Note that to use this system, you must give your kernel file a .efi extension, at least on the ESP (or other boot loader partition)!
+- rEFInd looks for boot loaders whose names include the strings
+ bzImage or vmlinuz and that end in .efi. For
+ instance, bzImage-3.3.0.efi or vmlinuz-3.3.0-fc17.efi
+ would match, and trigger subsequent steps in this procedure. Beginning
+ 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.
-- rEFInd looks for an initial RAM disk in the same directory as the kernel file. A matching initial RAM disk has a name that begins with init and that includes the same version string as the kernel. The version string is defined as the part of the filename from the first digit to the last digit, inclusive. Note that the version string can include non-digits. For instance, the version string for bzImage-3.3.0.efi is 3.3.0, which matches initramfs-3.3.0.bz; and vmlinuz-3.3.0-fc17.efi's version string is 3.3.0-fc17, which matches initrd-3.3.0-fc17.img. Many other matches are possible. If an initial RAM disk is identified, rEFInd passes a suitable initrd= option to the kernel when it boots.
-
-
-
-- rEFInd looks for a file called refind_linux.conf in the same directory as the kernel file. This file is a practical requirement for 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.
+- rEFInd looks for an initial RAM disk in the same directory as the
+ kernel file. A matching initial RAM disk has a name that begins with
+ init and that includes the same version string as the kernel.
+ The version string is defined as the part of the filename from the
+ first digit to the last digit, inclusive. Note that the version string
+ can include non-digits. For instance, the version string for
+ bzImage-3.3.0.efi is 3.3.0, which matches
+ initramfs-3.3.0.bz; and vmlinuz-3.3.0-fc17.efi's
+ version string is 3.3.0-fc17, which matches
+ initrd-3.3.0-fc17.img. Many other matches are possible. If an
+ initial RAM disk is identified, rEFInd passes a suitable
+ initrd= option to the kernel when it boots.
+
+
+
+- rEFInd looks for a file called refind_linux.conf in the same
+ directory as the kernel file. This file is a practical requirement for
+ 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.
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 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!
+
As an example, consider the following file configuration:
@@ -174,16 +203,33 @@ total 17943
Your kernels must be compiled with EFI stub loader support.
-You can't set a submenu option to boot via a different boot loader, such as ELILO or GRUB; all the submenu options apply to a single boot loader—that is, a single kernel. (rEFInd will still detect other boot loaders and provide separate main-menu tags for them, though.)
+You can't set a submenu option to boot via a different boot loader,
+ such as ELILO or GRUB; all the submenu options apply to a single boot
+ loader—that is, a single kernel. (rEFInd will still detect other
+ boot loaders and provide separate main-menu tags for them,
+ though.)
-If an installation includes two or more kernel files, each one receives its own main-menu entry; you can't combine them together in one menu item. This is essentially a corollary of the preceding limitation. The result can be an overburdened main menu if your system has many kernels.
+If an installation includes two or more kernel files, each one receives
+ its own main-menu entry; you can't combine them together in one menu
+ item. This is essentially a corollary of the preceding limitation. The
+ result can be an overburdened main menu if your system has many
+ kernels.
-All the kernels in a given directory use the same refind_linux.conf file. If you need to set different options for different kernels, you'll need to place those kernels in different directories.
+All the kernels in a given directory use the same
+ refind_linux.conf file. If you need to set different options
+ for different kernels, you'll need to place those kernels in different
+ directories.
-You must place your kernels in a directory other than the one that holds the main rEFInd .efi file. This is because rEFInd does not scan its own directory for boot loaders.
+You must place your kernels in a directory other than the one that
+ holds the main rEFInd .efi file. This is because rEFInd does
+ not scan its own directory for boot loaders.
+Ordinarily, a kernel booted in this way must reside on the ESP, or at least on another FAT partition. On a Macintosh, though, you can use HFS+ to house your kernel files. In fact, that may be necessary; my Mac Mini hangs when I try to boot a Linux kernel via an EFI stub loader from the computer's ESP, but it works fine when booting from an HFS+ partition. If you use EFI drivers, though, you can place your kernel on any filesystem for which an EFI driver exists. This list is currently rather limited (ext2fs/ext3fs, ReiserFS, ISO-9660, and HFS+), but even just one or two options might help a lot if you've got an undersized ESP or if copying your kernel file to the ESP is a hassle you'd rather avoid.
+
+Beginning with version 0.3.1, rEFInd sorts boot loader entries within each directory by time stamp, so that the most recent entry comes first. Thus, if you specify a directory name (or a volume label, for loaders stored in a volume's root directory) as the default_selection, rEFInd will make the most recent loader in the directory the default. This can obviate the need to adjust this configuration parameter when you add a new kernel; chances are you want the most recently-added kernel to be the default, and rEFInd makes it so when you set the default_selection in this way. If you don't want the latest kernel to become the default, you can use touch to give the desired kernel (or other boot loader) in the directory a more recent time stamp, or you can set default_selection to a value that uniquely identifies your desired default loader. One caveat you should keep in mind is that the EFI and Windows interpret the hardware clock as local time, whereas Mac OS X uses Coordinated Universal Time (UTC). Linux can work either way. Thus, time stamps for boot loaders can be skewed by several hours depending on the environment in which they were created or last modified.
+
On the whole, this method of configuration has a lot going for it. For distribution maintainers, if you place your Linux kernel files (with EFI stub support) on the ESP, with suitable filenames, matching initial RAM disk files, and a refind_linux.conf file, then any rEFInd 0.2.3 or later installation should detect your files, even if the user installs another distribution with another rEFInd that takes over from yours. (If the user, or this other rEFInd installation, disables auto-detection, this won't work.)