Bug 746901
Summary: | Apple computers require MBR (full or 'hybrid', not protective) to boot Fedora in CSM mode | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Murphy <bugzilla> |
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | anaconda-maint-list, awilliam, bcl, bloch, costan, csvanefalk, ehoekema, esok127, jonathan, lfelipebm, marius.andreiana, meltingrobot, mishu, psj, somlo, the.ridikulus.rat, vanmeeuwen+fedora |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-01-06 19:28:35 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Chris Murphy
2011-10-18 07:58:02 UTC
Same thing here on a Mac Mini. I have managed to install F16 as standalone, but the suggested fix seems to only work if you use the LVM partition layout. At the end of the process, I ended up with 3 partitions (as listed by gdisk): 1. BIOS boot, 2. Linux boot (/boot) and 3. Linux LVM. After finishing installation from LiveCD, before I rebooted, I´ve entered gdisk and issued the recovery menu and then created new hybrid MBR, adding to it only the 3. Linux LVM partition. Then, I could reboot with no problem and the grub menu was working just fine. (In reply to comment #1) > Same thing here on a Mac Mini. I have managed to install F16 as standalone, but > the suggested fix seems to only work if you use the LVM partition layout. No, as I wrote: "I am adding the lvm because it's last in the list, and GPT partitions 1-4 all end up in the 1st MBR partition (type EE, the protective MBR). Other combinations are possible and work..." If you're not using LVM that's fine. I'd still suggest the last partition be the only one to go into the MBR as partition 2. That last partition if you don't use LVM is probably linux root. All of the other GPT partitions get stuffed into the protective MBR as partition 1, hex code 0xEE. I can confirm that the gdisk workaround as described in the initial report worked for me. I had the same partition layout. (It is frustrating though, that for a number of Fedora releases in a row, the Macbook dual boot scenario has failed out of the box.) *** Bug 503149 has been marked as a duplicate of this bug. *** -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers It seems to me we kind of have multiple scenarios to consider here, assuming we want to 'support' installing to Macs via CSM at all: 1. User has a Mac with OS X on it. They download a Fedora install image and run it. They don't know anything about Boot Camp, they haven't do any Boot Camp prep. They expect to install Fedora alongside OS X. Assuming we're in CSM mode for the nonce (I'm not sure if this is true, but let's assume it), for dual-boot to work, Fedora is going to have to understand how to create a hybrid MBR that OS X will be happy with, right? 2. User has a Mac with OS X on it, and tries to use Boot Camp to prepare a hybrid MBR and partitions for Fedora before installing it. Is this ever going to work, or can Boot Camp only really handle creating a hybrid MBR and partitions for *Windows*? 3. User tries to do a complete wipe of OS X and install Fedora as the only OS. In this case 'all' we need to do is create a conventional MBR rather than use GPT, right - so for this scenario, on F16, all you need to do is pass 'nogpt'? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers (In reply to comment #6) 1: Correct. However you have an earlier problem which is resizing the existing file system to make room for Fedora. Boot Camp is the only included GUI means for resizing an existing jhfs+ volume and creating "free space" which is actually formatted FAT32. 2. Boot Camp helps resize an existing jhfs+ volume so that there is at least space for a Fedora installation. This is the first step in Boot Camp. Subsequent steps involve downloading Windows only drivers, and doing initial installation work. But as the resulting "free space" is FAT32, presently anaconda won't do an automatic partitioning to use a FAT32 partition that otherwise doesn't contain anything. It would be nice if 'Free Space' installation type would use FAT32 if there's nothing on it. Or ask. Further, in every case so far I've seen parted get involved, it blows away the hybrid MBR leaving only a protective MBR. 3. Correct. I have done this, and at least Fedora installs. But I never kept it around long enough to see how well the resulting system works. An unanswered question I have with this scenario is the consequence of not having the Firmware.scap file present on the EFI system partition. I do not know if this is used by Apple's CSM or what. This is a 15MB file, which only becomes present on the EFI System partition if Mac OS X is installed, and connected to the internet, and there is a first user login. If those three things aren't true, the file is not downloaded. If they are true, it is silently downloaded without user being informed. chris: right, for the disk space thing, if we wanted to make it work without previous configuration, we might want to support jhfs+ resizing (if possible) and/or recognize the fingerprints of a 'post-bootcamp' layout and blow away the FAT32 partition. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Still a problem with Fedora-17-Nightly-20120307.09-x86_64-Live-kde.iso and CSM-BIOS mode boot method. Resulting installation will not boot Fedora without manual post-install creation of hybrid MBR. Closing this as not a bug. Supporting CSM and hybrid MBRs is perilous. EFI work on GRUB2 and the mactel boot package obviates this bug. |