3

Okay, here follows now a somewhat more complex topic. I want to ask what's the simplest way to implement a clean EFISTUB Linux kernel booting through the rEFInd boot manager?

The very best method would be a Linux distro which natively includes an install option for EFISTUB via rEFInd. Unfortunately this doesn't exist. Even the rEFInd supporting Manjaro Linux installer is using for booting the Linux kernel a grubx64.efi file (which is loaded by rEFInd). That really doesn't make a lot of sense. (It effectively makes absolutely no sense.)

Well, in a lot of cases, native EFI booting via GRUB is working fine also for Apple hardware. However, there are some situations where that is not possible. I am thinking in particular of all the Apple models which doesn't continuously expose the video BIOS in native EFI mode. For example, this is true for all non-MXM based (earlier & later) models which doesn't contain an Intel GPU but still have a separate GPU chip. On such Apple hardware, the video BIOS is embedded in the main EFI firmware and not in a separate flash chip (like at the MXM GPU cards). While the vBIOS information is in legacy CSM BIOS emulation mode (aka Apple boot camp) always present and accessible, it is NOT under native EFI. So, when Linux is booting in EFI over GRUB the kernel is unable to reach the vBIOS information and cannot proceed with KMS (kernel mode-setting). On Radeon GPU based systems this results in an *Error* No UMS support in Radeon module! message. Source: Linux issues on iMac11,2

Confirmed (incomplete) list of Apple models affected by "vBIOS not exposed in EFI":

  • iMac4,1 & iMac5,1 (Radeon X1600)
  • Macmini4,1 (GeForce 320M)
  • iMac11,2 (Radeon HD 4670)

The solution for this problem is to boot the bare Linux kernel directly from EFI via the built-in EFISTUB feature. This allows the Linux kernel to reach the necessary vBIOS information and initialize the kernel mode-setting properly.

So far, my intended steps are:

  • Prepare the desired partitioning layout under Mac OS. In my case this would be: sda1 (EFI ESP), sda2 (Macintosh HD), sda3 (Apple Recovery HD), sda4 (Linux HD) Note, the Recovery Partition is not visible in the Apple disk utility.

  • Install Ubuntu through CSM BIOS emulation (with MBR) on partition sda4. (no additional boot, swap or data partition is used in this example!)

After these points this topic becomes somewhat more complicated because of Apple specific EFI restrictions. At a regular UEFI environment, the steps described here How to boot load the kernel using EFI stub (efistub) loader? (See the SECOND answer) would allow a migration to EFISTUB kernel booting.

