Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve EFI bootloader installation #2312

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

HTV04
Copy link
Contributor

@HTV04 HTV04 commented Dec 24, 2023

PR Description:

Some improvements to the installation of bootloaders on devices with UEFI:

  • GRUB:
    • Adjusted the grub-install parameters
      • Disabled the --bootloader-id option, using the default grub instead
      • Disabled the --debug option, which prints a lot of unnecessary info and may enable a debug flag
      • Disabled the --removable option, which prevents an EFI entry from being created
        • The other functionality of this option, setting the destination EFI file to the standard /EFI/BOOT/BOOTxxx.EFI/, has been implemented manually
  • Limine:
    • An EFI entry is now added via efibootmgr
  • EFISTUB
    • Code clarity tweaks
  • All bootloaders:
    • Like GRUB, all bootloaders will now attempt to install again upon failure to assist with buggy EFIs
      • After two failed attempts, the installer will attempt to use a fallback without EFI variables; if this fails, the installer will error out
    • Added a few debug messages for silent errors

Tests and Checks

  • I have tested the code!

@HTV04 HTV04 requested a review from Torxed as a code owner December 24, 2023 19:22
@HTV04 HTV04 force-pushed the efi-install branch 2 times, most recently from 752b9da to 19b8d90 Compare December 24, 2023 19:38
@vanillaSprinkles
Copy link

vanillaSprinkles commented Mar 5, 2024

would it be possible to give the user a prompt, upon ultimate failure, to abort advancing on the entirety of the archinstall scripts, or to continue with a potentially failed grub-install? (or check for an archinstall flag to allow prompt/silent mode or something) - suggested grub-install errors as a my example in #2378

edit; i tested this on an ipxe'd bios-install and it has still failed (dropped it on top of the current installer.py, did not check for rebase'ing ect) ( it = https://github.com/archlinux/archinstall/blob/5b9574d3acbe5a106543e16d5cc02e1ed860d7b1/archinstall/lib/installer.py )

@Torxed
Copy link
Member

Torxed commented Mar 7, 2024

Awesome work, I'd like to marge this.
I'm wondering if we'll bring back this tho: #793

@HTV04
Copy link
Contributor Author

HTV04 commented Mar 10, 2024

Awesome work, I'd like to marge this. I'm wondering if we'll bring back this tho: #793

I believe that "fixed" the issue because it prevented grub-install from adding the EFI entry in the first place. The removable flag treats the destination as a removable drive, only adding a standard BOOTX64.EFI file.

Also, this PR might actually fix that issue due to automatically retrying the installation upon such an error.

@HTV04
Copy link
Contributor Author

HTV04 commented Mar 10, 2024

would it be possible to give the user a prompt, upon ultimate failure, to abort advancing on the entirety of the archinstall scripts, or to continue with a potentially failed grub-install? (or check for an archinstall flag to allow prompt/silent mode or something) - suggested grub-install errors as a my example in #2378

edit; i tested this on an ipxe'd bios-install and it has still failed (dropped it on top of the current installer.py, did not check for rebase'ing ect) ( it = https://github.com/archlinux/archinstall/blob/5b9574d3acbe5a106543e16d5cc02e1ed860d7b1/archinstall/lib/installer.py )

I could try, but it would make the installation process less "automatic." This might be in the scope of a future PR to handle common errors during installation.

@Torxed
Copy link
Member

Torxed commented Mar 10, 2024

I could never get a hold of hardware that could trigger the error.
I'm totally fine adding in this PR considering the try/except which should fallback to trying.

And now that we know about the issue, if it comes back we could add back this flag.

@vanillaSprinkles
Copy link

im wondering now if adding different behaviors for each type of error would be useful? for example for my "fun" hardware the efibootmgr can fail but is not an issue due to having to teak the bios manually anyways; and skipping it by adding --no-nvram to grub-install might be useful (something like that is where a user-prompt maybe okay vs auto-skip (or the never ending add-more-flags/inputs))

@Torxed
Copy link
Member

Torxed commented Mar 12, 2024

Those checks and tweaks would improve reliability if nothing else, and it's a godsend if we could get there. Because this and disk operations have always been a painpoint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants