The installer no longer uses mactel-boot.x86_64 package on Intel Macs. The result does work but there are pretty significant changes as a result: a. The existing FAT32 EFI System partition is now used, instead of a new partition formatted HFS+ and dedicated for Fedora. b. The user now sees an EFI boot volume in the firmware built-in boot manager, instead of a Fedora Linux volume. c. The user no longer sees a Fedora Linux volume in the macOS Startup Disk panel. d. Different results from Fedora variants that don't use webui. I don't think any of this is untenable. It's just unexpected, and I'm uncertain if it's intentional. But we could note this in Common Bugs so it gets some visibility. Tested with Fedora-Workstation-Live-42-20250215.n.0.x86_64.iso on MacBookPro9,2 (mid-2012) Reproducible: Always
I would rather we fixed this because it's a point of pride that we actually have that integration. It's very user-visible stuff.
I believe this regressed with: https://github.com/rhinstaller/anaconda/commit/708a8f909bc385396189b241f6a4dd3bd79917f3
This cannot be related to Web UI.Re-assigning to our backend component.
@chris I see you tried to specify this as blocker for 42 though https://bugzilla.redhat.com/show_bug.cgi?id=2231339 This is not the proper way to propose blockers. Feel free to propose it as a blocker through the official fedora platform for this: https://qa.fedoraproject.org/blockerbugs/propose_bug
Btw. mactel-boot package was orphaned and retired from Fedora: https://src.fedoraproject.org/rpms/mactel-boot/c/da1c3e396cfab2224d1fba24c17a46f4a87a9a0a?branch=rawhide
Will not be able to support mactel-boot, see comment above.
I'll revive the component. As an owner of Intel Macs, I'd rather we not regress on this.
Package review request: https://bugzilla.redhat.com/show_bug.cgi?id=2353284
Removing this from a WebUI tracker, it is not at all related to Web UI.
This now just needs karma to land: https://bodhi.fedoraproject.org/updates/FEDORA-2025-870a78179f
1. Boot Fedora-Workstation-Live-42-20250319.n.0.x86_64.iso 2. rpm -iv mactel-boot-0.9-35.fc42.x86_64.rpm 3. Performed an installation using the default option (I'll call it preserve existing OS and install into free space, because I failed to take a screenshot) It still uses the EFI System partition for shim and grub, a separate "HFS ESP" isn't created. Boots OK though. I'll attached anaconda logs for this installation.
Created attachment 2081367 [details] storage.state
Created attachment 2081368 [details] storage.log
Created attachment 2081369 [details] program.log
Created attachment 2081370 [details] anaconda.log
Clarification on comment 11, step 2 - this installs mactel-boot in volatile storage in the LiveOS environment. So it should be available to anaconda.
Here's the comps PR to restore it: https://pagure.io/fedora-comps/pull-request/1104
Fedora-Workstation-Live-42-20250324.n.0.x86_64 doesn't have mactel-boot still. Booted it anyway and installed mactel-boot-0.9-35.fc42.x86_64.rpm then ran the installer. Same result. It uses existing FAT32 ESP. Unfortunately I'm losing access to this system for testing for the rest of this cycle. Is there a way to trick Anaconda into thinking a qemu-kvm is a Mac?
Seems like the reason why this bug is still happening is bug 2354671. Anaconda thinks Windows is installed, therefore it doesn't do whatever mactel-boot tells it to do?
(In reply to Chris Murphy from comment #19) > Seems like the reason why this bug is still happening is bug 2354671. > Anaconda thinks Windows is installed, therefore it doesn't do whatever > mactel-boot tells it to do? With bug 2354671 fixed I think you can check if this works now ? :)
I've lost access to the hardware used for testing. If there's a way to get Anaconda to think a VM (qemu/kvm) is a Mac, I can retest.
F42 Final image contains mactel-boot and bug 2354671 is resolved. Is there anyone who can confirm whether this is fixed?