RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1751311 - Partitioning issue RHEL8 on a Mac machine
Summary: Partitioning issue RHEL8 on a Mac machine
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: python-blivet
Version: 8.0
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Blivet Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-11 17:21 UTC by Juan Manuel Parrilla Madrid
Modified: 2024-02-14 12:21 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-11 15:18:33 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Anaconda installation log (582.44 KB, text/plain)
2019-10-05 15:45 UTC, Jose Deniz
no flags Details

Description Juan Manuel Parrilla Madrid 2019-09-11 17:21:15 UTC
Description of problem:

Hi there, I have a Mac Pro 6.1 machine on my homelab and I've tried to install RHEL8 into it (It was a success with Fedora30 and CentOS7). When I reach the partitioner on the installer, and I select auto partitioning, it gives me an empty error.

Diving a bit more, I received this other (more verbose) error:

"Resource to create this format macefi is unavailable"


Version-Release number of selected component (if applicable):

I've tried with 8.1 Beta and 8.0 release

How reproducible:


Steps to Reproduce:
1. Boot a RHEL8 using a usb stick on a Mac machine
2. Use the auto-partitioning
3. Receive multiple errors related with storage like:

"Error checking storage configuration"
"Failed to save storage configuration"

But the most important one is this:

Resource to create this format macefi is unavailable

Actual results:

Cannot be installed with in an accesible way 

Expected results:

Partitioning applied into the storage selected and the start the installation

Additional info:

Comment 1 Juan Manuel Parrilla Madrid 2019-09-11 18:13:06 UTC
I've performed a correct RHEL8 installation on the Mac machine (It's a workaround).

- Use a USB stick with RHEL8 into mac machine
- Perform the usual configuration
- Once you get into the partitioning stage, click down to don't allow this device to boot
- Create the partition configuration that you want.
- Install RHEL8 and reboot
- Boot from USB stick on rescue mode and enter on chroot
- Create an EFI partition manually with fdisk and then give it vfat format.
- Get the UUID and put the correct line into the fstab: 
    UUID=8BF5-B6D3                 /boot/efi               vfat    defaults        0 0
