Error installing Rocky 8.4 on macbook pro

I’ve been trying to get the latest version of Rocky installed on a partition of my Macbook Pro but I’m getting an error when I have the installer run automatically for the hard drive installation. See the attachment but it basically just says “resource to create this format macefi is unavailable”.

I also get this error when I try to install Centos 8.4.

I’ve faced the same issue while installing Rocky Linux in an iMac from 2008. The good news is that I have a working system!

Since I’m far from an expert, there may be steps that are not necessary or even incorrect, in any case here are the steps I followed. At the end I added some links to some sources I used to get this all to work:

  1. Boot into the install media and set it all up as desired.
  2. For the partitioning:
    • Tell the tool to “Do not install boot loader”
    • Select custom partitioning scheme:
      • Create /boot partition (1024 MiB, Standard, XFS), then edit it to make it /boot/efi (1024 MiB, Standard, EFI Partition). I did this because the installer wouldn’t let me choose the right settings from the + menu and I wanted to follow the steps from (1) in order.
      • Create /boot partition (1024 MiB, Standard, XFS)
      • Create /home, in my case (X GiB, LVM, XFS) group rl => rl-home
      • Create / in my case (X GiB, LVM, XFS) group rl => rl-root
      • Create /swap, in my ase (7.88 GiB, LVM, swap) group rl => rl-swap
    • Proceed despite the warning/error regarding macefi or mactel tell it to continue despite it all.
  3. Proceed with the installation.
  4. Reboot.
  5. Boot into the newly installed Rocky. It should take you to GRUB2, but fail to load automatically.
  6. Boot manually:
    • Identify the root partition, in my case: set root=(lvm/rl-root)
    • Point to the linux image: linux (hd6,gpt4)/boot/vmlinuz-4.18... root=/dev/mapper/rl-root
      • Note. For this step and the following I don’t remember exactly the versions of vmlinuz and initrd, nor the exact path. I used ls, as in ls (hd6/gpt4)/ to determine in which partition and path where vmlinuz and initrd.
    • Then: initrd (hd6,gpt4)/boot/initrd.img-4...
    • Finally: boot
    • This should boot your Rocky.
  7. Once in the OS, update the GRUB configuration: grub2-mkgconfig -o /boot/efi/EFI/rocky/grub.cfg
  8. Hopefully, you are all set. Reboot to verify.

References:

  1. Partitioning issue RHEL8 on a Mac machine
  2. Using the GRUB2 boot prompt
  1. Configure separated GRUB to run Linux from LVM ddrescued device
  2. RHEL7/CentOS 7 – Recover/Reinstall GRUB2 with UEFI

