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

installer: Makes iso image compatible with *wrong* UEFI. #35528

Closed
wants to merge 1 commit into from

Conversation

samueldr
Copy link
Member

Motivation for this change

This change will help users with arguably broken UEFI implementations.
It has been reported that at least one specific motherboard has this
problem, and that other motherboards can exhibit the same behaviour.

Those UEFI implementations are not following the spec with regard to the
autodetection:

The format of the file path is defined as <EFI_SYSTEM_PARTITION>/EFI/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI;

Those boards will, instead, try to boot the default location of windows'
UEFI bootloader

/EFI/Microsoft/Boot/bootmgfw.efi

This change only affects the installation media. It may be necessary
to document the caveat that some (older?) motherboards exhibit such
behaviour, possibly on the users' wiki; users of such computers may want
to install a secondary bootloader like rEFInd, or copy the bootloader
installed by NixOS to that location after their successful installation.

See:

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

I couldn't verify whether the installer would boot on such hardware, but the file is at the expected location.

This change will help users with arguably broken UEFI implementations.
It has been reported that at least one specific motherboard has this
problem, and that other motherboards can exhibit the same behaviour.

Those UEFI implementations are not following the spec with regard to the
autodetection:

> The format of the file path is defined as `<EFI_SYSTEM_PARTITION>/EFI/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI`;

Those boards will, instead, try to boot the default location of windows'
UEFI bootloader

> `/EFI/Microsoft/Boot/bootmgfw.efi`

This change *only affects the installation media*. It may be necessary
to document the caveat that some (older?) motherboards exhibit such
behaviour, possibly on the users' wiki; users of such computers may want
to install a secondary bootloader like rEFInd, or copy the bootloader
installed by NixOS to that location after their successful installation.

See:

  * https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#UEFI_boot_loader_does_not_show_up_in_firmware_menu
  * https://logs.nix.samueldr.com/nixos/2018-02-25#1519530841-1519530628;
@bjornfor
Copy link
Contributor

If I understand this correctly, I think it will be very confusing to have the NixOS installation medium be able to boot, but not the final installation.

IMHO, users must complain to the motherboard manufacturer and have them fix this bug.

@samueldr
Copy link
Member Author

samueldr commented Feb 25, 2018

Sure, this will be confusing, but it will make it possible to boot the installation media in UEFI mode for those users.

This could be either:

  1. Merged as-is and then do what's proposed next.
  2. Wait until what's proposed next is implemented.

Ideally, what would happen is that the bootloader would use a different configuration when booted using that specific path, or somehow detect it was booted using this specific path. Then, it would be possible to add a parameter to the kernel, which in turn could be used in nixos-generate-config to add a (commented by default) line in hardware-configuration.nix, which would in turn let the bootloader install process install at that location if desired.

For this particular issue, there is no good one-size-fits-all solution as some users will be fine having NixOS' bootloader installed as the only boot option, some will want to to their own things, some would prefer to try to keep dual-boot working.


In the end, we cannot realistically hope motherboard manufacturers to fix firmwares. Buggy UEFI seem to be, sadly, the norm. This is especially true considering those motherboards are older, in this particular specimen, 2013.

I mean, from anecdotal evidence, the only updates manufacturers do are for about a year or two after the release, and seem to change actually nothing. Once it's over that time, even if the part is still sold new, I have been told before that there won't be any more update as it's unsupported 😕.


Alternatively, since I know this isn't necessarily the "cleanest" solution for anything, adding fixes for real-world warts, it may be enough to recomment a custom build of an USB image, using rEFInd, which also adds that rEFInd at that location. (The upstream usb image for rEFInd doesn't provide a program at that location.) This could be distributed and documented somewhere in the doc, just as rEFInd is documented as useful for CD booting in UEFI mode.

This may be a safer bet, since it will allow booting the now-installed-but-inaccessible installation of NixOS using that USB drive. (And it may help fixing boot issues in other situations.)

@samueldr
Copy link
Member Author

Closing.

I'm thinking that this should be attempted, but only if the installer image can know about the situation. This probably means doing some EFI shenanigans (another loader+config which appends information to the kernel command line) so the installer can then warn and/or (through nixos-generate-config) setup a config option for this particularly bad behaviour.

@samueldr samueldr closed this Aug 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants