Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#34191 - [gummiboot] Avoiding unconditional execution of setup on install/upgrade

Attached to Project: Arch Linux
Opened by Gerardo Exequiel Pozzi (djgera) - Thursday, 07 March 2013, 02:00 GMT
Last edited by Tobias Powalowski (tpowa) - Friday, 04 September 2015, 17:45 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No


I think the step of installing gummiboot during package installation should not be done, leaving to the user such job manually, like with syslinux/grub. Maybe can be done, but should be conditionally, testing for presence of some file, like is done with syslinux, in our custom script.
I guess that this can causes issues (since it sets efivars) when installing gummiboot on chroot, for other usages like preparing live-isos.

Additional info:
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Friday, 04 September 2015, 17:45 GMT
Reason for closing:  Fixed
Comment by Tom Gundersen (tomegun) - Thursday, 07 March 2013, 04:54 GMT
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.
Comment by Tobias Powalowski (tpowa) - Thursday, 07 March 2013, 07:28 GMT
Also a problem with gummiboot install routine:
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 08 March 2013, 14:05 GMT
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
Comment by Pierre Schmitz (Pierre) - Friday, 08 March 2013, 18:01 GMT
"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.
Comment by Tom Gundersen (tomegun) - Saturday, 09 March 2013, 07:58 GMT
@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.
Comment by Tom Gundersen (tomegun) - Saturday, 09 March 2013, 07:59 GMT
@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...
Comment by Pierre Schmitz (Pierre) - Saturday, 09 March 2013, 08:27 GMT
@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: 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.
Comment by Andre "Osku" Schmidt (oskude) - Sunday, 21 April 2013, 10:24 GMT
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.
Comment by Keshav Amburay (the.ridikulus.rat) - Sunday, 03 November 2013, 06:24 GMT
@tomegun: How about using /boot/EFI/gummiboot/GUMMIBOOT_AUTOUPDATE control file similar to /boot/syslinux/SYSLINUX_AUTOUPDATE file used in syslinux pkg?
Comment by Francis Moreau (fmoreau) - Friday, 04 April 2014, 06:58 GMT
@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 ?

Comment by Francis Moreau (fmoreau) - Wednesday, 04 February 2015, 07:45 GMT
so, is this one finally ignored ?
Comment by Doug Newgard (Scimmia) - Tuesday, 07 July 2015, 14:51 GMT
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?
Comment by Francis Moreau (fmoreau) - Wednesday, 08 July 2015, 07:07 GMT
good news, go ahead. That's just a pity to see how long it took.
Comment by Tobias Powalowski (tpowa) - Friday, 04 September 2015, 17:45 GMT
Gummiboot removed from core, systemd-boot is the successor which does not install itself on update.