Arch Linux

The situation is different from syslinux for a couple of reasons. Firstly, if you are not on an EFI system, or if your ESP is not mounted at /boot the installation is aborted (I suppose in an chroot you would not mount the host ESP on /boot unless you actually also wanted to set the EFI variables?). Secondly, even when the installation succeeds it will not overwrite the other boot loaders you might have installed (which is not possible for syslinux as you can only have one BIOS boot loader at a time) and it will not change their EFI variables.

The only possible negative side effect (that i'm aware of at least) of calling "gummiboot install" is that gummiboot will change the boot-order and insert itself with the highest priority (when using "update" instead it will use the lowest priority). If anyone can think of a use-case where this poses a problem so that it is not the correct default for package install, we should discuss how to work around it (but the change should be made upstream to the gummiboot installer, possibly as a new "package-install" verb).

The reason I hesitate to follow syslinux is that it would be nice if we were able to avoid having to require any user action to set up the boot loader: just mount the ESP at /mnt/boot before calling pacstrap, and everything will "just work". This still requires some work to get the kernels installed correctly, but that should happen soon.

Also a problem with gummiboot install routine:
https://bbs.archlinux.org/viewtopic.php?pid=1240322#p1240322

Beyond technical points, I think this breaks one of the nice features of Arch packages: "they does not touch any configuration file from, let user edit yourself" (sure, this applies to a greater or lesser degree depending on the type of change made). But it this case it touches the "system", maybe you might want to pass --no-variables to the gummiboot setup.

I imagine another scenario where EFI firmware implementation gets crazy because of touching efivars. For example, I heard about efibootmgr bricks some Macs, who knows, firmware level is an esoteric world :P

"gummiboot update/install" kind of broke things here. It even manged to freeze the system to a point where I had to pull the plug (sysrq did not work). A BIOS reset did not fix it and there is still something wrong with my EFI. efibootmgr shows different things than the BIOS menu and gummiboot install/update now fails with "Failed to create EFI Boot variable entry: No such file or directory"

Log story short: I would classify gummiboot as pretty dangerous to use atm. Maybe call it with "--no-variables". Right now a lot of EFI implementations seem to be very buggy.

@Tobias: that's an interesting discussion, I'll follow up on it. However, I'm not really sure if I see what problems you refer to? As far as I know everything currently works as intended.

@Gerardo: Ok, after thinking about it I agree that we should not make gummiboot the default boot loader on install. I do think, however, that it would make sense to set up the EFI and set gummiboot as the lowest priority. I'll take that upstream.

To make an analogy with systemd a systemd service: After installing a daemon, it can be started manually, or pulled in as a dependency but manual action is needed to start it by default. Similarly, after installing gummiboot, it should be possible to start gummiboot from the boot menu manually, and if no other boot loader is installed gummiboot should be used. However, to be used by default the admin should take manual action.

For now (in testing), I simply disabled the "gummiboot install" action. We can revisit adding "gummiboot install-fallback" or something along those lines after it gets added upstream (assuming it does).

@Pierre: there are lots of issues with the kernels implementation of EFI variables in 3.8. If you are using 3.8.2, that explains the "No such file or directory", the mounting of efivarfs simply fails on that kernel. As to the hang, that is likely due to using gummiboot (/sys/firmware/efi/efivars) and efibootmgr (/sys/firmware/efi/vars) without rebooting inbetween. Yeah, this is retarded, but the kernel has these two ways of accessing the efi variables and does not keep them in sync (if I understand it correctly).

Not really much we can do about that though... Except maybe disabling /sys/firmware/efi/vars, but that would break efibootmgr unless that is updated to the new interface.

@Pierre: to be clear, avoiding writing to the EFI vars during install does not solve any of these (many) problems as the admin will have to do it anyway...

@Tom: I got it working again with 3.8.2. But I had to reflash my BIOS; resetting to default values did not help. So maybe the kernel wrote something it should not have.

I did not know about the conflicting API in the kernel and that efibootmgr and gummiboot use different ones, but that makes things worse.

Here is the only thing that got logged: http://paste.xinu.at/RzveFF/ It printed way more on the console, but that was never written into the journal.

I guess the general Take-Home-Message here is to be careful if you deal with UEFI, not just gummiboot. So there is probably not much we can do at the packaging level.

yes, please remove these from gummiboot.install:

`mkdir -p /boot/EFI/gummiboot`
cause it pollutes my /boot and i want only one copy of uefi bootloader at /boot/efi/boot/bootx64.efi (eg. i do it manually)

`/usr/bin/gummiboot update`
cause it pollutes efi variables (where possible) and in case of qemu+ovmf not even needed nor working (the variables are not stored or read, dunno). and according to man page, `gummiboot update` would overwrite /boot/efi/boot/bootx64.efi without questions and maybe i installed gummiboot just to read its man page.

@tomegun: How about using /boot/EFI/gummiboot/GUMMIBOOT_AUTOUPDATE control file similar to /boot/syslinux/SYSLINUX_AUTOUPDATE file used in syslinux pkg?

@tomegun: could you please at least take a look at what other distro do during gummiboot installation since you seem to fail to understand why a lot of people don't want gummiboot to blindly install itself in /boot and update the EFI boot manager ?

Maybe that could give you a hint ?

Thanks

so, is this one finally ignored ?

Gummiboot has been obsoleted by systemd-boot. The systemd package doesn't automatically install it in the install script. Can we call this one fixed?

good news, go ahead. That's just a pity to see how long it took.

Gummiboot removed from core, systemd-boot is the successor which does not install itself on update.