I wrote the PKGBUILD, so here is the reply:

1. /boot/efi has been the standard mountpoint for EFISYS partition ever since the first linux came out for Intel Itanium (which supported only EFI 1.x, no BIOS). So this is a very valid assumption. Having /boot itself as EFISYS may work, but it restricts choice of FS for /boot to be vfat and we don't know whether problems can occur. Since most of the x86 distros have agreed to go /boot/efi way, I do not want to project /boot itself as EFISYS. I persinally want to keep /boot and EFISYS separate.

2. The config files are there as examples. The kernel paths and parameters in them are just for example. The files are there just to show wherein EFISYS the files should be present, for gummiboot to find them and the format of the file contents. It is assumed that the user has already read some info about gummiboot and it is assumed that the USER WILL COPY THE KERNEL TO EFISYS AND MODIFY THE CONFIG FILES ACCORDINGLY. I don't want to clutter the post_install output with this info, since this is uncerstood.

3. <See 2.>. Again they are just for example, you can put rootfstype=XXX if you want

4. EFISYS should be vfat formatted, so dosfstools is required (standard for all UEFI bootloaders). Without efibootmgr there is no way (from within linux) to inform the fimware about gummiboot and add it to the firmware boot menu. So it should be depends.

5. My mistake, I adapted the PKGBUILD from my -git one.

6. "make clean" removes any pre-compiled or half baked files which may give incorrect output at the end (*.efi files). So it is run. This may not be required in case you create fresh chroots when building, but no harm done in running it. I added "echo" so that i can see where output of one command ends and the next begins. It is difficult to debug when the output scrolls continuously. It is upto the dev to keep "echo" or delete it, but i add "echo" in all my PKGBUILDs just for fun.

7. Regarding installing to /usr/lib , I think that would be good idea, not for /boot vs /boot/efi thingy, but doing that will ensure, when a package is removed, only files in /usr/lib is removed and the actual bootloader files at /boot/efi are not removed, then not rending system unbootable. That is one of the reasons why syslinux and grub files are installed to /usr/lib , the other bring that how upstream build system does it (in gummiboot, refind etc. there is no "make install" command to setup such things"

Anyway I have sent tpowa another set of PKGBUILDs which combine gummiboot-efi-{x86_64,i386} into one. I may incorporate /usr/lib change and other related changes. But to summarise /boot/efi is the standard presently.

> Having /boot itself as EFISYS may work, but it restricts choice of FS for /boot to be vfat and we don't know whether problems can occur.
There is no problem with this. Files in /boot are read in an environment where basic filesystem features like ownership or permissions are completely irrelevant.

> I don't want to clutter the post_install output with this info, since this is uncerstood.
Understood? By who, you? There's clearly already confusion about /boot v. /boot/efi.

> 6. "make clean" removes any pre-compiled or half baked files which may give incorrect output at the end (*.efi files).
Don't you think this is something you should talk to upstream about? If they're shipping garbage, as you claim, I'm sure they'd like to know about it.

> Anyway I have sent tpowa another set of PKGBUILDs which combine gummiboot-efi-{x86_64,i386} into one.
You couldn't include it here? I'd like to review the new PKGBUILD, and I'm sure Mantas would like to see it as well.

This sort of maintainer by proxy is a little more than strange...

I removed gummiboot from extra until all things are sorted out.

During the brief period that gummiboot was in Extra yesterday I tested it and could absolutely *not* get it working, where the AUR gummiboot-efi-x86_64 works fine. If this is not a drop in replacement for that package I'd recommend that whomever is actually the maintainer on this draft a revision to the gummiboot wiki page. I'll retest when it's back in Extra, but my experience yesterday led me to believe that it had problems, fwiw.

Opinion on /boot vs /boot/efi: I'd like to see this work with a plain /boot path. EFI with gummiboot is very clean. Allowing /boot would simplify things further. Why complicate matters by requiring /boot/efi?

Also, I assume it was an error that gummiboot was in $esp/EFI/arch/gummiboot/ (that should be $esp/EFI/gummiboot/ , no?)

Sorry for all the confusion. I have made some changes to the PKGBUILD. Please review them. I may not reply fast as I am travelling. I couldn't upload the last time I replied because I had booted into Windows at that time. I used "make clean" in my -git PKGBUILD and forgot to remove it in the non-git one. Anyway "make clean" and "echo" are minor stuff (which i have removed form the attached files).

I have combined 32-bit and 64-bit UEFI gnu-efi libs into one package (in x86_64 system only). With this package it is possible to build even 32-bit UEFI apps in x86_64 system. The gummiboot-efi PKGBUILD builds both 32-bit and 64-bit UEFI app of gummiboot (installed at /usr/lib/gummiboot). Please review the post_install message also.

Out of curiosity, how many 32-bit UEFI systems actually exist, and run Arch?

Ethan: Actually the spec says that /EFI/arch/ (or a subdirectory) would be correct, since the package is installed by Arch... My own system uses /EFI/gummiboot/ because Gummiboot is self-contained -- it doesn't depend on Arch being installed (unlike, e.g., GRUB2) and could be shared nicely with other distros; I seem to remember that being one of the design goals.

Keshav: I think you could remove the first two `sed`'s by using `make CFLAGS=... ARCH=... LIBDIR=...` instead of passing them in the environment.

Mantas: does that mean that /EFI/arch/gummiboot is mandatory or just recommended? If not, but if this package will use /EFI/arch/gummiboot as the new default install location, then as long as it's a trivial PKGBUILD edit at install time, I'd roll with that. I'd encourage the maintainer to include a comment to that effect in the PKGBUILD itself as well as the wiki.

Conforming to the EFI spec always seems like a sysiphean task.

Ethan: Hmm, actually I can't seem to find anything other than "\EFI\BOOT\BOOT<arch>.EFI" in the main spec ("Unified Extensible Firmware Interface Specification Version 2.3.1"). Maybe I was just imagining things about it being a requirement.

(There is a registry of subdirectories, though: http://www.uefi.org/specs/esp_registry#)

Interesting. Out of scope for this thread, but I wonder if Arch should register on that list.

@grawity: "make CFLAGS=... ARCH=... LIBDIR=..." does not work for some reason. But "CFLAGS=... ARCH=... LIBDIR=... make" works. So I am retaining the sed and passing the values in the env.

@altercation: See http://rodsbooks.com/refind/linux.html (end of the page - Tip for distribution maintainers section) for explanation why /EFI/arch/gummiboot was used as the install location.

I have made slight changes to the PKGBUILDs to remove unwanted variables. I have attached PKGBUILDs of gnu-efi-libs, gummiboot-efi, refind-efi and efilinux-efi (precursor to EFISTUB, required for booting non-EFISTUB LTS kernels using gummiboot/refind, used by archboot iso).

gnu-efi-libs requires lib32-glibc while building i386 UEFI libs, but not while installing it.. But gummiboot-efi, refind-efi and efilinux-efi require only gnu-efi-libs, not lib32-glibc while building.