How do I get the grub menu to show on a MacBook?

Question

I've installed Ubuntu 19.10 on my MacBook (Mid-2010 a.k.a. Macbook7,1) as the only OS. Right now my system is working but it has a few issues. One of those issues is that I can't seem to get GRUB to show a menu no matter what I do. Right now, this is what my /etc/default/grub file contains:

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
GRUB_GFXMODE=auto

When my computer boots, I see a non-blinking _ symbol for about 5 seconds and then I see the normal kernel output that you seen when Ubuntu starts booting. If I press the ESC key when the _ is showing, the boot will not continue and the screen is stuck like that until I forcibly power down the system by holding the power button.

A clue that I have noticed is that the grub menu works perfectly fine when booting from the USB installer. I've looked at the grub.cfg on the USB installer, and it has this line which seems absent from /boot/grub/grub.cfg on my Ubuntu install: insmod efi_gop

So given this info, how do I configure GRUB to show a menu?

Yuri Sucupira · Answer 1 · 2021-08-27T02:27:49.080

SHORT ANSWER

This workaround worked on my 13" Apple Macbook Pro mid-2009 running 64-bit XUbuntu 20.04:

Create a LiveCD of the *Ubuntu (i.e. Ubuntu, XUbuntu, KUbuntu...) distribution just in case.
Delete the shim*.efi file located at /boot/efi/EFI/ubuntu/
Use APT to purge (i.e. completely uninstall) the shim DEB packages (shim and shim-signed) from the system.
Delete the grub folder located at /boot
Install GRUB again (i.e. perform a "fresh" or "clean" GRUB install with a command such as grub-install /dev/sda ; grub-install --recheck).
Fix GRUB's default settings at /etc/default/grub in order to [1] activate GRUB's console mode and [2] force GRUB to show its menu for 3 seconds, under such console mode. You do this by basically setting GRUB_TIMEOUT_STYLE=menu, GRUB_TIMEOUT=3 and GRUB_TERMINAL=console in /etc/default/grub.
Run sudo update-grub so these fixed default settings are applied to the "fresh" GRUB install.
Run efibootmgr in order to make sure that ubuntu (i.e. grubia32.efi or grubx64.efi, created and stored at /boot/efi/EFI/ubuntu) still is the default EFI boot loader option.
Reboot the system.
Boot from the LiveCD in case of problem.

(VERY) LONG ANSWER: HOW TO PERFORM THE ABOVE PROCEDURES

CREATE THE LIVECD.

There are several ways to create a LiveCD. The most basic ones, in my opinion, consist of downloading the *Ubuntu LiveCD .iso file (e.g. ubuntu-20.04-amd64.iso) and then either using UNetbootin to burn it into a USB stick (flashdrive) or (if you have access to a Linux shell terminal such as bash) using dd to burn such .iso file into any external media (USB stick, writeable CD-ROM etc.). The answers to this question provide a quite detailed set of procedures about it.
DELETE THE SHIM EFI FILES.

Once you've created your LiveCD and tested it to make sure that it's going to work if you happen to need it, open a shell terminal emulation window (CtrlAltT is a shortcut to it, but you can also run it from the Applications panel/menu or right-click a free area in the Desktop and then select the Terminal option) and then run sudo su in the terminal so you become the root user. Becoming root will spare you from having to use sudo on every shell command from this point on. After becoming root, delete the shim*.efi file (e.g. shimia32.efi for 32-bit systems, shimx64.efi for 64-bit systems) that is probably located at /boot/efi/EFI/ubuntu. Assuming that the shim .efi file is indeed located at /boot/efi/EFI/ubuntu, it can be deleted by running this command in the terminal:
```
 rm /boot/efi/EFI/ubuntu/shim*.efi
```
- If the EFI partition isn't mounted, the command mount /boot/efi will likely mount it. If such command doesn't mount it, run lsblk -o NAME,FSTYPE,MOUNTPOINT,PARTLABEL |grep -i efi to find your EFI partition (e.g. /dev/sda1) and then mount it (e.g. mount /dev/sda1 /boot/efi). If the /boot/efi mount point does not exist, create it with the command mkdir -p /boot/efi and then mount the EFI partition at it (e.g. mount /dev/sda1 /boot/efi).
- Furthermore, once such EFI partition is mounted at /boot/efi, and assuming that the shim .efi file is at /boot/efi/EFI/ubuntu, a command like thunar /boot/efi/EFI/ubuntu or nautilus /boot/efi/EFI/ubuntu (depending on which file manager your system uses) will give you root access to such folder (e.g. /boot/efi/EFI/ubuntu) directly from your file manager (windowed interface): this makes it easier to browse, find and then delete the shim .efi file (e.g. shimx64.efi).
- *WARNING* If you're connected as root and accidentally delete the wrong file, such file is lost forever (it does not go to the trash bin). It's therefore advised that you pay a lot of attention on what you're doing so you don't end up rendering your operating system unusable/inaccessible.
- In case you're wondering why you should delete the shim .efi file (i.e. the 32-bit shimia32.efi file or the 64-bit shimx64.efi file): GRUB's .efi file (i.e. the 32-bit grubia32.efi file or the 64-bit grubx64.efi file) is the appropriate one to use on a computer where Secure Boot is disabled. The shim version actually just provides a signed version of the GRUB .efi file version (because Secure Boot requires such signed version). But if you install *Ubuntu on a Mac with disabled Secure Boot (which is the frequent case), *Ubuntu adds the shim EFI file as the default option even though the Mac's firmware tells the bootlader to load the unsecure GRUB EFI file. So the solution is to delete the shim (Secure Boot) EFI file and then make the GRUB (non-Secure Boot) EFI file the new default one that must "interact" with the Mac's hardware at boot time.
PURGE THE SHIM DEB PACKAGES.

