I'm afraid your patch would not implement the Freedesktop boot loader proposal. Your patch adds filenames beginning with the string linux to the list of Linux kernel filenames; but the Freedesktop proposal requires parsing a new configuration file format, in which the keywordlinux points to a Linux kernel file. The example on the site happens to use a kernel file called linux, but that's not actually a requirement of the proposal.
In fact, I have already looked at the possibility of supporting this proposal in rEFInd. It shouldn't be too difficult, because most of the configuration file elements are similar to what rEFInd already uses in its manual boot stanza settings. They aren't identical, though, so I would need to either extend what's already in rEFInd or add a new option to load Freedesktop-style configuration files. A more serious concern is that, to the best of my knowledge, no major distribution is actually using the Freedesktop proposal. Most of them are sticking with GRUB 2 and its traditional configuration file. (Arch Linux is probably the closest to using this system, since many Arch users use gummiboot, whose method of operation seems to have been the inspiration for the Freedesktop proposal.) Thus, adding support for the Freedesktop proposal wouldn't really do much to help anybody. It would be extra code, though, which means more possibilities for bugs and something new for me to support. There'd also be more to document, and many users find the rEFInd documentation intimidating as it is. Furthermore, if the Freedesktop proposal changes, that would mean (possibly disruptive) changes for any rEFInd users who adopt this method of configuration. I'll add that there are a number of problems with the Freedesktop proposal, so although it's got some potential benefits, I'm not really a big fan of it in its current form.
In sum, I'm playing "wait-and-see" on this one. I'll add support for this proposal if I think that doing so will be beneficial in the future. In the meantime, I see more negatives than positives to adding such support to rEFInd.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would start the discussion on the freedesktop spec and I couldn't come without a small present.
The systemd "kernel-install" helper, which is designed to be called after each kernel installation, put the kernel binary in /boot/$id/$kver/linux.
kernel-install come with a hook system, which allow users to add extra treatments. For example, like installing a custom refind_linux.conf for each installed kernel. This mechanism is pretty useful.
This humble patch, makes refind look for kernel installed by kernel-install and makes them visible on the refind menu (using the default refind configuration files for boot options).
Without supporting the freedesktop boot spec and modifying the code base, this tiny patch allow refind to boot kernel installed with "kernel-install" (which respect the bootspec). I see good benefit with no pain.
About a complete support of the freedesktop spec, there is, more work to do. I'm happy that you express your thoughts. I'm not a huge supporter of the freedesktop boot spec design, but let me share with you what benefits I see to implement it in refind.
1) You will support a feature trying to unify boot configurations.
2) You will make boot configuration easiers for refind users who wants a hook system in front of kernel installation process.
3) You will offer a shelter to "kernel-install" users. Gummiboot lacks of refind features (auto kernel selection by name, global kernel options configuration, etc).
4) You would be the second bootloader to support them. You will avoid an anti-trust trial to gummiboot developers.
5) There are users looking for that. I'm one of them.
6) If this is never adopted by major distros, you can drop it, it was just one way to configure refind.
7) It's no more a proposal, but a spec, so there should not have disruptive change.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IMHO, using a systemd script to move the kernel file from /boot and modifying rEFInd to support this change makes things more complicated than they need to be. rEFInd detects Linux kernels just fine where the Arch package puts them; and for more complex setups with multiple kernels, a manual boot stanza will be required in any event. Thus, the patch you provided doesn't really accomplish much.
As to the Freedesktop boot loader proposal more generally, I've stated my position, and your stated reasons for supporting it in rEFInd have not swayed me. Sorry, but I'm just going to play "wait and see" on this one.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, that's a little hairier than it looks because of the issue of pattern-matching wildcards (*, ?, and so on). One section of code (in ScanEfiFiles()) could be easily enough adapted for this, because the patterns are simply passed on to an EFI system call; but in another point (in SetLoaderDefaults()), the pattern-match characters would have to be parsed or stripped away. Although this could be done, I'm not convinced that there's much value to doing so. The vast majority of Linux kernels match the patterns vmlinuz* or bzImage*, and the current code works fine with them. If a user has a kernel with a non-standard filename, a manual boot stanza can handle the task of booting that kernel. Granted, this may require maintenance with kernel updates if the filename includes a version number; but modifying rEFInd for a feature that 99.9% of users won't be using seems pointless to me.
Note that if you want to match on linux*, as in the patch you proposed at the start of this thread, that is not a standard or common name. The Freedesktop boot proposal does not say that should be a filename; it uses linux as a keyword in its proposed/gummiboot's configuration file, but says nothing explicit about what the kernel's filename should be. As a practical matter, as I say, it's almost always vmlinuz* or bzImage*. These names are both well-documented as Linux kernel filenames. Therefore, anybody who uses the Freedesktop proposal as a reason to name the Linux kernel linux* is deviating from accepted kernel-naming practice. This isn't necessarily "wrong," but it's something that I don't want to encourage because it just complicates matters.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
Refind is almost already able to support Freedesktop bootspec. The missing step is to match kernel starting by linux (or named linux).
Here is a patch proposal:
https://horus.seblu.net/~seblu/refind/0001-Add-Freedesktop-bootspec-support.patch
The bootspec url:
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
Regards,
I'm afraid your patch would not implement the Freedesktop boot loader proposal. Your patch adds filenames beginning with the string
linuxto the list of Linux kernel filenames; but the Freedesktop proposal requires parsing a new configuration file format, in which the keywordlinuxpoints to a Linux kernel file. The example on the site happens to use a kernel file calledlinux, but that's not actually a requirement of the proposal.In fact, I have already looked at the possibility of supporting this proposal in rEFInd. It shouldn't be too difficult, because most of the configuration file elements are similar to what rEFInd already uses in its manual boot stanza settings. They aren't identical, though, so I would need to either extend what's already in rEFInd or add a new option to load Freedesktop-style configuration files. A more serious concern is that, to the best of my knowledge, no major distribution is actually using the Freedesktop proposal. Most of them are sticking with GRUB 2 and its traditional configuration file. (Arch Linux is probably the closest to using this system, since many Arch users use gummiboot, whose method of operation seems to have been the inspiration for the Freedesktop proposal.) Thus, adding support for the Freedesktop proposal wouldn't really do much to help anybody. It would be extra code, though, which means more possibilities for bugs and something new for me to support. There'd also be more to document, and many users find the rEFInd documentation intimidating as it is. Furthermore, if the Freedesktop proposal changes, that would mean (possibly disruptive) changes for any rEFInd users who adopt this method of configuration. I'll add that there are a number of problems with the Freedesktop proposal, so although it's got some potential benefits, I'm not really a big fan of it in its current form.
In sum, I'm playing "wait-and-see" on this one. I'll add support for this proposal if I think that doing so will be beneficial in the future. In the meantime, I see more negatives than positives to adding such support to rEFInd.
I would start the discussion on the freedesktop spec and I couldn't come without a small present.
The systemd "kernel-install" helper, which is designed to be called after each kernel installation, put the kernel binary in /boot/$id/$kver/linux.
kernel-install come with a hook system, which allow users to add extra treatments. For example, like installing a custom refind_linux.conf for each installed kernel. This mechanism is pretty useful.
This humble patch, makes refind look for kernel installed by kernel-install and makes them visible on the refind menu (using the default refind configuration files for boot options).
Without supporting the freedesktop boot spec and modifying the code base, this tiny patch allow refind to boot kernel installed with "kernel-install" (which respect the bootspec). I see good benefit with no pain.
About a complete support of the freedesktop spec, there is, more work to do. I'm happy that you express your thoughts. I'm not a huge supporter of the freedesktop boot spec design, but let me share with you what benefits I see to implement it in refind.
1) You will support a feature trying to unify boot configurations.
2) You will make boot configuration easiers for refind users who wants a hook system in front of kernel installation process.
3) You will offer a shelter to "kernel-install" users. Gummiboot lacks of refind features (auto kernel selection by name, global kernel options configuration, etc).
4) You would be the second bootloader to support them. You will avoid an anti-trust trial to gummiboot developers.
5) There are users looking for that. I'm one of them.
6) If this is never adopted by major distros, you can drop it, it was just one way to configure refind.
7) It's no more a proposal, but a spec, so there should not have disruptive change.
IMHO, using a systemd script to move the kernel file from
/bootand modifying rEFInd to support this change makes things more complicated than they need to be. rEFInd detects Linux kernels just fine where the Arch package puts them; and for more complex setups with multiple kernels, a manual boot stanza will be required in any event. Thus, the patch you provided doesn't really accomplish much.As to the Freedesktop boot loader proposal more generally, I've stated my position, and your stated reasons for supporting it in rEFInd have not swayed me. Sorry, but I'm just going to play "wait and see" on this one.
Ok
Could you consider adding a way to customize the kernel detection pattern in the config file?
Unfortunately, that's a little hairier than it looks because of the issue of pattern-matching wildcards (
*,?, and so on). One section of code (inScanEfiFiles()) could be easily enough adapted for this, because the patterns are simply passed on to an EFI system call; but in another point (inSetLoaderDefaults()), the pattern-match characters would have to be parsed or stripped away. Although this could be done, I'm not convinced that there's much value to doing so. The vast majority of Linux kernels match the patternsvmlinuz*orbzImage*, and the current code works fine with them. If a user has a kernel with a non-standard filename, a manual boot stanza can handle the task of booting that kernel. Granted, this may require maintenance with kernel updates if the filename includes a version number; but modifying rEFInd for a feature that 99.9% of users won't be using seems pointless to me.Note that if you want to match on
linux*, as in the patch you proposed at the start of this thread, that is not a standard or common name. The Freedesktop boot proposal does not say that should be a filename; it useslinuxas a keyword in its proposed/gummiboot's configuration file, but says nothing explicit about what the kernel's filename should be. As a practical matter, as I say, it's almost alwaysvmlinuz*orbzImage*. These names are both well-documented as Linux kernel filenames. Therefore, anybody who uses the Freedesktop proposal as a reason to name the Linux kernellinux*is deviating from accepted kernel-naming practice. This isn't necessarily "wrong," but it's something that I don't want to encourage because it just complicates matters.