FS#39216 - [gummiboot] gummy boot shouldn't be installed/updated during package installation/update

Attached to Project: Arch Linux
Opened by Francis Moreau (fmoreau) - Friday, 07 March 2014, 11:37 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Thursday, 03 April 2014, 23:52 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

During gummiboot package installation or update, gummiboot is always installed on the ESP partition (with the default value '/boot') and EFI variables are updated. This is due to the post_install() and post_upgrade() defined for this package that always runs "/usr/bin/gummiboot update".

There're several issues by doing that:

- the path to ESP must be /boot so user can't customize ESP path
- an entry in EFI variables is always created which can be a problem when installing gummiboot in a chroot for testing purpose for example

And even if the user undo the default values, they're restored during package upgrade.

Would it be possible to not install gummiboot during the package installation/upgrade.

One odd thing is that during package installation, post_install() suggests to run "gummiboot install" whereas it previously run "gummiboot update".
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Thursday, 03 April 2014, 23:52 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#34191 
Comment by Matthias Dienstbier (fs4000) - Friday, 07 March 2014, 23:56 GMT
post_install says "Run '/usr/bin/gummiboot install' to make gummiboot your default bootloader". Unlike 'gummiboot update' this will make gummiboot the default bootloader. There might be situations where gummiboot should not install itself automatically on install, but it should call the update command in post_upgrade().
Comment by Francis Moreau (fmoreau) - Sunday, 09 March 2014, 06:43 GMT
Running "gummiboot install/update" will both create a new entry in the EFI's boot menu and I don't think we should do that, there're case where we don't want to: for example when creating a disk image.

Note that running "gummyboot update" also creates a new entry in the EFI's boot menu if it didn't already exist. And it also make it the default bootloader in that case since it obviously will be the first and only one entry to boot.

Also (cf my questions in my initial report) how can one customize the path installation for example ? If one still try to customize the path, isn't it going to be ignored during next gummiboot package upgrade ?

I think currently no other bootloader (grub, syslinux) are installed automatically during the package installation/upgrade, they require manual installation.
Comment by Tom Gundersen (tomegun) - Sunday, 09 March 2014, 11:30 GMT
The difference between "update" and "install" is in the case you don't have gummiboot installed already, but you have some other bootloader. In that case "update" will install gummiboot with the lowest priority and "install" will install it with the highest priority.

If /boot in the root you are installing to is not the ESP, we should not be installing anything (as in a chroot). Is this not the case?
Comment by Francis Moreau (fmoreau) - Sunday, 09 March 2014, 13:18 GMT
No this is not the case, installing gummyboot in a disk image (mounted through a loopdev) will update EFI boot entries of the *host* and that's not what we should do, I think.

Also please, there're several questions that you haven't answered.
Comment by Mateus Rodrigues Costa (CharlesAtum) - Thursday, 13 March 2014, 18:15 GMT
I think I got what he thinks the .install file should do.

I am not sure how flexible these .install files are, or if there's an variable with the value for the ESP, but here are the two ways I think the .install file could handle it:

1. Check if /boot is the ESP. If it is, then run all the commands as normal. If it isn't, then show a message telling the user to run the command manually with the --path option set to his ESP.

2. If there is a variable with the ESP mount path we use it, if there isn't we try to guess where it is mounted (Not sure how you would do it though, maybe check if /boot is FAT and has the GPT type and, if not, then fallback to /boot/efi?) and store it to a variable. Then we run the gummiboot commands with the path set to this variable.

I didn't get the problem with the disk image, can you explain it again? Is it something about after installing the gummiboot package it automatically running the install command while you would to run it manually adding the --no-variables option?

Loading...