After you delete the shim .efi file that was located at e.g. /boot/efi/EFI/ubuntu, run APT to purge the shim DEB packages and therefore prevent future shim updates from creating the problematic .efi file again:
```
apt-get purge shim shim-signed --allow-remove-essential -y
```
DELETE THE GRUB FOLDER.

Now that you're rid of shim, it's time to get rid of GRUB: go back to your file manager window (e.g. Nautilus, Thunar...) and delete the grub folder that is likely located at /boot. If you don't find the grub folder in /boot, run the command updatedb ; locate -i grubenv to find the location of the grubenv file: this file is stored at the grub folder, thus if you find the location of the grubenv file you find the location of the grub folder.
- If you prefer to delete the grub folder from the terminal (assuming that it's located at /boot), just run:
```
rm -r /boot/grub
```
  ...and the grub folder will be deleted.
INSTALL A "FRESH" COPY OF GRUB.

Assuming that GRUB was installed in your first SATA storage drive (i.e. sda), install it back there by running this command:
```
grub-install /dev/sda ; grub-install --recheck
```
If your EFI partition is located at e.g. sda (e.g. /dev/sda1), it's common practice to install GRUB in /dev/sda. If your EFI partition is located at e.g. sdb (e.g. /dev/sdb1), it's common practice to install GRUB in /dev/sdb. And so on.

As explained here, it's also possible to use your LiveCD to install a "fresh" GRUB in your boot disk (e.g. /dev/sda). This method is particularly useful when your system's GRUB installer is damaged and you're temporarily unable to reinstall it through e.g. APT. I.e. for a 64-bit Intel Mac, the root installation command currently is apt install grub-common grub-efi grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-pc-bin grub2-common, but if it's not working on your system, you can always boot the LiveCD so GRUB is installed from the packages that are running from your LiveCD and then the new grub folder created in e.g. /boot is created by this LiveCD's GRUB.
FIX GRUB'S DEFAULT SETTINGS.

If you don't have the Gedit text editor, install it by running the command apt-get install gedit -y and then run this command in order to edit GRUB's default settings file with Gedit:
```
gedit /etc/default/grub
```
Once the Gedit window shows the contents of the grub file, remove the # character that is located at the left side of each one of the parameters GRUB_TIMEOUT_STYLE, GRUB_TIMEOUT and GRUB_TERMINAL, and then modify their options so they become these:
```
GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=3
GRUB_TERMINAL=console
```
- The menu option tells GRUB that it must create and show a menu when the computer is started or restarted.
- The 3 option tells GRUB that it must wait 3 seconds before automatically booting the default operating system kernel, so the user has enough time to e.g. select a different kernel from the menu (if you prefer, you may either lower it to 1 or 2, or increase it to 4, 5 etc.).
- The console option tells GRUB that it must ignore the graphics card's most appropriate driver and instead use a simplified VGA display driver that is much more basic but also much more compatible: it won't provide a fancy menu, but will provide a functional one that's more likely to work and be visible.
When you're done making the above modifications, save the file and then exit the Gedit text editor.

If you prefer to use the shell's standard text editor (which happens to be Nano), run nano /etc/default/grub instead of gedit /etc/default/grub.
APPLY THE CHANGES THAT WERE MADE IN GRUB'S DEFAULT SETTINGS.

This one is easy. Just go back to the terminal and run this command:
```
update-grub
```
The above command will read the content of /etc/default/grub and apply it into the settings of the "fresh" GRUB install, thus changing GRUB's behavior from this point on.
MAKE SURE THAT THE CORRECT BOOT EFI IS SELECTED.

Assuming that your EFI partition is mounted at /boot/efi and the shim .efi file that you deleted was stored at /boot/efi/EFI/ubuntu (this is *Ubuntu's default location for its .efi files), check if the GRUB's .efi file is there:
```
ls -l /boot/efi/EFI/ubuntu/ |grep -i '.efi'
```
Because Intel Macs are 64-bit computers, it's expected that a 64-bit *Ubuntu was installed on it, and that therefore a file named grubx64.efi is found by the command above. However, 32-bit systems should instead use a file named e.g. grubia32.efi, so in case your system is a 32-bit one, look for the 32-bit version of the GRUB .efi file.
- If no GRUB .efi file is found, something's wrong and you're advised to install GRUB again (see STEP 5).
- If the GRUB .efi file is found, then it's now time to check if the ubuntu EFI folder is selected as the default (i.e. first) source of .efi files (this precedence is important at boot time). In order to do it, run this command:
```
efibootmgr
```
The output must show something like this:
```
BootCurrent: 0001
BootOrder: 0001,0080
Boot0001* ubuntu
Boot0080* Mac OS X
Boot0081* Mac OS X
Boot0082* 
BootFFFF* 
```
In my case, ubuntu is identified as Boot0001* (its number is 0001), thus it's the one that needs to be the default option: from left to right, BootOrder must show 0001 (i.e. ubuntu) first. If this is not your case, fix it by running a command like this:
```
efibootmgr --bootorder 0001,0080,0081
```
This is going to make 0001 (i.e. ubuntu) the first boot option, 0080 (i.e. Mac OS X) the second one, and 0081 (i.e. Mac OS X) the third one (I'm yet to find what is the difference between 0080 and 0081. Anyway...).
- If your bootloader is placed at e.g. /dev/sdb, you must update the boot manager by running the command efibootmgr --disk /dev/sdb.
- If ubuntu isn't the active boot, make it active with efibootmgr -b 0001 -a. See more e.g. here or by running efibootmgr --help.
REBOOT THE SYSTEM.

Reboot your system in order to check if all this long journey fixed things out. You may reboot it from the menu or by running one of these terminal commands:
```
init 6
```
or
```
reboot
```
or
```
shutdown -r now
```
or
```
telinit 6
```
BOOT FROM THE LIVECD IN CASE OF PROBLEM.

The standard way to boot from a LiveCD on a Mac (iMac, Macbook etc.):
- Power the Mac off.
- Turn it on again and immediately hold the option key.
- Type the password (if any was recorded in it) and hit enter.
- Plug in your LiveCD USB stick, external DVD drive containing a LiveCD DVD, Mac's internal DVD drive containing a LiveCD etc. and wait.
- Once the Mac reads the contents of the LiveCD, a new icon will show up on the screen. Select it with the arrow keys (◀ and ▶) and hit enter (i.e. return).
- From here there are many possibilities depending on what went wrong. You may e.g. want to use your LiveCD to reinstall and/or update GRUB. In the worst case scenario, you can use the LiveCD to backup your data (to e.g. an external drive) and then reinstall the *Ubuntu distribution.

This answer doesn’t have nearly enough upvotes. Thank you! — Cris Luengo, Feb 17 '21 at 07:56
@CrisLuengo Thanks. It took me a lot of time to figure out how to get rid of this issue and one of the reasons is because I couldn't find a "complete" answer anywhere. This motivated me to share this solution so others can more easily get rid of the issue aswell. I'm glad to know that it helped you and I hope that it helps more people. — Yuri Sucupira, Feb 18 '21 at 18:48
@YuriSucupira What to do if I am stuck at the ubuntu logo? I can't get access to a shell — Linux Geek, Mar 29 '21 at 10:16
@LinuxGeek There are lots of possible reasons why this is happening and it's impossible to cover all of them in a single comment, but some questions may help you, e.g. https://askubuntu.com/questions/1035332/updated-to-18-04-pc-freezes-before-the-login-screen-ubuntu-logo, https://askubuntu.com/questions/1085807/black-screen-after-installation-of-ubuntu-18-04, https://askubuntu.com/questions/959471/ubuntu-16-04-hangs-on-splash-screen-during-boot and https://askubuntu.com/questions/38780/how-do-i-set-nomodeset-after-ive-already-installed-ubuntu. If none helps, I suggest you add a new question. — Yuri Sucupira, Mar 30 '21 at 01:33
@LinuxGeek You can also boot from the LiveCD, add the nomodeset parameter in /etc/default/grub as explained in https://askubuntu.com/a/38782/389062, then run sudo update-grub from the LiveCD session and reboot. You can read more about the nomodeset parameter here. — Yuri Sucupira, Mar 30 '21 at 01:43
When I ran grub-install it put the simx64 file right back (visible in the ls of step 8). The behavior is different now, though. It shows the invalid parameter error for only a second, then boots to the grub menu and goes on. It used to hang at the invalid parameter error for a long time. — absmiths, Apr 10 '21 at 14:21
@absmiths grub-install only installs the GRUB bootloader to a device: it does not install Shim, which is different bootloader. In order to install Shim you have to run sudo apt-get install -y shim-signed. — Yuri Sucupira, Apr 10 '21 at 18:40
@absmiths Shim is a preliminary bootloader: when you start your computer, its firmware (a small piece of software in its hardware) asks for a signed EFI file in order to authorize booting. Such EFI file must be a Microsoft-signed one. Shim then provides such signed EFI file (a 32-bit shimia32.efi file or a 64-bit shimx64.efi file) to the firmware. The firmware then authorizes Shim to boot. Shim then transfers such authorization to GRUB (which is not Microsoft-signed). And then GRUB boots Ubuntu Linux by either loading its 32-bit grubia32.efi file or its 64-bit grubx64.efi file. — Yuri Sucupira, Apr 10 '21 at 18:44
@absmiths Hence, if you still got Shim in your system, then Shim is not completely removed and you should make sure that all Shim DEB packages are indeed purged from the system. Moreover, run sudo find /boot \( -iname 'shim*.efi' \) -exec ls -l '{}' \; in order to find where the remaining Shim EFI file is located and then delete it with a command such as sudo rm /path/to/such/shim/efi/file. See also https://askubuntu.com/questions/342365/what-is-the-difference-between-grubx64-and-shimx64 — Yuri Sucupira, Apr 10 '21 at 18:45
@YuriSucupira On MacPro 2013 6,1 with macOS + Ubuntu 20.04 dual boot worked fine for a year then perhaps some system update messed up grub. Now, I get stuck at the grub boot screen after I reinstall grub from LiveUSB with error msg like ... Importing MOK states has failed: import_mok_state() failed : Invalid Parameter Continuing boot since secure mode is disabled If I remove the shim*.efi from /mnt/boot/efi/EFI/ubuntu using LiveUSB then I get the extra error msg LoadImage failed: Not found DevicePath: PciRoot(0) ...... /\EFI\ubuntu\shimx64.efi ... and a paragraph of hex numbers. So? — Shah-G, Jun 16 '21 at 17:32
@YuriSucupira I've also tried adding nomodeset to the grub config but the screen still gets stuck at grub boot msgs. — Shah-G, Jun 16 '21 at 17:46
@Shah-G My workaround is designed to work on a Mac with a single OS (Linux), but you need dual boot. This complicates things. You're likely going to have to boot from the LiveUSB, mount the Mac's 1st disk's 1st partition (e.g. /dev/sda1) at /boot/efi and then copy its /boot/efi/EFI/ubuntu/grubx64.efi to /boot/efi/EFI/boot/bootx64.efi so your Mac's firmware chip reads the EFI GRUB data from /boot/efi/EFI/boot/bootx64.efi and then boots. Resetting the NVRAM and PRAM may help, too (due to undesirable GPU driver save state data that may be inconveniently stored in your Mac's hardware). — Yuri Sucupira, Jun 16 '21 at 19:04
@Shah-G Also check this question and its answers. Edit: this is not related to kernel mode setting, thus using nomodeset does not affect the issue. — Yuri Sucupira, Jun 16 '21 at 19:07
I've done both NVRAM reset and bootx64.efi replacement. Now it gives a blank black screen and nothing happens. I've tried advanced options kernel 5.8 (recovery mode). It says smt like address NOT found ... kernel panic. — Shah-G, Jun 17 '21 at 07:26
@Shah-G Unfortunately, I can't replicate the issue because I'm not dual booting. I'm going to suggest another couple of things, here, but if my suggestions don't help you fix this I strongly suggest that you report this issue in that question that I mentioned about dual booting with OS X/macOS + Linux, because the people up there dealt with the same issue. [1] Use efibootmgr as explained in step 8 to make this new grub EFI file the default one, and [2] make sure that the original mmx64.efi is present in both /boot/efi/EFI/boot/mmx64.efi and /boot/efi/EFI/boot/mmx64.efi. — Yuri Sucupira, Jun 17 '21 at 09:52
@Shah-G mmx64.efi is MOKManager, a utility that signs bootloaders with your Machine Owner Key. MOKManager calls grubx64.efi. If it fails to boot that EFI file due to e.g. a bad signature, it reports the issue. grubx64.efi is therefore the GRUB bootloader, responsible for loading Linux, while mmx64.efi just invokes grubx64.efi. And bootx64.efi is a fallback when everything else fails. If you copy grubx64.efi to mmx64.efi (after creating mmx64.efi.bak), such hack may circumvent a problem with your UEFI implementation and MOKManager (because it just boots directly from GRUB). — Yuri Sucupira, Jun 17 '21 at 10:01
@Shah-G I forgot to mention, but I believe that reading the article hosted at https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how-does-that-actually-work-then/ is a good start to understand what UEFI is, what's the difference between EFI boot manager and EFI boot loader, and why Apple's firmware complicates things for Mac users who wish to dual boot. If your Mac's firmware has its EFI boot manager with Secure Boot off, then it must load any unsigned EFI file despite of MOK and MOK state, since signing keys in such case are not required to boot from any boot loader (i.e. EFI file). — Yuri Sucupira, Jun 20 '21 at 12:26
Is there any disadvantage in removing shim? For me the other answer was enough to get into grub menu. — jarno, Sep 04 '21 at 08:59
@jarno As I mention here, shim is not necessary on a Macbook with Linux, because a Macbook with Linux boots Linux with secure boot mode disabled but shim is made for booting Linux with secure boot mode enabled. So, in a nutshell: for the moment, no, there's no immediate disadvantage in keeping shim. However, there's no advantage, either, and a further shim update may cause you problems that you however won't experience if you preemptively remove shim. — Yuri Sucupira, Sep 04 '21 at 15:52

score 5 · Answer 2 · answered Sep 11 '20 at 23:04

5

I'm experiencing the same issue with 20.04 on a MacBook Pro 5,5 (13" Mid-2009). Booting from the Ubuntu Live USB installer displays the grub graphical menu absolutely fine.

A workaround that is working for me, until someone is able to find the root cause, is to uncomment or add GRUB_TERMINAL=console to /etc/default/grub, and run sudo update-grub.

You can at least see and make selections from the menu, it just isn't full-screen or look as nice. I have a suspicion this is more of an EFI setup issue as opposed to a grub one.

answered Sep 11 '20 at 23:04

visnaut

51

Same problem and same solution on a Macbook Pro 2011. Congratulations for finding this. Moreover I do not see any problem with the display. If you have display problem while booting, try resetting the PRAM. GRUB_TIMEOUT_STYLE="countdown" GRUB_TIMEOUT="4" GRUB_CMDLINE_LINUX_DEFAULT="" GRUB_TERMINAL="console" are my edits of /etc/default/grub to see the booting messages and have a count down allowing to press ESC to enter the GRUB menu if I want to. Thus I am better set for booting problems. – Pierre ALBARÈDE Mar 29 '21 at 19:31

score 0 · Answer 3 · answered Jun 09 '22 at 16:06

0

This worked for me on my MacBook Pro 2010 with Xubuntu 22.04:

Edit /etc/default/grub:

GRUB_TIMEOUT_STYLE=false
GRUB_TIMEOUT=
GRUB_TERMINAL=console

Then run sudo update-grub and reboot and you should see the GRUB menu.

answered Jun 09 '22 at 16:06

SurvivalMachine

2,783

How do I get the grub menu to show on a MacBook?

3 Answers3

Linked