NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
17.62k stars 13.77k forks source link

Unable to run Grub2 on Apple Mac machines #30795

Open ylwghst opened 6 years ago

ylwghst commented 6 years ago

Issue description

Grub 2 doesn't run after it's built on Mac. I wasn't able to run grub2 on my Apple MacBook Mid 2010.

After successful fresh NixOS install using nixos-install with only grub2 boot loader declared in configuration.nix there is no boot option to select partition with grub2 installed after reboot while holding option key. Grub2 files are present in /boot but the default apple bootloader can't run grubx64.efi. I'm not able to get in NixOS.

I can still use thee systemd-boot which works properly. If I declare only systemd-boot before the nixos-install process then successfully build, systemd-boot partition will be visible in default apple bootloader menu. I can select it and boot into systemd-bootloader and then into NixOS.

If decide to try install grub2 again from already running NixOS by changing the configuration.nix where I remove systemd-bootloader and declare only grub2 it will properly install all grub2 files in to /boot. After build systemd-boot files will remain in /boot too. The machine will still show a nixos boot partition in the default apple bootloader and I'm able to select it however it will run systemd-boot, not grub2.

NVRAM EFI variables (efibootmgr) are always properly changed during the build process. As I was experimenting the order or any other settings of boot nums doesn't really have any effect on Apple Mac machines. The Mac will always boot first the apple default firmware bootloader which has its own partition. User can then select which partition wants to boot. A partition with OS X or partition with another efi bootloader installed.

Why Grub2 doesn't run?

Mac completely ignores how EFI system variables are set (boot order).

Mac is starting .efi from this location

/boot/EFI/BOOT/BOOTX64.efi

The Grub2 is installed only into

/boot/EFI/grub/grubx64.efi

If I copy grubx64.efi into /boot/EFI/BOOT/ and change it's name then It will properly load grub2 after I select the partition from apple default bootloader

sudo cp /boot/EFI/grub/grubx64.efi /boot/EFI/BOOT/BOOTX64.efi

with all it's files and configurations located in

/boot/grub

How can I get Grub2 work? How should I build it?

On Mac platform it's necessary to include this in your configuration.nix:

boot.loader.grub.efiInstallAsRemovable = true;

If you turn this feature on, GRUB will install itself in a special location within efiSysMountPoint (namely EFI/boot/boot$arch.efi) which the firmwares are hardcoded to try first, regardless of NVRAM EFI variables.

Sample configuration:

boot.loader.grub = {
     enable = true;
     efiSupport = true;
     efiInstallAsRemovable = true;
     device = "yourbootdevicehere";
  }; 

Have you experienced same problem while installing grub2 on Mac? Please leave a commnet.

Steps to reproduce on Apple Mac

  1. Run NixOS live-cd
  2. Declare grub2 boot loader in configuration.nix
  3. Build with nixos-install
  4. Try boot into new installation.

or

  1. Run NixOS live-cd
  2. Declare systemd boot loader in configuration.nix
  3. Build with nixos-install
  4. Boot into new nixos-installation
  5. Remove systemd-boot from configuration.nix
  6. Declare grub2-bootloader instead.
  7. Build with nixos-rebuild
  8. Try boot into grub2

Technical details

bjornfor commented 6 years ago

Have you tried with boot.loader.grub.efiInstallAsRemovable = true?

ylwghst commented 6 years ago

I haven't, according to description:

If you turn this feature on, GRUB will install itself in a special location within efiSysMountPoint (namely EFI/boot/boot$arch.efi) which the firmwares are hardcoded to try first, regardless of NVRAM EFI variables.

It looks like solution of this issue is done already. I will give it try asap.

/// Definitely this works well.

Mac completely ignores how EFI system variables are set. Grub2 should be always installed in EFI/boot/boot$arch.efi

Systemd-boot creates both EFI/boot/boot$arch.efi and /boot/EFI/systemd/systemd-bootx64.efi

Should we improve grub2 build the same way? Force it to create copy in EFI/boot/boot$arch.efi as fallback for Mac computers or computers with similar behavior?

stale[bot] commented 4 years ago

Stale bot information

Suggestions for PRs

  1. GitHub sometimes doesn't notify people who commented / reviewed a PR previously, when you (force) push commits. If you have addressed the reviews you can officially ask for a review from those who commented to you or anyone else.
  2. If it is unfinished but you plan to finish it, please mark it as a draft.
  3. If you don't expect to work on it any time soon, closing it with a short comment may encourage someone else to pick up your work.
  4. To get things rolling again, rebase the PR against the target branch and address valid comments.
  5. If you need a review to move forward, ask in the Discourse thread for PRs that need help.
  6. If all you need is a merge, check the git history to find and request reviews from people who usually merge related contributions.

Suggestions for issues

  1. If it is resolved (either for you personally, or in general), please consider closing it.
  2. If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
  3. If you still have interest in resolving it, try to ping somebody who you believe might have an interest in the topic. Consider discussing the problem in our Discourse Forum.
  4. As with all open source projects, your best option is to submit a Pull Request that addresses this issue. We :heart: this attitude!

Memorandum on closing issues

Don't be afraid to close an issue that holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

Useful GitHub search queries

samueldr commented 1 year ago

Hi :wave:,

A bit of a necro-bump, but let's try answering this:

Should we [make] grub2 [...] create [a] copy in EFI/boot/boot$arch.efi as fallback? [Following what systemd-boot does]

(I took the liberty of distilling the question)

First, whatever the decision is here, it shouldn't be a grub-only thing. There is work being done into unifying the semantics of the different bootloadery bits. Though the question is still relevant:

Do we install to the fallback location by default?

The answer is: It depends on whether or not we follow the UEFI spec faithfully or not by default.

An EFI system partition that is present on a hard disk must contain an EFI defined directory in the root directory. All OS loaders and applications will be stored in subdirectories below EFI. The choice of the subdirectory name is up to the vendor, but all vendors must pick names that do not collide with any other vendor’s subdirectory name. This applies to [...] operating system vendors [...] and third party tool vendors, or any other vendor that wishes to install files on an EFI system partition. There may also be an optional vendor subdirectory called BOOT. — 13.3.1.3 Directory Structure

Currently, AFAICT systemd-boot via bootctl install may not be entirely compliant as it will install to /EFI/BOOT also. It is unclear by the spec when an OS vendor can use /EFI/BOOT other than on a removable media. (It is registered to Unified EFI Forum, Inc. Especially when considering must pick names that do not collide with any other vendor’s subdirectory name”. If any two vendors choose to use the default fallback location, it will conflict.

The whole goal here is that multiple operating systems must be able to co-exist. But with that said, the way that systemd-boot does it, it would conflict with anything else assuming this can be used, which may or may not be an issue. (The bootctl install command will AFAICT always replace the fallback bootloader location.)

So my opinion here is that no it shouldn't be the default, for any bootloader, but that yes, there should be a single option to turn on, and maybe better suggested for "if there are any issues booting".

IMO usage of /EFI/BOOT should be reserved to a user's conscious choice. Or at the very least never replaced (unless it is verifiably "owned" by the the vendor doing an update).

cc @RaitoBezarius for lanzaboote considerations