However, at Apple EFI firmware based systems, some modifications are necessary. A further limitation is that Linux runs during the first phase in CSM BIOS mode. As a consequence, the step "Add the boot entry" (with efibootmgr) cannot be applied. This must be done later over the EFI Shell (outside of Linux).

  1. When Ubuntu is completely installed, mount the efi esp partition at /boot/esp. (Be aware, a regular EFI booting Ubuntu installation uses a mounting point in /boot/efi. So the following commands must be adjusted if the mount point differs.) Because Ubuntu was in our case installed via CSM BIOS emulation, the ubuntu directory is missing on the ESP. It has to be created first:

    mkdir /boot/esp/EFI/ubuntu
    
  2. Create a new file sudo nano /etc/kernel/postinst.d/zz-update-efistub with the following contents:

    #!/bin/sh
    rm /boot/esp/EFI/ubuntu/*
    cp /vmlinuz /vmlinuz.efi
    cp /vmlinuz* /initrd.img /boot/esp/EFI/ubuntu/
    rm /boot/esp/EFI/ubuntu/vmlinuz.old
    

    This is called a hook. It will sync the ESP kernel-related files to those at the root partition. Make it executable with:

    sudo chmod +x /etc/kernel/postinst.d/zz-update-efistub
    sudo /etc/kernel/postinst.d/zz-update-efistub
    

    The vmlinuz.efi kernel loader is needed at older Apple EFI firmware versions. On those the normal vmlinuz file is not recognized as bootable.

  3. As mentioned, the boot entry cannot be established because Linux is not in UEFI mode. That has to be done as the very last over the EFI Shell. However, the following command can be used later to adjust the boot entry when Linux is running in native EFI.

    sudo efibootmgr -c -d /dev/sda -p 1 -L "Ubuntu (efistub)" -l /EFI/ubuntu/vmlinuz.efi -u "root=/dev/sda4 rw initrd=/EFI/ubuntu/initrd.img quiet splash"
    

    The syntax is correct for this example here. Otherwise the arguments -d and -p must be changed according to the used partition layout. The EFI ESP is /dev/sda1 while the root= partition is sda4.

The next steps requires that the Apple System Integrity Protection (SIP) is disabled. That feature is mandatory used since Mac OS 10.11 (and upwards). This can be done quite easy at EFI firmware level with the rEFInd Boot CD. After that:

  • Boot into Mac OS and install the GPT fdisk tool. http://www.rodsbooks.com/gdisk/ Launch it in Terminal as root sudo gdisk /dev/disk0 and convert the Hybrid GPT MBR scheme into a standard GPT protective one. Useful information can be found here: https://discussions.apple.com/thread/6095828

  • Download and install rEFInd (grab the newest pkg file from the website). Open the terminal and install rEFInd into the EFI ESP. A howto can be found here: Installing rEFInd under Mac OS It should be noted that rEFInd must be installed after Linux. Otherwise the rEFInd ext4fs driver (and Linux support) won't be installed. Alternatively it is also possible to skip this step and boot rEFInd from CD.

Finally, make a reboot into the newly installed rEFInd boot manager and launch the EFI shell. As the last step the boot entry must be added. In that example here the command would be:

vmlinuz.efi root=/dev/sda4 ro initrd=\EFI\ubuntu\initrd.img

This results in a configuration in which two vmlinuz.efi boot options exist in rEFInd. The first is located in the esp partition sda1 and can be loaded directly from the Apple stock EFI loader. The other one is located in the root partition sda4 (or in its boot folder). That second vmlinuz.efi can be loaded from rEFInd but not from the stock Apple loader. Conversely, rEFInd seems unable to load the first vmlinuz.efi file without additional information regarding the root partition. (The boot process will hang and a BusyBox shell will be displayed.)

Well, as mentioned at the beginning, it is sometimes necessary to start the bare Linux kernel directly from rEFInd to avoid tough problems like the "vBIOS not exposed in EFI" issue. In this case, the kernel must also have an efi extension. This requires a manual adjustment because the kernel name changes with every kernel update. The syntax may look like:

sudo cp /boot/vmlinuz-5.4.0-65-generic /boot/vmlinuz-5.4.0-65-generic.efi

In some situations it may be necessary to delete the previously generated vmlinuz.efi file. But i recommend to try it first out without deleting it.

sudo rm /boot/vmlinuz.efi

Last of all, if everything works as expected the esp partition can be auto-mounted in fstab with the following command. (This is needed for the hook to updated the kernel loader files automatically.)

/dev/sda1   /boot/esp   vfat   rw,auto,user,uid=1000,gid=1000,utf8   0   0

or

/dev/sda1   /boot/efi   vfat   rw,auto,user,uid=1000,gid=1000,utf8   0   0

All suggestions for further improvements are welcome! ;-)

Pictures: enter image description here

enter image description here

6
  • What version of Ubuntu? – David Jan 22 at 8:27
  • A LTS version, - I made my first attempts with version 16.04 and 18.04. Now I will implement it with 20.04. I can give more information when I have again access to appropriate Apple hardware. – Clemens Jan 22 at 9:13
  • Any updates? Inquiring minds want to know. – SciGuy Feb 6 at 3:23
  • For an iMac12,2 I can confirm that rEFInd and EFISTUB kernel booting works perfectly with 20.04 LTS (Kubuntu). However, at this iMac model that is not really needed because also GRUB is working fine in EFI mode. An advantage of EFISTUB is that it's definitely faster in booting. Until now, I haven't found an iMac11,2 to test. Maybe somone other will do that. ;-) – Clemens Feb 6 at 18:28
  • The newest Macs seems to have trouble getting rEFInd to work. Any advice on getting Apple's boot manager to start up the ubuntu stub? ie, MacOS and the windows bootcamp can restart in one other, but you'd have to hold down option key to boot Ubuntu? – SciGuy Feb 9 at 14:10
1

Here follows a somewhat simpler way to implement a EFISTUB and bare Linux kernel booting from rEFInd.

Newer (K)Ubuntu versions includes a not much noticed EFI boot option called safe graphics. Behind this stands the more or less known nomodeset GRUB parameter. In older times this option mostly resulted in booting to a CLI command prompt, no graphical UI (X-Server) was available. However under an EFI environment that option enables the booting of X with basic "UEFI resolutions". These seems to be defined along the UEFI GOP (Graphics Output Protocol) specification. (https://wiki.osdev.org/GOP) To some degree the working principle of the safe graphics option corresponds to the "Microsoft Basic Display Driver" in newer Windows versions.

Long speak short, this nice little option enables a minimal X "emergency booting" also on very restricted "vBIOS not exposed in EFI" systems. :-) Well I have not tested this at an iMac11,2, but I can confirm that this works GREAT at an iMac11,1 which contains a Radeon HD 4850 GPU.

Whatever, this awesome option has the potential to dramatically simplify the topic described here. The installation steps will look as follow:

  • Prepare the desired partitioning layout under Mac OS. As mentioned, in my case this would be: sda1 (EFI ESP), sda2 (Macintosh HD), sda3 (Apple Recovery HD), sda4 (Linux HD) Note, the Recovery Partition is not visible in the Apple disk utility.

  • Install Ubuntu directly through EFI (safe graphics) mode on partition sda4. (Also here, no additional boot, swap or data partition is used in this example!)

Because (K)Ubuntu is now already installed in EFI mode, we can config the EFI stub booting directly without any additional steps. Note, at a problematic "vBIOS not exposed in EFI" system it is absolutely necessary to boot-up Ubuntu the first times through the safe graphics option. It will NOT work without that. It will start to work when the rEFInd and EFISTUB kernel booting is "in place" and correctly configured. However, this limitation does not apply to "normal" EFI systems, these are booting in EFI mode fine also via GRUB. Second note, because (K)Ubuntu is running in EFI mode I use here the regular EFI path syntax.

  1. When Ubuntu is completely installed, the efi esp partition should be present and mounted at /boot/efi. (This is because Ubuntu is installed in EFI mode.)

  2. Create a new file sudo nano /etc/kernel/postinst.d/zz-update-efistub with the following contents:

    #!/bin/sh
    rm /boot/efi/EFI/ubuntu/*
    cp /boot/vmlinuz /boot/vmlinuz.efi
    cp /boot/vmlinuz* /boot/initrd.img /boot/efi/EFI/ubuntu/
    rm /boot/efi/EFI/ubuntu/vmlinuz.old
    

    This hook will sync the ESP kernel-related files to those at the root partition. Make it executable with:

    sudo chmod +x /etc/kernel/postinst.d/zz-update-efistub
    sudo /etc/kernel/postinst.d/zz-update-efistub
    

    The vmlinuz.efi kernel loader is needed at older Apple EFI firmware versions. On those the normal vmlinuz file is not recognized as bootable.

  3. Because Linux is running in EFI mode, the regular EFISTUB boot entry can be established now.

    sudo efibootmgr -c -d /dev/sda -p 1 -L "Ubuntu (efistub)" -l /EFI/ubuntu/vmlinuz.efi -u "root=/dev/sda4 rw initrd=/EFI/ubuntu/initrd.img quiet splash"
    

    Also here, the syntax is correct for this example. Otherwise the arguments -d and -p must be changed according to the used partition layout. The EFI ESP is /dev/sda1 while the root= partition is sda4.

As the final step it is recommended to completely remove GRUB and Shim. I noticed some strange behavior because of some GRUB related config settings. These all disappeared when GRUB was removed entirely, including the old GRUB and Shim config data:

sudo apt remove --purge grub-common
sudo apt remove --purge shim

Congrats, the EFISTUB kernel booting is now fully configured!

To verify the boot order enter sudo efibootmgr -v at the CLI. The "Ubuntu (efistub)" is in my case entry "Boot0002". It should be set as the first one, before any other. This can be done at the CLI for example with sudo efibootmgr -o 0002,0000,0001. But be aware, Mac OS sometimes defaults the boot order again back to itself. As an emergency boot option, a rEFInd CD or USB flash drive can be used then. There exist also the risk that Ubuntu automatically reinstalls GRUB and Shim. So the most save option is to install rEFInd permanently (see below). This will by-pass all generic boot principles in Ubuntu.

Take a reboot an check if everything works as expected. :-D

Optional further steps, only necessary on restricted "vBIOS not exposed in EFI" systems:

To establish a bare Linux kernel booting directly from rEFInd, the following command is required. It is very important to understand that this requires an ongoing manual adjustment because the kernel and kernel name changes with every kernel update. So check first out which kernel version is present! ;-)

sudo cp /boot/vmlinuz-5.4.0-72-generic /boot/vmlinuz-5.4.0-72-generic.efi

In some situations it may be necessary to delete the previously generated vmlinuz.efi file. But I recommend to try it first out without deleting it.

sudo rm /boot/vmlinuz.efi

As the last step, download and install rEFInd. Regarding (K)Ubuntu this can be done quite easy through the official rEFInd PPA from Roderick W. Smith:

sudo apt-add-repository ppa:rodsmith/refind
sudo apt-get update
sudo apt-get install refind

Alternatively it is also possible to skip this step and boot rEFInd always from CD.

That's it, an auto-mount entry in fstab (of the esp partition) isn't required, this is already configured because (K)Ubuntu was installed in EFI mode.

0

No, if you're trying to run something from disk (.img), you should use the path to the options structure.

options "root=/dev/ram0 where screen format can also be used ~ video=1366x768 UVESA_MODE=1366x768"

In addition, you do not mention the disk formats, which is important.

In standard mode (unpacked), the following should be written on your screenshot...

Boot boot\vmlinuz-5.8.0-50-generic from 24 GiB ext4 volume

The other axes should not have ext4 format, and you should specify the options or .efi file for axes.

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.