Fedora's Peter Jones has stopped maintenance of GRUB Legacy when Fedora moved fully to GRUB2, so grub-legacy-fedora (EFI) is not an option anymore.
I disagree with your conclusion. Just because software is no longer being maintained does not mean that it's "not an option." This is especially true of programs for something like a boot loader, which is relatively simple and that runs in an environment that's quite stable (in the sense that any given computer's firmware is unlikely to change often, and when it does change, that change is likely to be a minor bug-fix release). The problems with the EFI stub loader on some computers support my point of view on this -- the old and unmaintained GRUB Legacy and ELILO both work on many computers, despite lack of maintenance, whereas the newer EFI stub loader has problems, which have persisted for ages, despite being known to the developer. Even in a much more dynamic OS environment, old and unmaintained software can be useful. For instance, I regularly use xv, which is a graphics program that hasn't been updated in ages.
That said, the lack of maintenance is certainly an issue in the long term, and possibly when installing to a new computer with a new firmware -- when UEFI 2.4 comes out, it's conceivable that some unmaintained boot loaders will stop working. Unless and until that happens, though, I have no compunctions about using (or recommending) unmaintained boot loaders.
]]>cfr wrote:I just feel a certain obligation to defend grub out of loyalty and because I am immensely glad that it is available to me, given that without it I would be completely screwed. [yaboot is in that category, too.]
Do Fedora's patched GRUB Legacy, ELILO, SYSLINUX not work for you? The usual EFI stub boot problems can be solved by any of those three problems or GRUB 2, so there are lots of options even then. (Granted, Fedora's patched GRUB Legacy is not in the Arch repository, and I'm not sure about ELILO; but they are still available elsewhere....)
Fedora's Peter Jones has stopped maintenance of GRUB Legacy when Fedora moved fully to GRUB2, so grub-legacy-fedora (EFI) is not an option anymore.
I exchanged few private mails with ELILO maintainer regarding its development status. According to upstream maintainer, ELILO is in bug-fix only maintenance mode (no new features will be added). He himself recommends moving to other EFI bootloaders like GRUB if new features are required.
Syslinux EFI support is new and still has few rough edges (see bugzilla.syslinux.org for list of open reports). Development is currently slow, not the fault of upstream maintainers (mfleming and hpa) since they also maintain the upstream kernel EFI code and they are busy taking care of that right now. Syslinux also uses the EFI Handover Protocol, a subset of the EFISTUB code so the EFISTUB issue may or may not affect Syslinux EFI users.
So that leaves only GRUB as the currently fully maintained non-EFISTUB related bootloader. GRUB upstream has no plans to implement EFI Handover Protocol currently, so it is still using the traditional linux boot protocol used by Syslinux pre-v6, ELILO and GRUB Legacy, which the only working way for EFISTUB affected users to boot.
EDIT: I currently maintain ELILO in AUR. I used to maintain grub-legacy-fedora EFI in AUR but orphaned it when Fedora moved fully to GRUB2 and Peter Jones stopped maintaining the code. The package has been deleted from AUR at some point.
]]>cfr wrote:I just feel a certain obligation to defend grub out of loyalty and because I am immensely glad that it is available to me, given that without it I would be completely screwed. [yaboot is in that category, too.]
Do Fedora's patched GRUB Legacy, ELILO, SYSLINUX not work for you? The usual EFI stub boot problems can be solved by any of those three problems or GRUB 2, so there are lots of options even then. (Granted, Fedora's patched GRUB Legacy is not in the Arch repository, and I'm not sure about ELILO; but they are still available elsewhere....)
I'm reluctant to rely on something from AUR for something this critical unless forced to do so. Syslinux didn't support EFI when I first needed a solution. I don't believe Elilo is in the repos either.
]]>I just feel a certain obligation to defend grub out of loyalty and because I am immensely glad that it is available to me, given that without it I would be completely screwed. [yaboot is in that category, too.]
Do Fedora's patched GRUB Legacy, ELILO, SYSLINUX not work for you? The usual EFI stub boot problems can be solved by any of those three problems or GRUB 2, so there are lots of options even then. (Granted, Fedora's patched GRUB Legacy is not in the Arch repository, and I'm not sure about ELILO; but they are still available elsewhere....)
]]>EDIT: Stripping blanks and comments:
grub.cfg: 292 for 23 entries
refind + custom .conf: 100 for 14 entriesYou're presumably using a lot of manual boot entries in rEFInd, or have many or large refind_linux.conf files. (There are only 24 configuration keywords in refind.conf, aside from those associated with manual boot stanzas, so you'd use at most 24 lines outside of the manual boot stanzas.) Although using manual boot stanzas is a perfectly legitimate way to use rEFInd, IMHO it's not the best way in most cases. One of the things that impressed me about rEFIt, and that prompted me to continue its development as rEFInd, was that rEFIt could auto-detect a lot of boot loaders, so that it didn't need to be messed with in order to boot new OSes. I built on that ability in rEFInd, extending it to Linux kernels with EFI stub loaders. Thus, rEFInd can detect and boot a new kernel (stored under a new name) with no changes to its configuration file -- something that no other boot loader/manager for Linux can claim (except for rEFIt, with several caveats). Unless you're doing something really weird, it's almost always simpler to configure rEFInd to rely on auto-detection than to use manual boot stanzas.
Actually, I didn't think it was fair to count the refind_linux.conf I have so I didn't include it. But, yes. I have 14 entries versus 23 for grub. I forget why I need to use manual configuration for rEFInd but there is some reason I needed this to achieve something I wanted.
This is not to disagree but I think grub's complexity is easily overstated. It can do all kinds of fancy stuff but it doesn't have to, and it is not that complicated to configure for simple stuff.
IMO, part of GRUB's problem is that there is so much complexity associated with the "fancy stuff... it doesn't have to" do. Even if you strip the grub.cfg file down to a bare-bones configuration, the complexity still lurks in the code, which means there's the potential to hide bugs. As a practical matter, most people rely on the grub-mkconfig script, which generates ridiculously complex and difficult-to-parse grub.cfg files. If you use a simpler hand-crafted grub.cfg file, then that helps matters, but considering typical use cases, GRUB falls down on this one.
I won't argue about the complexity of grub's code. I just meant that it need not be complex to configure if you want it to be simple.
EDIT 2: Note that I have a bias in favour of grub because it happens to work very, very reliably on my machine. Nothing else will even boot the damn thing. So simplicity is really beside the point. I don't want a 6 line config file for something which won't boot. If I relied on EFISTUB to boot, I'd still be on kernel 3.7.*!
Naturally; in your case the EFI stub loader isn't working, so you can't use rEFInd or gummiboot. You'll get no argument from me on this score.
Actually, I really like rEFInd and I still use it even though it would be more efficient to set grub as my default boot loader and not use a boot manager at all (since essentially the only usable entry is grub anyway). I just feel a certain obligation to defend grub out of loyalty and because I am immensely glad that it is available to me, given that without it I would be completely screwed. [yaboot is in that category, too.]
]]>I would recommend syslinux-efi, but it is still young and not without some occasional issues. I have it set up, and test it from time to time, and it typically works pretty well. But I wouldn't rely on it as a sole bootloader at this point in time. But one of the nice things about UEFI is that you are not limited to one bootloader and/or boot manager.
]]>FWIW [including comments and blank lines]:
total lines in grub.cfg: 416
total lines in refind.conf + my custom conf: 475 [refind.conf is 408 but that's not a fair comparison since it isn't customised to my liking without the additional file]
Currently, the default refind.conf-sample file is 388 lines, but most of those are comments, most of the rest are either blank lines or sample manual boot stanzas that are disabled. Replacing the default setup with a two-line refind.conf would have the same effect as the default file. (This file would set "timeout 20" and "scan_all_linux_kernels".)
EDIT: Stripping blanks and comments:
grub.cfg: 292 for 23 entries
refind + custom .conf: 100 for 14 entries
You're presumably using a lot of manual boot entries in rEFInd, or have many or large refind_linux.conf files. (There are only 24 configuration keywords in refind.conf, aside from those associated with manual boot stanzas, so you'd use at most 24 lines outside of the manual boot stanzas.) Although using manual boot stanzas is a perfectly legitimate way to use rEFInd, IMHO it's not the best way in most cases. One of the things that impressed me about rEFIt, and that prompted me to continue its development as rEFInd, was that rEFIt could auto-detect a lot of boot loaders, so that it didn't need to be messed with in order to boot new OSes. I built on that ability in rEFInd, extending it to Linux kernels with EFI stub loaders. Thus, rEFInd can detect and boot a new kernel (stored under a new name) with no changes to its configuration file -- something that no other boot loader/manager for Linux can claim (except for rEFIt, with several caveats). Unless you're doing something really weird, it's almost always simpler to configure rEFInd to rely on auto-detection than to use manual boot stanzas.
The gummiboot configuration files can be simpler than the rEFInd ones in some ways, but gummiboot requires manual configuration for every kernel. This isn't so bad with Arch, which is unusual among Linux distributions in that it uses the same filename for every kernel, so that the boot loader configuration needn't be touched when upgrading the kernel.
This is not to disagree but I think grub's complexity is easily overstated. It can do all kinds of fancy stuff but it doesn't have to, and it is not that complicated to configure for simple stuff.
IMO, part of GRUB's problem is that there is so much complexity associated with the "fancy stuff... it doesn't have to" do. Even if you strip the grub.cfg file down to a bare-bones configuration, the complexity still lurks in the code, which means there's the potential to hide bugs. As a practical matter, most people rely on the grub-mkconfig script, which generates ridiculously complex and difficult-to-parse grub.cfg files. If you use a simpler hand-crafted grub.cfg file, then that helps matters, but considering typical use cases, GRUB falls down on this one.
EDIT 2: Note that I have a bias in favour of grub because it happens to work very, very reliably on my machine. Nothing else will even boot the damn thing. So simplicity is really beside the point. I don't want a 6 line config file for something which won't boot. If I relied on EFISTUB to boot, I'd still be on kernel 3.7.*!
Naturally; in your case the EFI stub loader isn't working, so you can't use rEFInd or gummiboot. You'll get no argument from me on this score.
]]>EDIT: It is not difficult to write grub.cfg manually. See this url for grub.cfg samples for x86_64 Archiso and Archboot booting. That should give you an idea.
]]>I went with Grub reluctantly, as it plays rather nicely with Xen. I would have much rather used gummiboot given the option.
]]>FWIW [including comments and blank lines]:
total lines in grub.cfg: 416
total lines in refind.conf + my custom conf: 475 [refind.conf is 408 but that's not a fair comparison since it isn't customised to my liking without the additional file]
This is not to disagree but I think grub's complexity is easily overstated. It can do all kinds of fancy stuff but it doesn't have to, and it is not that complicated to configure for simple stuff.
Note that all of my config files are much longer than they strictly need to be since I have numerous boot entries, for example, that I could easily do without if, for some reason, I decided that a shorter config file was desirable .
EDIT: Stripping blanks and comments:
grub.cfg: 292 for 23 entries
refind + custom .conf: 100 for 14 entries
But I only stripped comment lines with # as the first character and I have quite a lot of lines in the grub.cfg which are commented with white space before the # so it isn't really a fair comparison. I could get fewer lines by not setting up a bunch of common variables but that would be harder to maintain!
EDIT 2: Note that I have a bias in favour of grub because it happens to work very, very reliably on my machine. Nothing else will even boot the damn thing. So simplicity is really beside the point. I don't want a 6 line config file for something which won't boot. If I relied on EFISTUB to boot, I'd still be on kernel 3.7.*!
]]>Guess I just can't make sense of grub then, switching to syslinux.
After some investigation, I found that grub DOES allow booting from an LVM /boot partition: "Currently, only GRUB 2 can read a kernel from within an LVM or RAID setup" (Credit to srs5694).
Still haven't been able to make it work though. "Cannot find canonical path to /boot/efi"
IMHO, you're on the right path with the first quoted statement; GRUB is overly-complex and is the most difficult boot loader to configure. I don't happen to have GRUB configured for any Arch installation, but here are some line-length statistics for configuration files on an Ubuntu 12.04 setup, with comment lines and blank lines stripped out:
GRUB 2: 298 lines (in grub.cfg)
rEFInd: 29 lines (26 in refind.conf and 3 in /boot/refind_linux.conf)
gummiboot: 6 lines (4 in entry for Arch and 2 in loader/loader.conf)
In fairness to GRUB, those 298 lines were auto-generated by Ubuntu's configuration scripts; a hand-crafted grub.cfg file could be much shorter than that. If we're optimizing, though, the rEFInd total could be lower, too -- most of those 29 lines for refind.conf are devoted to disabled manual boot stanzas (they aren't technically commented out, which is why I counted them). Aside from the manual boot stanzas, just one line is used in refind.conf by default, and that setup is adequate for half or more of all systems. The gummiboot total would go up if multi-booting, but six lines is adequate for an Arch-only installation. Despite these hedges, I think these totals do say something about the configuration complexity of these boot managers. Certainly my it's been my observation that people who try to configure GRUB 2 by hand often have problems with it. Some people say they have an easier time of it after abandoning the automated tools like grub-mkconfig, but that requires a better understanding of the configuration file format.
]]>Still haven't been able to make it work though. "Cannot find canonical path to /boot/efi"
]]>Of course you can mount the ESP under /mnt. It is the ESP partition, that can not reside inside of the LVM. The fact that /mnt is a filesystem on LVM is irrelevant for any mounts below /mnt like /mnt/boot.
Ah, thanks for clearing that up. Guess I just can't make sense of grub then, switching to syslinux.
]]>