I know it's just an Example, but it can be a little misleading. Most Linux Kernels are on /boot and it's possible to assume looking into this example that rEFInd would look into the /boot directory for the files, which it doesn't. So I would change the behavior to look into '/' and '/boot' by default or maybe change the example to:
Suggestion 2: I find exceptional the way rEFInd detects the linux kernels on all partitions in case of scan_all_linux_kernels set to true, and I can think of only one way to improve: The ability to select only the latest kernels. This could be an option that could be set not by default but commented with the following behavior:
- if /boot/vmlinuz or /boot/vmlinux found, ignore all the other files on the same directory.
- if not, detect the numbers on the file names and choose the latest accordingly so vmlinuz-3.10.2 e.g. would be the only selected instead of both it and vmlinuz-3.10.1
That way only one option for each Linux could be shown and it would be nice for someone who has more than one Linux Distribution and is testing rEFInd without yet touching too much the config file.
Best Regards.
Last edit: ICMP_Request 2014-05-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Most Linux distributions do place kernels in the /boot directory from Linux's point of view. Many distributions and individuals, though, create a separate /boot partition, in which case the kernels will reside in the root directory of that partition from the EFI's point of view. Thus, although making the change you suggest would bring the example more in line with the state of affairs on some installations, it would make it more confusing for others. In other words, this is a no-win scenario.
A few weeks ago, I looked into folding multiple kernels into a single entry, using the F2/Insert submenu as a way to select among them. Unfortunately, this got pretty hairy because of the layout of the data structures that rEFInd uses to hold boot loader information. I'm giving this more thought, and may eventually do something like this, but I may want to first re-work some of those internal data structures, which will be a big undertaking.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for reading and considering my suggestions! =)
About the first one, I have just one additional point to add: While many distributions and individuals create a separate /boot partition, what is the point of doing that if rEFInd can be used as the boot manager? Of course rEFInd IIRC is able to call Grub2, etc. but there seems to be really no need since it can boot Linux Kernels directly and also specify parameters on its config files.
My point is, if someone is using rEFInd, chances are they will not install other boot loaders or they will be installed not in a /boot partition but on the EFI one, so there seems to be really no need for an alternate boot partition. It may happen but I believe in most cases not.
Best Regards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are several reasons to use a separate /boot partition, such as:
LVM or RAID -- rEFInd cannot currently read an LVM or software RAID setup (except for mirrored RAID). Thus, a separate /boot partition is pretty much required in such setups. Note that some distributions, including the popular Fedora, use LVM by default, so this is actually a pretty common configuration.
XFS, JFS, or some other exotic root filesystem -- If the user wants to use a root (/) filesystem that rEFInd can't read, then /boot pretty much has to be a separate partition.
ESP as /boot -- When using some boot loaders, such as ELILO or gummiboot, it simplifies matters to mount the ESP as /boot rather than as /boot/efi. A user might have begun with such a configuration or might want to maintain multiple boot loaders and so use such a setup. Using the ESP as /boot is popular among Arch Linux users. Although it's something that the setup utilities for some others (such as Fedora and Ubuntu) don't permit, it can be achieved with most distributions manually after installation, if desired.
/boot on a separate disk -- If the main hard disk is unsupported by the EFI (say, if it's a hardware RAID device for which EFI drivers are unavailable), it may be necessary to put both the ESP and /boot on another disk that the EFI can read -- maybe even on a USB flash drive.
There are probably other reasons that I'm forgetting or haven't considered.
One of the challenges of writing software is that users have divergent needs. People have used both rEFInd and my other project, GPT fdisk, in ways that I'd never considered before hearing of them. Sometimes I add features or tweak the program in order to help these people. The point here, though, is to net get caught in the trap of thinking that because you've never done something that it's uncommon or unnecessary.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I think you've done an excellent work on rEFInd and words cannot express my gratitude for this great Boot Manager.
I have only 2 minor low-priority suggestions to make:
Suggestion 1: On the Sample Config, there is this line below:
menuentry Linux {
icon EFI/refind/icons/os_linux.icns
volume KERNELS
loader bzImage-3.3.0-rc7
initrd initrd-3.3.0.img
options "ro root=UUID=5f96cafa-e0a7-4057-b18f-fa709db5b837"
disabled
}
I know it's just an Example, but it can be a little misleading. Most Linux Kernels are on /boot and it's possible to assume looking into this example that rEFInd would look into the /boot directory for the files, which it doesn't. So I would change the behavior to look into '/' and '/boot' by default or maybe change the example to:
loader bzImage-3.3.0-rc7 -> loader /boot/bzImage-3.3.0-rc7
initrd initrd-3.3.0.img -> initrd /boot/initrd initrd-3.3.0.img
Suggestion 2: I find exceptional the way rEFInd detects the linux kernels on all partitions in case of scan_all_linux_kernels set to true, and I can think of only one way to improve: The ability to select only the latest kernels. This could be an option that could be set not by default but commented with the following behavior:
- if /boot/vmlinuz or /boot/vmlinux found, ignore all the other files on the same directory.
- if not, detect the numbers on the file names and choose the latest accordingly so vmlinuz-3.10.2 e.g. would be the only selected instead of both it and vmlinuz-3.10.1
That way only one option for each Linux could be shown and it would be nice for someone who has more than one Linux Distribution and is testing rEFInd without yet touching too much the config file.
Best Regards.
Last edit: ICMP_Request 2014-05-12
Most Linux distributions do place kernels in the
/bootdirectory from Linux's point of view. Many distributions and individuals, though, create a separate/bootpartition, in which case the kernels will reside in the root directory of that partition from the EFI's point of view. Thus, although making the change you suggest would bring the example more in line with the state of affairs on some installations, it would make it more confusing for others. In other words, this is a no-win scenario.A few weeks ago, I looked into folding multiple kernels into a single entry, using the F2/Insert submenu as a way to select among them. Unfortunately, this got pretty hairy because of the layout of the data structures that rEFInd uses to hold boot loader information. I'm giving this more thought, and may eventually do something like this, but I may want to first re-work some of those internal data structures, which will be a big undertaking.
Thanks for reading and considering my suggestions! =)
About the first one, I have just one additional point to add: While many distributions and individuals create a separate /boot partition, what is the point of doing that if rEFInd can be used as the boot manager? Of course rEFInd IIRC is able to call Grub2, etc. but there seems to be really no need since it can boot Linux Kernels directly and also specify parameters on its config files.
My point is, if someone is using rEFInd, chances are they will not install other boot loaders or they will be installed not in a /boot partition but on the EFI one, so there seems to be really no need for an alternate boot partition. It may happen but I believe in most cases not.
Best Regards.
There are several reasons to use a separate
/bootpartition, such as:/bootpartition is pretty much required in such setups. Note that some distributions, including the popular Fedora, use LVM by default, so this is actually a pretty common configuration./) filesystem that rEFInd can't read, then/bootpretty much has to be a separate partition./boot-- When using some boot loaders, such as ELILO or gummiboot, it simplifies matters to mount the ESP as/bootrather than as/boot/efi. A user might have begun with such a configuration or might want to maintain multiple boot loaders and so use such a setup. Using the ESP as/bootis popular among Arch Linux users. Although it's something that the setup utilities for some others (such as Fedora and Ubuntu) don't permit, it can be achieved with most distributions manually after installation, if desired./booton a separate disk -- If the main hard disk is unsupported by the EFI (say, if it's a hardware RAID device for which EFI drivers are unavailable), it may be necessary to put both the ESP and/booton another disk that the EFI can read -- maybe even on a USB flash drive.There are probably other reasons that I'm forgetting or haven't considered.
One of the challenges of writing software is that users have divergent needs. People have used both rEFInd and my other project, GPT fdisk, in ways that I'd never considered before hearing of them. Sometimes I add features or tweak the program in order to help these people. The point here, though, is to net get caught in the trap of thinking that because you've never done something that it's uncommon or unnecessary.