5

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). Addition: It turns out that this problem is also present at certain Apple 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 rEFInd. This allows the Linux kernel to reach the necessary vBIOS information and initialize the kernel mode-setting properly. If someone needs to install just the bare Linux kernel booting via rEFInd please check the section "Optional further steps" at the end.

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.) Important note, the steps 1 to 3 mentioned below must be carried out before a reboot is made.

  • After Ubuntu is installed and the EFI adjustments are in place, install rEFInd directly from the CD/DVD. This option is avaiable in newer rEFInd builds. Download the corresponding image from the official website, burn it to a CD/DVD, boot from it and chose the "install" option.

This topic becomes even 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, Apple EFI firmware based systems requires some additional modifications. 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).

The following steps describe how a regular EFISTUB booting from the stock Apple EFI firmware is established.

  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.

Finally, make a reboot, install rEFInd from CD, boot into it and launch the EFI shell. The last step establishes the boot entry in the stock Apple EFI bootloader. This is not absolutely necessary when only rEFInd is used as bootloader. However, in that example here the command would be:

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

Regarding rEFInd this results now in a configuration in which two vmlinuz.efi boot options exists. 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.)

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

As mentioned at the beginning, it is sometimes necessary to start only the bare Linux kernel (without the "vmlinuz loader") 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

Clemens
  • 481
  • 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 06 '21 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 09 '21 at 14:10
  • Yes, newer Macs have currently some difficulties with rEFInd. There exist a note at the rEFInd website about this incompatibility. (https://www.rodsbooks.com/refind/) Maybe this has to do with some additional security features in Mac OS (or in the Mac firmware). Whatever, if rEFInd is unable to boot, then this will be most likely also true for an EFISTUB starting Linux. However, you must try this out, - I cannot give here any further advice. ;-) – Clemens Feb 14 '21 at 13:50
  • Thanks @Clemens ! You seem to be the only one on earth who has a solution to this problem ! I have an iMac11,2 (Radeon HD 4850), with PopOS 21.10 (based on Ubuntu 21.10) installed on it. Kernel log show the "No UMS support" line. – Ricflomag Mar 23 '22 at 12:39
  • @Clemens I have installed rEFind through the amd64 package. Alas, it seems that Ubuntu 21.10 boot logic is different from 20.04. Can you help me ? Of course I would reinstall the OS if necessary. – Ricflomag Mar 23 '22 at 12:47
  • @Ricflomag Sorry for the late reply. Please follow the steps of the second install variant below. Important, you have to chose the safe graphics option of the Ubuntu 21.10 installer. And you may have to use a newer kernel beyond 5.11 or so. Maybe it is worth to wait until the upcoming Ubuntu 22.04 LTS release. ;-) – Clemens Apr 18 '22 at 15:52

2 Answers2

3

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

More recent (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 again 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 now Ubuntu, select the EFI (safe graphics) option, target partition is sda4 aka the "Linux HD". (Also in this case no additional boot, swap or data partition is used.) Please consider, the steps 1 to 3 mentioned below should be carried out before a reboot is made.

  • After K(U)buntu is installed, install rEFInd directly from the CD/DVD. This option is avaiable in newer rEFInd builds. Download the corresponding image from the official website, burn it to a CD/DVD, boot from it and chose the "install" option.

Note, if someone needs to install just the bare Linux kernel booting, the following steps can be skipped (for the moment). Please check first the section "Optional further steps".

Because (K)Ubuntu is running in EFI mode, we can config the additional EFI related booting stuff directly without any additional steps. The example here uses the regular EFI path syntax.

The following steps describe how a regular EFISTUB booting from the stock Apple EFI firmware is established.

  1. When Ubuntu is completely installed, the efi esp partition should be present and mounted at /boot/efi. (As mentioned, this is because Ubuntu is running 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 a final (optional) step it would make sense to completely remove GRUB and Shim. Update: Unfortunately these two packages are installed again and again automatically by (K)Ubuntu. If you really want to get rid of them, then it is necessary to blacklist the GRUB and Shim packages manually. The following command would uninstall these two packages including the corresponding config:

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

Congrats, the regular EFISTUB kernel booting (including rEFInd) 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. So the most save option is to install rEFInd permanently as already described. This will by-pass all generic Apple EFI and GRUB boot principles. As an emergency boot option, a rEFInd CD or USB flash drive can be additionally used if the installed rEFInd fails.

Take a reboot and 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 it is recommended to install the rEFInd PPA. This will automatically update rEFInd to the newest release. 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! Reboot the Mac and choose in rEFInd the Linux kernel (with the efi extension). K(u)buntu should now boot fine also on systems which doesn't expose the vBIOS under EFI.

And by the way, an auto-mount entry (of the esp partition) in fstab isn't required. This is already configured because (K)Ubuntu was installed from the beginning in EFI mode.

Clemens
  • 481
  • Did I understand this correctly, I have to start the installer using safe graphics, then choose "Try Ubuntu" (instead of "Install Ubuntu") and when I'm done installing, I should keep testing Ubuntu instead of rebooting, and do steps 1-3? Unfortunately in my case, after installation, the efi partition is not mounted at all, so I have to mount it manually. But then the commands in the sh script in step 2 fail because the files apparently don't exist (they do though, when I execute ls).. Does anyone know what I did wrong? – nhcodes Dec 23 '22 at 11:01
  • Sorry for the late reply. ;-) For (K)ubuntu 22.04 LTS (and newer) this should work fine. The only problem may be the special hybrid Apple GPT/MBR partition scheme which can result in weird problems regarding the installation of the boot loader in the EFI partition. It is possible to convert the special Apple layout to standard EFI-GPT with the tool GPT fdisk. And finally, this might also depends on which Apple system the installation is performed. The older the more difficult but starting from the iMac 7,1 line form 2007 this should work here as described. It does at least for me. ;-) – Clemens May 24 '23 at 10:55
  • Does brightness control work? I tried booting Ubuntu 22.04 with nomodeset (without doing any of the other options you did), and brightness does not work. – Archisman Panigrahi Feb 15 '24 at 02:11
  • When native EFI was used it worked under Kubuntu 20.04 LTS but it no longer works on Kubuntu 22.04 LTS. And it looks that there exist for 22.04 also some strange behavior with the standby and suspend mode. Whatever, Kubuntu 24.04 LTS is almost ready so I hope that those problems will be in the near future resolved. :-) Note, the brightens issue seems unrelated to the kernel version. Ergo when kernel 5.15.x is used it works on 20.04 while it doesn't work under 22.04. – Clemens Feb 29 '24 at 09:11
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.

boot screen

phuclv
  • 628
  • 1
  • 8
  • 38