(Posting in a follow up to work around the limitations I have as a new user :blush:

Other sources that may be of help:

3/3

Sorry for the necrobump but I ran into the same issue. The cause of this issue is that RedHat and likely Rocky too builds their iso’s explicitly disabling Mac booting by building iso’s with a “–nomacboot” flag. The solution is to build the iso’s with a “–macboot” flag instead. This can be done using mock/kickstart/livemedia-creator but it might be too involved for most users though.

Ideally Rocky can change this flag so their iso’s just work on Macs. I don’t really understand why RedHat even does this. There are so many forums and mailing posts spread over many years of people trying to re-use their Macs/Macbooks all running into this issue. All caused by a flag that breaks things on purpose. I haven’t been able to find a single reason as to why this flag is used by RedHat and also in many RHEL based distro’s.

An iso build with the macboot flag will install just fine on other machines too. It just adds the needed packages the installer is complaining about. There is really no downside changing flags.

Fedora and RHEL (and thus rocky) use --nomacboot likely because everyone should be using FAT32 for their EFI partition, not HFS+. Pretty much everyone should be using FAT for the EFI partition at this point and those mac’s that are still using HFS+ for their EFI partition are likely much older installations. Even new installations of macOS are like this (see below).

lani:~ root# diskutil info /dev/disk0s1
   Device Identifier:         disk0s1
   Device Node:               /dev/disk0s1
   Whole:                     No
   Part of Whole:             disk0

   Volume Name:               EFI
   Mounted:                   No

   Partition Type:            EFI
   File System Personality:   MS-DOS FAT32
   Type (Bundle):             msdos
   Name (User Visible):       MS-DOS (FAT32)

   OS Can Be Installed:       No
   Media Type:                Generic
   Protocol:                  PCI-Express
   SMART Status:              Verified
   Volume UUID:               0E239BC6-F960-3107-89CF-1C97F78BB46B
   Disk / Partition UUID:     EA172E04-C7A4-4263-A762-88D56D159C74
   Partition Offset:          20480 Bytes (40 512-Byte-Device-Blocks)

   Disk Size:                 209.7 MB (209715200 Bytes) (exactly 409600 512-Byte-Units)
   Device Block Size:         512 Bytes

   Volume Total Space:        0 B (0 Bytes) (exactly 0 512-Byte-Units)
   Volume Free Space:         0 B (0 Bytes) (exactly 0 512-Byte-Units)

   Media OS Use Only:         No
   Media Read-Only:           No
   Volume Read-Only:          Not applicable (not mounted)

   Device Location:           Internal
   Removable Media:           Fixed

   Solid State:               Yes
   Hardware AES Support:      No

There are no plans to change this behavior on the Rocky side. We follow our upstreams (fedora and rhel) in this regard.

1 Like

Every other distro installs fine making it’s own efi/fat partition. There is no need to set it up with hfs.

No plans to change a little flag. So any Mac user has to build their own iso or use another distro.

All without a good reason. Amazing. Smh.

You should adjust the installer to make this clear to the user instead of showing a vague “macefi not found” message. Just put there you hate Mac users and build the iso broken for Macs on purpose with a flag.

That would be the honest truth.

And by the way. Fedora installs fine since F36. Just tested it with the F38 RC. They no longer use that flag. So yeah…

There is no need to use HFS, yes. However older installations of macOS initially used HFS+ on their EFI partitions, and that’s likely where this issue starts, among that anaconda is detecting intel mac hardware and trying to do work that can’t be done as the support is unavailable/turned off. There are workarounds for this though (for both full installs and dual boot installs).

With that said, even if we decided to drop --nomacboot, we wouldn’t be able to build our ISO’s as we (and RHEL) do not ship the HFS utilities needed to make this work (mactel-boot being the main one).

That’s a bit unfair to say, given that I used my macbook to provide diskutil output and we have team members that use macs almost exclusively. It’s also very likely there are folks at Red Hat that use macs too.

Unless Red Hat plans to support mactel-boot in RHEL (the required package) and other HFS utilities (if applicable), there’s not much else we can do. I understand that this is frustrating for some users.

1 Like

Whats the point of having your own RedHat spin if you blindly follow upstream and can’t even change a small flag? Luckily there are better distro’s out there that don’t require the user to build their own iso to install it. Every single other distro I tried installs fine. Including Fedora.

What will actually change for Rocky if the change a tiny flag to build iso’s the needed package? What does actually change other than a few mb’s extra being used? Why build a broken iso on purpose?

You sound like a corporate shill: We can’t do this, there’s no good reason, we can change it but we won’t. Computer says no.

There’s no downside of not using that flag so your iso can be used on Macs. You simply don’t want to. Changing the flag is easy, nobody is harmed by it, there is no logical reason to build iso’s broken for Macs on purpose!

But even given all that you simply refuse to change. Now that’s something to be proud about.

Not one single reason to use this flag has been presented. This issue has been happened for many years, many users confused as to why. The why is easy, this stupid flag. I guess I will be finding posts about this issue in the years to come as well. Since it’s not even made clear to user as to why it doesn’t install. so the user heads to a forum or Reddit with this error message, wasting people’s time who try to help them figure it out.

Just put an honest message in the installer and say Mac iso’s are broken by default on purpose. It is not a bug, it is a feature. And if the user wants to use the OS that was crappy enough to build a crippled iso they have to build their own iso omitting the flag that breaks the iso on purpose.

Just wow. Please remove my account on this forum. I am done with anything RHEL, Rocky, Alma, etc. All build their iso broken. Only Fedora doesn’t build a broken iso.

As I said, Red Hat does not provide mactel-boot nor hfsutils, so even if we drop the flag, our ISO’s wouldn’t build. Those packages are expected if we don’t use --nomacboot or use --macboot. I understand that this is frustrating, but understand our goal is to match our upstream RHEL 1:1 as close as possible. You are right that nobody is harmed by it, but the packages are missing from RHEL proper.

I’m sorry that you feel this way about the Enterprise Linux distribution ecosystem. We can remove your account if you wish. This thread is now locked.

1 Like