- Move all the things from /boot/efi/* to tmp and mount the previous partition
- Move again from /tmp/efi into /boot/efi (once the partition is mounted)
- Create the Grub config with "grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg"
 and reboot the node. (Expect 2 reboots, it needs to relabel all the new files and so on)

With those steps you should be able to boot with your installation.

H2H

Comment 2 Jiri Konecny 2019-09-12 10:26:24 UTC
Hello,

Could you please provide us logs from the installation environment? You can find them in /tmp/*.log.

Comment 3 Jose Deniz 2019-10-05 15:43:54 UTC
I can confirm same behaviour on CentOS 8.0 and attach one anaconda log for it

Comment 4 Jose Deniz 2019-10-05 15:45:16 UTC
Created attachment 1622786 [details]
Anaconda installation log

anaconda-tb log

Comment 5 Jose Deniz 2019-10-05 15:48:04 UTC
If I follow https://bugzilla.redhat.com/show_bug.cgi?id=1751311#c1 workaraound I get an additional error "mactel-boot package not found"

Comment 6 Jiri Konecny 2019-10-10 13:03:51 UTC
My guess is that RHEL-8 is missing a library in the stage2 or a kernel module.
This issue is raised from our storage library so I'm switching to them for further triaging.

Comment 7 Jose Deniz 2020-01-20 12:40:50 UTC
I can confirm that package "mactel-boot" is also missing in RHEL 8.1 & CentOS 8.1

Comment 8 Brian Lane 2020-01-20 17:45:25 UTC
I don't think we've ever officially supported installation to Mac hardware. We build the images with --nomacboot and we do not ship the hfs tools needed to make the HFS+ EFI partition that we use in Fedora.

Comment 9 Jose Deniz 2020-01-20 17:58:58 UTC
I can confirm RHEL 7 was able to install without any problem, at least, Macbooks Pro 12,1  11,1 and 11,4; also iMac 12,2 and MacBook Air

Now it can also be installed, but efi partition needs to be built and populated manually, being an additional manual step. atm we have ten different units migrated from 7.7 running 8.1 (CentOS clone)

I can not say if it was officially supported in 7.x but it worked OOB

Comment 10 Ben Konrath 2020-01-26 11:57:56 UTC
I also have this problem installing on the MacBook Pro (12,1 / 2015). I'm trying to dual boot with MacOS 10.5 and the EFI partition is actually already FAT as created by a fresh install (installed OS X 10.10 and then upgraded to MacOS 10.15). This error is a bit surprising to me given that I wouldn't need to have an HFS+ EFI partition created. I could be missing something though.


(In reply to Jose Deniz from comment #9)
> Now it can also be installed, but efi partition needs to be built and
> populated manually, being an additional manual step. 


Did you have to do anything else to get your machines up and running besides the workaround Juan Manuel Parrilla Madrid posted in comment 1?

It might interesting for some of you to see other workarounds that people are doing (including installing Oracle 8 Linux and then converting to CentOS 8):

https://forums.centos.org/viewtopic.php?t=71821

It would be nice if installing RHEL / CentOS 8 on Apple hardware would work like it did on version 7 - even if it's not officially supported.

Comment 11 Jose Deniz 2020-01-29 06:58:24 UTC
(In reply to Ben Konrath from comment #10)
> Did you have to do anything else to get your machines up and running besides
> the workaround Juan Manuel Parrilla Madrid posted in comment 1?

I simply follow steps from comment 1. But it's not dual boot. It uses only CentOS 8 so we wipe the disk. I also use a kickstart via Foreman to build them automatically. (Actually about 20 Mac laptops have been installed using it)
So as a workaround basically for your scenario I recommend you to use rEFInd boot manager to get a dual OS disk booting properly.
Perhaps building a custom DUD with mactel-boot and HFS+ tools (as per comment #8) could make the job. I'll try it and if it's successful I'll open a ticket in elrepo to include it there. That also could be a way to solve it and make RHEL8-CentOS8 available to Mac hardware.

Comment 12 Ben Konrath 2020-01-29 11:20:36 UTC
(In reply to Jose Deniz from comment #11)
> Perhaps building a custom DUD with mactel-boot and HFS+ tools (as per
> comment #8) could make the job. I'll try it and if it's successful I'll open
> a ticket in elrepo to include it there. That also could be a way to solve it
> and make RHEL8-CentOS8 available to Mac hardware.

I also thought about this as a potential solution but I didn't know how to get started. I'm curious to heard about the results.

Comment 13 David Lehman 2020-02-11 15:18:33 UTC
Comment 8 is correct. The lack of support for Mac hardware is not a bug or a mistake.

Comment 14 Matt 2020-02-12 14:20:12 UTC
Well, that's surprising that RH would write off ~12% of the PC market for what doesn't seem like a good reason. RHEL/CentOS 7 creates a normal vfat EFI partition for my mac. I could see RH not supporting dual-boot which requires HFS+, but it doesn't seem like there's anything wrong with a normal install other than an installer bug.

Comment 15 Ben Konrath 2020-02-12 15:34:52 UTC
Just thought I'd clarify some misunderstandings I've read here. Dual booting OS X / MacOS with Linux does not require an HFS+ EFI partition. It works fine with a normal vat EFI partition as I've been using with CentOS 7.

I've never installed a distro with the HFS+ support (e.g. Fedora) but I think the HFS+ EFI partition just gets you a better menu entry with the OS name when you hold command and boot to select which OS you want to boot. With vfat, it's listed as something like "EFI other".

I don't deal with stuff day-to-day so I might not understand things correctly - please do correct me if I'm missing something. That said, I do feel there is a bug here. Passing the --nomacboot flag should just disable the HFS+ EFI partition stuff and allow the normal vfat EFI partition setup to work (which works fine on Apple hardware). But instead, it seems Apple hardware is detected somehow and the installation fails due to the missing mactel-boot package. Maybe the --nomacboot flag only removes the mactel-boot package without removing or disabling the code that checks for Apple hardware.

I do hope that this issue can be reconsidered to be fixed. It seems there is demand from within Red Hat and from potential non-Red Hat RHEL and CentOS 8 users such as myself. At the end of the day, it's just a product decision if RHEL doesn't support running on Apple hardware as point of policy, then I understand that fixing this bug may not be a priority. I might end up filing a bug in the CentOS bug tracker to see if the CentOS developers can address this somehow in the context of that project.

Comment 16 Matt 2020-02-24 14:23:42 UTC
In the beating a dead horse department, I tried the method in #1, and found a somewhat cleaner route. Thanks for the ideas to get me started.

Start:
- Boot Centos/RHEL 8 ISO Normally (I used 8.1 of each)
- Do the normal setup of network, packages, etc.
- Enter disk partitioning
  - Select your disk
  - At the bottom, click the "Full disk summary and boot loader" text
     - Click on the disk in the list
     - Click "Do not install boot loader"
     - Close
  - Select "Custom"  (I didn't try automatic, but it probably would not create the EFI partition)
  - Done in the top left to get to the partitioning screen
  - Delete existing partitions if needed
  - Click +
     - CentOS 8: create /boot/efi mountpoint, 600M, Standard EFI partition
     - RHEL 8: create /foo mountpoint, 600M, Standard EFI partition, then edit the partition to be on /boot/efi
  - Click + repeatedly to create the rest of the partitions as usual (/boot, / swap, /home, etc.)
  - Done
- During the install, there may be an error about the mactel package, just continue
- On reboot, both times I've let it get to the grub prompt, but there's no grub.cfg; not sure if this is required
- Boot off ISO into rescue mode
  - Choose 1 to mount the system on /mnt/sysimage
  - At the shell, chroot /mnt/sysimage
  - Check on the files in /boot to make sure they exist: ls -l /boot/ /boot/efi/EFI/redhat (or centos)
  - Run the create the grub.cfg file: grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
     - I got a couple reload ioctl errors, but that didn't seem to hurt anything
  - exit
- Next reboot should be fine, and as mentioned above it'll reboot after SELinux labelling

Comment 19 Aki Ketolainen 2020-11-24 15:42:45 UTC
Matt: Thanks this helped also with installing Fedora 32 onto an iMac 2011 with UEFI. If I didn't disable installing boot loader during install,
I would get an error something like "EFI system partition cannot be of type efi".

Comment 20 edulimit 2021-01-27 20:57:57 UTC
(In reply to Matt from comment #16)

Hi Matt,

Thank you for your description of the current workaround. I am kind of new with Linux so I am unsure which partitions I need to create in order to deploy RHEL on my MacBookPro15.1. Would it be possible for you to indicate what partitions did you create in the steps below, e.g. names, size etc. Maybe an scheme of your partition-map. Also Did you use dual-boot or format the whole disk?:


>   - Click +
>      - CentOS 8: create /boot/efi mountpoint, 600M, Standard EFI partition
>      - RHEL 8: create /foo mountpoint, 600M, Standard EFI partition, then
> edit the partition to be on /boot/efi
>   - Click + repeatedly to create the rest of the partitions as usual (/boot,
> / swap, /home, etc.)
>   - Done
> - During the install, there may be an error about the mactel package, just
> continue

Thank you for your help. 

Ed

Comment 21 Jon 2021-04-02 17:04:37 UTC
Hi Matt,

I’m Newbie to bugzilla. Fedora 33 fails to boot and install on Mac Mini 2018 but successfully installs on 32GB flash for 2016 MacBook Air by Anaconda.

/dev/sdb/sdb1  fat32 600mb flag=boot, esp
/dev/sdb/sdb2  name=hfs+esp 600mb 
/dev/sdb/sdb3  ext4 1Gb 
/dev/sdb/sdb4  btrfs fedora_localhost-live 26.5Gb

Is this a vendor or device specific issue? Is there a fix coming in release 34?

Thanks for pointing me in the right direction.

Jon

Comment 22 Matt 2021-04-07 19:29:03 UTC
(In reply to edulimit from comment #20)
> Hi Matt,
> 
> Thank you for your description of the current workaround. I am kind of new
> with Linux so I am unsure which partitions I need to create in order to
> deploy RHEL on my MacBookPro15.1. Would it be possible for you to indicate
> what partitions did you create in the steps below, e.g. names, size etc.
> Maybe an scheme of your partition-map. Also Did you use dual-boot or format
> the whole disk?:

I'm not dual-booting technically, the MacMini I'm using has two drives; one still has macOS on it, the other I wiped completely for CentOS. Presumably the MacBook only has one drive so you'd have to figure out how to resize the Mac stuff if you wanted both.

Best bet for partitions would be to tell the installer to auto-partition and note the layout (although I can't remember if it'll fail due to the bug or not), then follow the workaround.

The standard partition layout is something like:
/boot/efi - 600M (EFI)
/boot - 1024M (Standard partition)
/ 50G (LVM)
swap - system memory size (LVM) - although I often change it to something like 2 or 4 GB if I'm short on space) (LVM partition)
/home - rest of disk (LVM) - I often make this some smaller size so I can create other volumes later, but I'm not sure that's really necessary)

If this doesn't make sense, I'll try to remember to grab a partition layout next time I'm on that system.

Comment 23 Matt 2021-04-07 19:35:52 UTC
(In reply to Jon from comment #21)
> Hi Matt,
> 
> I’m Newbie to bugzilla. Fedora 33 fails to boot and install on Mac Mini 2018
> but successfully installs on 32GB flash for 2016 MacBook Air by Anaconda.
> 
> /dev/sdb/sdb1  fat32 600mb flag=boot, esp
> /dev/sdb/sdb2  name=hfs+esp 600mb 
> /dev/sdb/sdb3  ext4 1Gb 
> /dev/sdb/sdb4  btrfs fedora_localhost-live 26.5Gb
> 
> Is this a vendor or device specific issue? Is there a fix coming in release
> 34?

No idea. I do have Fedora 33 on my Mac Mini (mid-2010), but I'm not using btrfs. I don't remember if there was no drama installing it or if I used the process above to fix it. I just looked at the partitions and it's the same as what you have listed other than sda4 for me is LVM (and xfs file systems).

Comment 25 Red Hat Bugzilla 2023-09-15 00:18:39 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days

Comment 26 Dave H. 2023-10-19 00:07:06 UTC
Comment 16 by @matthew.piechota was extremely helpful.  In fact, I would never have figured it out without that guidance.  Thanks!

I installed RHEL 9.2.  I was stuck after running through the steps, so I started over a few times from scratch and this is what I figured out.

Basically I wasn't deleting the EFI partition from the Mac drive, which was a mistake.  The Mac drive should be completely free of partitions before doing the RHEL install.  (I'm not sure if dual-boot OSx/RHEL is possible without a lot of grub expertise.  I only cared to have RHEL on these old Macs, so I was good with deleting the Mac partitions.)

My preparatory steps:

1. Booted the Mac (Mini) into recovery mode Apple Key + R.
2. Used Disk Utility to erase the drive.  I created a couple of new partitions (PART1 and PART2) so I had something to delete in the next step.  That probably wasn't necessary but it made me feel better.
3. Used Terminal app to examine then remove all partitions:

diskutil list
diskutil list /dev/disk0
diskutil eraseVolume free PART2 disk0s3
diskutil eraseVolume free PART1 disk0s2
diskutil eraseVolume free EFI disk0s1

Then the RHEL installation:

4. Inserted the RHEL 9.2 installation media (USB flash drive) into the Mac and rebooted holding the Option/Alt key.  Booted the RHEL installation using EFI Boot and started the RHEL installation.

5. When I arrived at the installation options screen, I followed Matt's Comment 16 steps to configure the installation partitioning options.  This is additional guidance based on my experience:

 - It is very important to not install the boot loader, so don't miss that step to turn off that option (the blue link at the very bottom of the screen).
 - After clicking Storage Configuration "Custom" then the Done button causing the Manual Partitioning screen appeared, I clicked "Click here to create them automatically" in the upper left of the screen.  This created the partitions for me, which was a handy short cut.
 - Since my drive is only 500GB, I had to update the size of the /home partition, lowering the default size by 2G to make room for the new "/foo" EFI boot partition that Comment 16 has us create (I could have gotten away with 1G, but I wanted to leave 1G of free space, just in case I needed it later).  Don't forget to click "Update Settings" so your change sticks.
 - Then I clicked + sign to create the /foo partition as instructed in Comment 16, made it 1G size, updated its Device Type to a Standard Partition and Changed its File System to EFI System Partition.  (This was the step that I screwed up in previous attempts, because there was an old EFI partition left on the disk from the Mac installation).  Make sure to update the mount point name from "/foo" to "/boot/efi" and click Update Settings.
 - I clicked "Done" and then had to click "Apply Changes" in the pop-up window to allow the installer to make the partitioning changes on the disk.

6. I completed all of the other installation option settings and began the installation.

7. I did get that missing mactel-boot error, but I clicked Yes to allow the installation to continue.

8. At the end of the installation I let the Mac reboot by clicking Reboot System. I selected the first grub menu option (the default) and RHEL 9.2 came up.  I didn't need to do anything in grub2 as mentioned in Comment 16.  It just worked.  I assume that the grub.cfg gets produced, maybe that was fixed for RHEL 9.2 install.

I successfully repeated the installation on a second Mac, so this process is 2 for 2.

Thanks to @matthew.piechota for Comment 16!

Comment 27 Matt 2024-02-14 12:21:28 UTC
(In reply to Dave H. from comment #26)
> Thanks to @matthew.piechota for Comment 16!

Nice! I've been wondering if RHEL9 worked but haven't tried it myself.


Note You need to log in before you can comment on or make changes to this bug.