How can we make F17 be able to boot on Macs (with or without reFit)

[Chris Murphy]

First post. I stumbled across this subject while performing an unrelated search.

I have found EFI booting Apple hardware is problematic on the two models I've tested. I think these are kernel related problems that would need to be sorted out to get a full boot and startup to a GUI login. CSM-BIOS boot works OK on these models.

Apple hardware tested:
mbp41 = MacBookPro 4,1 (2008), Nvidia Geforce8600M GT.
mbp82 = MacBookPro 8,2 (2011), Intel HD Graphics 3000 and AMD Radeon HD 6750M.

1. mbp41 booting is inconsistent. Without additional kernel parameters I generally end up with one of three results: successful boot to GUI login window; hang at nouveau (dmesg points to VBIOS corruption having occurred very early during boot); hang when unpacking initramfs (possibly the same intermittent corruption of VBIOS, causes corruption when unpacking initramfs).

With 'nomodeset' I usually am able to boot and complete startup except for x. So it's a text only situation. But all other function appears reliable.

https://bugzilla.redhat.com/show_bug.cgi?id=751147

2. mbp82 booting of kernel and initramfs appears to work 100% of the time. However immediately after a GRUB menu item is chosen, GRUB-EFI vanishes and is replaced with garbage on the screen. I speculate that in this boot mode, both video adapters are active at the same time and are conflicting maybe? In any event, I can't see anything. But it is possible to ssh into the computer or blindly type commands and they all appear to work.

https://bugzilla.redhat.com/show_bug.cgi?id=765954

Also, all EFI testing I've done is without rEFIt as I feel it adds another layer of unknowns to the process.


Chris Murphy

[Chris Murphy]

Volume 2

CSM-BIOS boot notes:

Apple hardware tested:
mbp41 = MacBookPro 4,1 (2008), Nvidia Geforce8600M GT.
mbp82 = MacBookPro 8,2 (2011), Intel HD Graphics 3000 and AMD Radeon HD 6750M.

All notes based on booting with the Apple-EFI option-key startup menu to choose how to boot, not rEFIt.

1. After default install using any installation type, and reboot, neither model loads GRUB2 (and thus does not boot) by default. Pre or post-install work is needed.

2. Both models CAN boot and startup Fedora to a GUI login with pre- or post-install work.

a. 'nogpt' kernel parameter for Fedora only installs produces a bootable system without post-install work.

b. In dual-boot (Mac OS + Fedora) anaconda isn't creating a hybrid MBR post-install, therefore Apple's EFI startup disk menu doesn't see the F16 installation. Further, creating the hybrid MBR in advance is useless as parted wipes out the hybrid MBR in favor of a protective MBR just prior to installation. (See 3 below for additional fallout of this behavior.)

c. Triple boot (Mac OS, Fedora, Windows) is possible, but there are more ways this won't work, than will work. And more ways that will work, but aren't good partition schemes (invitations for data loss) since there really isn't such a thing as a safe hybrid MBR + GPT. I have found one or two that I think are about as "safe" as they can get, and it means that the user needs to install Mac OS, Windows, Fedora, in that order, but located on the disk in order: Mac OS, Fedora, Windows.

3. Anaconda + parted consistently remove pre-existing hybrid MBRs, replacing them with protective MBRs. The hybrid MBR will exist in a case where Windows has already been installed (using Apple's Bootcamp application). If removed in favor of a protective MBR, Windows is no longer bootable. So not only is Fedora not bootable, a previously bootable Windows is no longer bootable. This happens with either EFI or BIOS mode installs of Fedora.

So either anaconda needs to proceed no further upon discovery of a hybrid MBR, or it needs to become pretty good at sorting out hybrid MBR and GPT schemes that are "safe".

4. gptsycnc: I don't think gptsync has such a sophisticated heuristic for creating such hybrid MBRs - I regularly see it produce very linear MBRs while suggesting huge percentages of the disk are empty. Any MBR only aware tool would see these areas as fair game - what I call an invitation for data loss and probably not a good idea.

5. If all requirements are met, Apple's startup disk menu (option-key at startup chime) will present a single "Windows" disk icon which if selected will load GRUB2 and its menu. That "Windows" label is apparently hard coded in Apple's EFI for any foreign OS requiring legacy CSM-BIOS booting.



Additional EFI boot notes:


1. By default EFI//EFI/redhat/grub.efi isn't found by Apple's EFI and install a choosable option. If it and the .conf are moved to EFI//EFI/BOOT/BOOTX64.efi and .conf, both models have an "EFI Boot" labeled disk icon in the option-key startup menu. I'm guessing like the "Windows" equivalent, that "EFI Boot" is hardwired.

This is being addressed by this:
https://bugzilla.redhat.com/show_bug.cgi?id=755093


2. GRUB-EFI (legacy) regularly just hangs are loading the kernel and initramfs, on mbp41. I don't have this problem with GRUB2-EFI but I still have other problems mentioned in the previous email.



Chris Murphy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20111224/0f836c04/attachment.html>

[Chris Murphy]

Responding to my own email on various boot behaviors, with some editorialization.

EFI vs CSM-BIOS:

EFI boot produces highly variable results between Apple models, while CSM-BIOS boot is very consistent between Apple models.

Windows 7 will not boot in UEFI mode on Apple hardware. I have searched thoroughly and have found no success stories so far. Even if it has been done, it's outside of what normal people are willing or able to do. Yet CSM-BIOS booting works fine on all of Apple's hardware for the past 4-5 years. This makes some sense, because Microsoft says they explicitly support UEFI 2.x and higher only, while Apple's firmware is based on Intel EFI 1.10, not UEFI 2.x.

CSM-BIOS boot is not ideal. But it's also not ideal to support a flakey EFI boot scenario that may take a lot of effort for low efficacy.

Also consider Mac users are running into the BIOS-MBR 2.2TB limit on Apple hardware. It stands to reason Apple will need to make some modifications to their EFI implementation to deal with this eventually. This accommodation of Windows (U)EFI requirements may be good for linux, or may be bad for linux. I think investing in Apple EFI unknowns is risky.

Further, consider CSM-BIOS has the best chance of supporting Fedora when Apple releases new hardware. It may take months or years to support the peculiarities of each model's EFI.

So if I were voting, I'd suggest a constrained type of support for CSM-BIOS boot, both Fedora only (atypical) and dual boot (typical).


Triple Boot:

This is possible, I've done it with several combinations, but it's non-trivial. I question if gptsync is at all appropriate for making sure the resulting hybrid MBR and GPT aren't a disaster (more often than not gptsync produces ill advised hybrid MBRs, more so than they already are).

The big gotcha with triple boot support, is that the most common situation is the existence of Mac OS and Windows, which means there is a hybrid MBR and GPT. This means a Fedora installation must make sure both an appropriate MBR and GPT are produced not merely so that all three systems to boot as expected, but to ensure neither of the previously working systems become unbootable. Today this is not the case with Fedora 16. Anaconda+parted blow away such a hybrid MBR in favor of GPT only with protective MBR, the result of which is an unbootable Windows (Mac OS remains bootable).

Even refusing to install Fedora (or a warning about the consequences) would be a much needed improvement here.


A bit about Apple's philosophy:

Apple doesn't sell hardware. They don't sell operating systems. They sell an experience that combines both. That's how they see it. The two are inseparable.

At best they "tolerate" Windows support, and not just any Windows, only Windows 7 is supported for the better part of a year now. I have zero doubt they'd be baffled by the idea anyone would want to run linux on a Mac, and would not care one single bit if it could not be done with either EFI or CSM-BOOT modes.

This is the hallmark company that does not believe users have any right to boot an operating system of their choice on any hardware they produce. People who buy Apple hardware today cannot even run the most recent previous version of Mac OS 10.6.8 (released July 28 2011) - it simply won't boot on their hardware.

I am leery of excessive amounts of effort, which in effect is a kind of turd polishing, to deal with Apple's non-standard EFI. I don't like being relegated to CSM-BIOS mode booting, but it does work, with well understood limitations.


Chris Murphy

[Todd V Orvieto]

Chris,
I got really frustrated with triple boot on Max OS X Lion. At one point I had it working on snow leopard pretty well. After many frustrating hours spent trying to get it setup I sold my MBA on eBay then bought a hp dm1 4050. The HP is much faster and now I can boot Linux and windows much easier plus I walked away with $300 in cash. My buddy who works for Apple has told me that the installation of refit voids the warranty and they have refused to fix computers under warranty with refit installed. I think this is bummer because the Apple hardware is good, it makes no sense why Apple cares. After I read snobs biography, where he dose not even mention open source despite the large amount of open source software used by Apple I decided I would switch back to a pc based laptop. I do still like the iPad but that is a different story.....

Sent from my iPad

Post by Chris Murphy
Responding to my own email on various boot behaviors, with some editorialization.
EFI boot produces highly variable results between Apple models, while CSM-BIOS boot is very consistent between Apple models.
Windows 7 will not boot in UEFI mode on Apple hardware. I have searched thoroughly and have found no success stories so far. Even if it has been done, it's outside of what normal people are willing or able to do. Yet CSM-BIOS booting works fine on all of Apple's hardware for the past 4-5 years. This makes some sense, because Microsoft says they explicitly support UEFI 2.x and higher only, while Apple's firmware is based on Intel EFI 1.10, not UEFI 2.x.
CSM-BIOS boot is not ideal. But it's also not ideal to support a flakey EFI boot scenario that may take a lot of effort for low efficacy.
Also consider Mac users are running into the BIOS-MBR 2.2TB limit on Apple hardware. It stands to reason Apple will need to make some modifications to their EFI implementation to deal with this eventually. This accommodation of Windows (U)EFI requirements may be good for linux, or may be bad for linux. I think investing in Apple EFI unknowns is risky.
Further, consider CSM-BIOS has the best chance of supporting Fedora when Apple releases new hardware. It may take months or years to support the peculiarities of each model's EFI.
So if I were voting, I'd suggest a constrained type of support for CSM-BIOS boot, both Fedora only (atypical) and dual boot (typical).
This is possible, I've done it with several combinations, but it's non-trivial. I question if gptsync is at all appropriate for making sure the resulting hybrid MBR and GPT aren't a disaster (more often than not gptsync produces ill advised hybrid MBRs, more so than they already are).
The big gotcha with triple boot support, is that the most common situation is the existence of Mac OS and Windows, which means there is a hybrid MBR and GPT. This means a Fedora installation must make sure both an appropriate MBR and GPT are produced not merely so that all three systems to boot as expected, but to ensure neither of the previously working systems become unbootable. Today this is not the case with Fedora 16. Anaconda+parted blow away such a hybrid MBR in favor of GPT only with protective MBR, the result of which is an unbootable Windows (Mac OS remains bootable).
Even refusing to install Fedora (or a warning about the consequences) would be a much needed improvement here.
Apple doesn't sell hardware. They don't sell operating systems. They sell an experience that combines both. That's how they see it. The two are inseparable.
At best they "tolerate" Windows support, and not just any Windows, only Windows 7 is supported for the better part of a year now. I have zero doubt they'd be baffled by the idea anyone would want to run linux on a Mac, and would not care one single bit if it could not be done with either EFI or CSM-BOOT modes.
This is the hallmark company that does not believe users have any right to boot an operating system of their choice on any hardware they produce. People who buy Apple hardware today cannot even run the most recent previous version of Mac OS 10.6.8 (released July 28 2011) - it simply won't boot on their hardware.
I am leery of excessive amounts of effort, which in effect is a kind of turd polishing, to deal with Apple's non-standard EFI. I don't like being relegated to CSM-BIOS mode booting, but it does work, with well understood limitations.
Chris Murphy
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Chris Murphy]

Post by Todd V Orvieto
Chris,
I got really frustrated with triple boot on Max OS X Lion. At one point I had it working on snow leopard pretty well.

A possible problem with Lion is not technically with Lion itself. When 10.7 is installed, there is an additional partition created called Recovery HD, which contains a minimal system for booting a limited environment. Because of this, out of the gate you have at least three partitions: sda1, sda2, sda3. You can only add one more partition and have parity with a hybrid MBR and I'll bet gptsync does this incorrectly. And there are also 2.2TB concerns because of course the Windows partition can't go beyond the 2.2TB limit. So how the MBR should look in a triple boot, is unique. I've done probably 2-3 dozen installs and figured out one that's ideal for less than 2.2TB disks, and one or two that are tolerable, but still gross lies, for 2.2TB+ drives.

It also requires giving up on the Windows bootloader and use GRUB2 for bootloading both Windows and Fedora.

Post by Todd V Orvieto
My buddy who works for Apple has told me that the installation of refit voids the warranty and they have refused to fix computers under warranty with refit installed.

Well that's completely bogus. I've heard this myth before, I don't know where it started. I think some traveling support crew probably were misinformed that rEFIt is an EFI firmware replacement, and if it were true that people were flashing Apple's firmware with some 3rd party firmware, they'd be able to void warranties. But rEFIt is not firmware, it's a set of EFI applications and drivers. So whoever says this is completely full of crap and doesn't know what they're talking about.

Post by Todd V Orvieto
I think this is bummer because the Apple hardware is good, it makes no sense why Apple cares.

Apple doesn't care to support foreign OS's.


Chris Murphy

[Andreas Tunek]

Has there been any more tests getting F17 to boot on macs, with or without
refit? I would love to test, but if macs are not any target hardware for
fedora it would be pretty pointless.

/Andreas

Post by Todd V Orvieto

Post by Todd V Orvieto
Chris,
I got really frustrated with triple boot on Max OS X Lion. At one

point I had it working on snow leopard pretty well.
A possible problem with Lion is not technically with Lion itself. When
10.7 is installed, there is an additional partition created called Recovery
HD, which contains a minimal system for booting a limited environment.
Because of this, out of the gate you have at least three partitions: sda1,
sda2, sda3. You can only add one more partition and have parity with a
hybrid MBR and I'll bet gptsync does this incorrectly. And there are also
2.2TB concerns because of course the Windows partition can't go beyond the
2.2TB limit. So how the MBR should look in a triple boot, is unique. I've
done probably 2-3 dozen installs and figured out one that's ideal for less
than 2.2TB disks, and one or two that are tolerable, but still gross lies,
for 2.2TB+ drives.
It also requires giving up on the Windows bootloader and use GRUB2 for
bootloading both Windows and Fedora.

Post by Todd V Orvieto
My buddy who works for Apple has told me that the installation of refit

voids the warranty and they have refused to fix computers under warranty
with refit installed.
Well that's completely bogus. I've heard this myth before, I don't know
where it started. I think some traveling support crew probably were
misinformed that rEFIt is an EFI firmware replacement, and if it were true
that people were flashing Apple's firmware with some 3rd party firmware,
they'd be able to void warranties. But rEFIt is not firmware, it's a set of
EFI applications and drivers. So whoever says this is completely full of
crap and doesn't know what they're talking about.

Post by Todd V Orvieto
I think this is bummer because the Apple hardware is good, it makes no

sense why Apple cares.
Apple doesn't care to support foreign OS's.
Chris Murphy
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120228/138f7203/attachment.html>

[Matthew Garrett]

Post by Andreas Tunek
Has there been any more tests getting F17 to boot on macs, with or without
refit? I would love to test, but if macs are not any target hardware for
fedora it would be pretty pointless.

Yes, F17's current media should be pretty close to working.

[Michele Baldessari]

Post by Matthew Garrett

Post by Andreas Tunek
Has there been any more tests getting F17 to boot on macs, with or without
refit? I would love to test, but if macs are not any target hardware for
fedora it would be pretty pointless.

Yes, F17's current media should be pretty close to working.

FWIW I installed F16 some time ago and upgraded just yesterday to F17
(via the rc4 iso) just fine on my MacbookAir4,1.
F16 didn't have a working graphical anaconda (Intel HW was too new), F17
upgrade went perfectly. So Kudos to everyone ;)

cheers,

[Andreas Tunek]

Post by Matthew Garrett

Post by Andreas Tunek
Has there been any more tests getting F17 to boot on macs, with or without
refit? I would love to test, but if macs are not any target hardware for
fedora it would be pretty pointless.

Yes, F17's current media should be pretty close to working.

Is this on native/basic Apple EFI, not reFit?

/Andreas

Post by Matthew Garrett
--
Matthew Garrett | mjg59 at srcf.ucam.org
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Matthew Garrett]

Post by Andreas Tunek

Post by Matthew Garrett
Yes, F17's current media should be pretty close to working.

Is this on native/basic Apple EFI, not reFit?

Yes. I'm mostly working on the netinst isos, and right now if you take
that and dd it onto a USB stick, then insert that and hold down alt on
boot, you'll get a Mac install. Unfortunately, alpha ended up getting
built with a grub that dies on any Macs that don't have built-in
ethernet, so you may have some problems with that. The alpha kernel also
has a bug that seems to trigger on Macs that results in incredible
slowness. But other than that! Fixed kernel is in the archive now, and
I've just commited a fix for the grub bug.

[Adam Williamson]

Post by Matthew Garrett

Post by Andreas Tunek

Post by Matthew Garrett
Yes, F17's current media should be pretty close to working.

Is this on native/basic Apple EFI, not reFit?

Yes. I'm mostly working on the netinst isos, and right now if you take
that and dd it onto a USB stick, then insert that and hold down alt on
boot, you'll get a Mac install. Unfortunately, alpha ended up getting
built with a grub that dies on any Macs that don't have built-in
ethernet, so you may have some problems with that. The alpha kernel also
has a bug that seems to trigger on Macs that results in incredible
slowness. But other than that! Fixed kernel is in the archive now, and
I've just commited a fix for the grub bug.

For the record, the incredible slowness bug is
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=795050 and is
documented at
https://fedoraproject.org/wiki/Common_F17_bugs#slooooooooooooooooow
(yes, I'm having some fun with the anchor names on the common bugs page,
and yes, my life is that tragic.)

[Chris Murphy]

Post by Matthew Garrett
Yes. I'm mostly working on the netinst isos, and right now if you take
that and dd it onto a USB stick, then insert that and hold down alt on
boot, you'll get a Mac install.

1.
http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fedora-17-Alpha-x86_64-netinst.iso

dd if=Fedora-17-Alpha-x86_64-netinst.iso of=/dev/rdisk1

2.
I get two additional icons to boot from, both named "EFI Boot". One is an orange USB icon, the other is a blue Fedora icon.

3.
If I choose the blue Fedora icon, I get a GRUB Legacy menu, let it time out. It appears to be loading data from the USB stick. After about 45 seconds, the computer reboots, and I'm at a Mac OS login window. No text error messages indicating why.

4.
I reboot with option key to get the AppleEFI boot menu, choose the orange USB "EFI Boot" icon, the same thing happens. 45 seconds, I get a reboot, and I'm at a Mac OS login window. No text error messages indicating why.

5.
In Mac OS X 10.7.3, Startup Disk panel, there are no additional boot options listed when the USB stick is inserted, yet there are two "ANACONDA" labeled volumes mounted.




The hardware is a Macbook Pro 4,1 (2008) model.

[Chris Murphy]

Prior attempt, I mentioned at the very bottom of the email, easy to miss, was a Macbook Pro 4,1 (2008) model.

---------------


Attempt 2 with different hardware: Apple Macbook Pro 8,2 (2011).

1.
Starting with a USB stick produced with the following:
http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fedora-17-Alpha-x86_64-netinst.iso

dd if=Fedora-17-Alpha-x86_64-netinst.iso of=/dev/rdisk1

2.
Inserting the USB stick while Mac OS 10.6.8 is running (I know, older OS on the newer hardware, I'm on crack), the Startup Disk panel does not show any additional options for booting.

3.
Rebooting, holding option key, I get two additional boot option icons both labeled "EFI Boot". One is an orange USB icon. The other is a blue Fedora icon.

4.
When choosing either option, I get the GRUB Legacy menu, it times down to zero, I get 7 seconds of USB stick activity, followed by a tone from the laptop I have only ever heard when doing firmware updates. Interval is approximately 0.7 seconds tone, 0.3 seconds silence, three times. Followed by 3 seconds of silence. Then repeats. It does not end on its own after 2 minutes, and the computer does not reboot. And the keyboard is not functional. I have to hold the power button for 5 minutes to force a shutdown.

Again, no text onscreen to indicate what the problem is - it's still at the GRUB window during all of this.



Chris Murphy

[Chris Murphy]

Post by Chris Murphy
http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fedora-17-Alpha-x86_64-netinst.iso
dd if=Fedora-17-Alpha-x86_64-netinst.iso of=/dev/rdisk1

I'm not sure if this is expected or not, but I make the following observations about the resulting USB stick, which appears to have a bogus GPT according to three utilities.

1.
GPT fdisk (gdisk) version 0.8.2

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Warning! Main partition table overlaps the first partition by 48 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/disk1: 3915776 sectors, 1.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): E2E967A4-B1E8-4D61-9F5D-37F99C3E603E
Partition table holds up to 128 entries
First usable sector is 48, last usable sector is 319454
Partitions will be aligned on 4-sector boundaries
Total free space is 1550 sectors (775.0 KiB)

Number Start (sector) End (sector) Size Code Name
2 58168 59483 658.0 KiB 0700 卉䡏批楲d灁汰e灁汰
3 59484 61323 920.0 KiB AF00 卉䡏批楲d灁汰e灁汰

Similar results but different Name encoding for gdisk on Fedora.


2.
parted on F17

Error: The backup GPT table is not at the end of the disk, as it should be.
This might mean that another operating system believes the disk is smaller.
Fix, by moving the backup to the end (and removing the old backup)?
Fix/Ignore/Cancel? i
Warning: Not all of the space available to /dev/sdb appears to be used, you can
fix the GPT to use all of the space (an extra 3596288 blocks) or continue with
the current setting?
Fix/Ignore? i
Error: Unable to satisfy all constraints on the partition.

3.
Apple's "gpt" program:

cd2:~ chris@ gpt show -l disk2
gpt show: error: bogus map
gpt show: unable to open device 'disk2': No such file or directory

[Chris Murphy]

Post by Chris Murphy

Post by Chris Murphy
http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fedora-17-Alpha-x86_64-netinst.iso
dd if=Fedora-17-Alpha-x86_64-netinst.iso of=/dev/rdisk1

I'm not sure if this is expected or not, but I make the following observations about the resulting USB stick, which appears to have a bogus GPT according to three utilities.

parted can't fix it.

gdisk then says the GPT is damaged and will not fix/restore the 1st partition which contains the bulk of the boot data.

gpt bails entirely.

AFAIK this ISO isn't valid, insofar as the GPT is invalid, but I'm not sure if that relates to the booting problems both computers are having.

I'm going to try making an EFI bootable USB stick using the latest livecd-tools and the F17-alpha-LiveCD and see where that takes me.

Chris Murphy

[Chris Murphy]

Following applies to a 2008, Macbook Pro 4,1

1.
Used livecd-tools-17.6-1.fc17 to successfully create an EFI bootable USB stick of Fedora-17-Alpha-x86_64-Live-Desktop.iso.

2.
Due to this bug: EFI boot fails on Macs with NVIDIA GeForce 8600M GT
https://bugzilla.redhat.com/show_bug.cgi?id=751147

I add 'nomodeset' kernel parameter. I know of no work around to get a GUI on this hardware. But it does boot kernel and most services.

3.
tty1 hangs at "Started Display Manager"
tty2 is functional, not sure how to get any information on what's up with tty1. Normally what I'm used to with EFI boot and nomodeset is X can't actually startup, but the rest of the services load, and I end up at a prompt.

4.
Out of 5 boot attempts, I get to a usable tty2 console and can reboot thrice.

Twice, I get a hang right after GRUB loads either the kernel or initrd, the GRUB splash screen is present with no text. The machine has hung and I have to hold the power button to shut down.

So on this hardware I'd say GRUB is marginally reliable.

5.
At reboot/poweroff time, there's a LOT of extra "garbage" information being produced on-screen compared to F16. It goes by quick enough and isn't logged, so I'm not sure if it's important. But I do get a reboot, albeit with about a 1 minute delay over F16.


Chris Murphy

[Chris Murphy]

Following applies to a 2011, Macbook Pro 8,2

1.
Used livecd-tools-17.6-1.fc17 to successfully create an EFI bootable USB stick of Fedora-17-Alpha-x86_64-Live-Desktop.iso.

2.
I get to the GRUB menu. Times out and starts to boot. Same result as: EFI boot failure to properly initialize graphics on Macs with Intel and AMD graphics
https://bugzilla.redhat.com/show_bug.cgi?id=765954


So no improvement so far over F16 on either hardware. But livecd-tools appears to work correctly.


Chris Murphy

[Adam Williamson]

Post by Chris Murphy
Following applies to a 2008, Macbook Pro 4,1
1.
Used livecd-tools-17.6-1.fc17 to successfully create an EFI bootable USB stick of Fedora-17-Alpha-x86_64-Live-Desktop.iso.
2.
Due to this bug: EFI boot fails on Macs with NVIDIA GeForce 8600M GT
https://bugzilla.redhat.com/show_bug.cgi?id=751147
I add 'nomodeset' kernel parameter. I know of no work around to get a GUI on this hardware. But it does boot kernel and most services.
3.
tty1 hangs at "Started Display Manager"
tty2 is functional, not sure how to get any information on what's up with tty1. Normally what I'm used to with EFI boot and nomodeset is X can't actually startup, but the rest of the services load, and I end up at a prompt.
4.
Out of 5 boot attempts, I get to a usable tty2 console and can reboot thrice.
Twice, I get a hang right after GRUB loads either the kernel or initrd, the GRUB splash screen is present with no text. The machine has hung and I have to hold the power button to shut down.
So on this hardware I'd say GRUB is marginally reliable.

I suppose it might be interesting to see if grub2-efi works any
better...

Post by Chris Murphy
5.
At reboot/poweroff time, there's a LOT of extra "garbage" information being produced on-screen compared to F16. It goes by quick enough and isn't logged, so I'm not sure if it's important. But I do get a reboot, albeit with about a 1 minute delay over F16.

I suspect 'yum install plymouth' may help with that.

In F16, dracut required plymouth, and dracut is in @core, so plymouth
got pulled into any install. In F17, dracut doesn't require plymouth any
more, and this is desired. So for Alpha I stuck plymouth into comps, but
I only put it into @base, not @core. Minimal installations don't install
@base, they install @core. If you do a text mode installation, you get a
minimal install, hence no plymouth.

I'm not entirely sure what we want to do about this for Beta - whether
we want to put plymouth in @core, or what.

[Chris Murphy]

Post by Adam Williamson
I suppose it might be interesting to see if grub2-efi works any
better...

It's been a year since I've tested it so it needs to be retested. But I do know that doesn't fix bug 765954, so the machine is, for me, functionally useless as a laptop with just a text console.

Post by Adam Williamson

Post by Chris Murphy
5.
At reboot/poweroff time, there's a LOT of extra "garbage" information being produced on-screen compared to F16. It goes by quick enough and isn't logged, so I'm not sure if it's important. But I do get a reboot, albeit with about a 1 minute delay over F16.

I suspect 'yum install plymouth' may help with that.

With rhgb and quiet disabled on F16 and F17, so plymouth is a non-factor. I just get a lot (like probably 10+ screenfulls) of repetitive text that scrolls by very quickly with F17. This comes after the unmounting of filesystems sequence, where as on F16 the computer shuts down. This only happens on actual hardware, in VM, I'm not seeing much of a difference.

Chris Murphy

[Adam Williamson]

Post by Chris Murphy

Post by Adam Williamson
I suppose it might be interesting to see if grub2-efi works any
better...

It's been a year since I've tested it so it needs to be retested. But I do know that doesn't fix bug 765954, so the machine is, for me, functionally useless as a laptop with just a text console.

Post by Adam Williamson

Post by Chris Murphy
5.
At reboot/poweroff time, there's a LOT of extra "garbage" information being produced on-screen compared to F16. It goes by quick enough and isn't logged, so I'm not sure if it's important. But I do get a reboot, albeit with about a 1 minute delay over F16.

I suspect 'yum install plymouth' may help with that.

With rhgb and quiet disabled on F16 and F17, so plymouth is a non-factor.

that doesn't actually disable plymouth, it's still involved.

[Chris Murphy]

Post by Adam Williamson

Post by Chris Murphy

Post by Adam Williamson
I suppose it might be interesting to see if grub2-efi works any
better...

It's been a year since I've tested it so it needs to be retested. But I do know that doesn't fix bug 765954, so the machine is, for me, functionally useless as a laptop with just a text console.

Post by Adam Williamson

Post by Chris Murphy
5.
At reboot/poweroff time, there's a LOT of extra "garbage" information being produced on-screen compared to F16. It goes by quick enough and isn't logged, so I'm not sure if it's important. But I do get a reboot, albeit with about a 1 minute delay over F16.

I suspect 'yum install plymouth' may help with that.

With rhgb and quiet disabled on F16 and F17, so plymouth is a non-factor.

that doesn't actually disable plymouth, it's still involved.

ok i don't get the fedora logo splash at shutdown in any event.

Chris

[Adam Williamson]

Post by Chris Murphy

Post by Adam Williamson

Post by Chris Murphy

Post by Adam Williamson
I suppose it might be interesting to see if grub2-efi works any
better...

It's been a year since I've tested it so it needs to be retested. But I do know that doesn't fix bug 765954, so the machine is, for me, functionally useless as a laptop with just a text console.

Post by Adam Williamson

Post by Chris Murphy
5.
At reboot/poweroff time, there's a LOT of extra "garbage" information being produced on-screen compared to F16. It goes by quick enough and isn't logged, so I'm not sure if it's important. But I do get a reboot, albeit with about a 1 minute delay over F16.

I suspect 'yum install plymouth' may help with that.

With rhgb and quiet disabled on F16 and F17, so plymouth is a non-factor.

that doesn't actually disable plymouth, it's still involved.

ok i don't get the fedora logo splash at shutdown in any event.

yup, but IIRC ray's told me that plymouth is actually still involved in
rendering the 'text' output you get if you take out rhgb from the
parameters. I think there is a parameter you can pass to entirely
disable plymouth, but I forget what it is.

[Michal Schmidt]

Post by Adam Williamson
I think there is a parameter you can pass to entirely
disable plymouth, but I forget what it is.

rd.plymouth=0 plymouth.enable=0

The first is for dracut. The second disables starting of plymouth from
the systemd units.

Michal

[Chris Murphy]

Post by Matthew Garrett
Yes. I'm mostly working on the netinst isos, and right now if you take
that and dd it onto a USB stick, then insert that and hold down alt on
boot, you'll get a Mac install.

OK so color me extremely confused. Starting with a zero'd USB stick (no APM, GPT or MBR), dd'ing the netinst.iso to the stick, I end up with a stick that all tools claims has a GPT, but is a broken GPT (see previous emails on this).

When I burn it to a DVD, diskutil and gdisk claim the partition scheme is APM! It's not GPT at all as far as they are concerned. I don't know how this is possible...but I've reproduced the results twice.


DVD version behaviors, on a 2008 Macbook Pro:

1.) Upon boot with option key, to get the Apple-EFI boot screen, there are four new options. Windows, EFI Boot, EFI Boot, EFI Boot.

a.) When I choose the CD/DVD icon labeled Windows, I get syslinux, and then a menu from which I can start Fedora. It produces a text anaconda installer which appears to function, although I did not proceed with an installation.

b.) When I choose the CD/DVD icon labeled EFI Boot, I'm dropped to a GRUB prompt.

c.) When I choose the Fedora icon labeled EFI Boot, I'm dropped to a GRUB prompt.

d.) When I choose the last CD/DVD icon labeled EFI Boot, a Mac OS login window appears and the computer appears to be booting from the hard drive, not the DVD at all.


On a 2011 Macbook Pro, there are only three new boot options when the DVD is present with behaviors 1a, 1b, and 1c. (Icon 1d is not presented.)

In any case, only the "Windows" option, which results in a CSM-BIOS mode boot, produces a booted system from which Fedora can be installed.

Chris Murphy

[Chris Murphy]

Post by Matthew Garrett
Yes. I'm mostly working on the netinst isos, and right now if you take
that and dd it onto a USB stick, then insert that and hold down alt on
boot, you'll get a Mac install. Unfortunately, alpha ended up getting
built with a grub that dies on any Macs that don't have built-in
ethernet, so you may have some problems with that. The alpha kernel also
has a bug that seems to trigger on Macs that results in incredible
slowness. But other than that! Fixed kernel is in the archive now, and
I've just commited a fix for the grub bug.

Fedora-17-Beta-TC1-x86_64-netinst.iso. I'm getting the same problems as with alpha ISO.


Burned to DVD
------------------
Macbook Pro 4,1 (2008)
Four additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot, EFI Boot
*2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon.

Windows=Boots CSM/BIOS mode successfully
EFI Boot= Grub prompt, no menu
*EFI Boot= Grub prompt, no menu
EFI Boot= Boots Mac OS X


Macbook Pro 8,2 (2011)
Three additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot
*2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon.

Windows=Boots CSM/BIOS mode successfully
EFI Boot= Grub prompt, no menu
*EFI Boot= Grub prompt, no menu



dd to USB stick
------------------
Macbook Pro 4,1 (2008)
Three additional USB icon options labeled as: EFI Boot, EFI Boot, EFI Boot
*2nd icon is a custom Fedora logo icon, not generic USB icon.

EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine
*EFI Boot= Grub prompt, no menu
EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine


Macbook Pro 8,2 (2011)
Three additional CD/DVD icon options labeled as: EFI Boot, EFI Boot, EFI Boot
*2nd icon is a custom Fedora logo icon, not generic USB icon.

EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force shutdown.
*EFI Boot= Grub prompt, no menu
EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force shutdown.


Further, upon completion of CSM-BIOS installation, Fedora isn't bootable by default because a hybrid MBR hasn't been created, requiring manual post install work to make it bootable. Same situation as F16.
https://bugzilla.redhat.com/show_bug.cgi?id=746901


Chris Murphy

[Andreas Tunek]

Thanks for all your testing! It certainly seems like Fedora has quite a way
to go before it is possible to install on "clean" macs.....

Have you done any testing using refit, or is this all with vanilla apple
efi?

Post by Chris Murphy

Post by Matthew Garrett
Yes. I'm mostly working on the netinst isos, and right now if you take
that and dd it onto a USB stick, then insert that and hold down alt on
boot, you'll get a Mac install. Unfortunately, alpha ended up getting
built with a grub that dies on any Macs that don't have built-in
ethernet, so you may have some problems with that. The alpha kernel also
has a bug that seems to trigger on Macs that results in incredible
slowness. But other than that! Fixed kernel is in the archive now, and
I've just commited a fix for the grub bug.

Fedora-17-Beta-TC1-x86_64-netinst.iso. I'm getting the same problems as with alpha ISO.
Burned to DVD
------------------
Macbook Pro 4,1 (2008)
Four additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot, EFI Boot
*2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon.
Windows=Boots CSM/BIOS mode successfully
EFI Boot= Grub prompt, no menu
*EFI Boot= Grub prompt, no menu
EFI Boot= Boots Mac OS X
Macbook Pro 8,2 (2011)
Three additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot
*2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon.
Windows=Boots CSM/BIOS mode successfully
EFI Boot= Grub prompt, no menu
*EFI Boot= Grub prompt, no menu
dd to USB stick
------------------
Macbook Pro 4,1 (2008)
Three additional USB icon options labeled as: EFI Boot, EFI Boot, EFI Boot
*2nd icon is a custom Fedora logo icon, not generic USB icon.
EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine
*EFI Boot= Grub prompt, no menu
EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine
Macbook Pro 8,2 (2011)
Three additional CD/DVD icon options labeled as: EFI Boot, EFI Boot, EFI Boot
*2nd icon is a custom Fedora logo icon, not generic USB icon.
EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force shutdown.
*EFI Boot= Grub prompt, no menu
EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force shutdown.
Further, upon completion of CSM-BIOS installation, Fedora isn't bootable

by default because a hybrid MBR hasn't been created, requiring manual post
install work to make it bootable. Same situation as F16.

Post by Chris Murphy
https://bugzilla.redhat.com/show_bug.cgi?id=746901
Chris Murphy
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120313/6e5c2af4/attachment.html>

[Matthew Garrett]

Post by Chris Murphy
EFI Boot= Grub prompt, no menu

Can you type "root" and see what it says, followed by "findiso" and then
"root"?

Post by Chris Murphy
EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine

That'll be a kernel bug of some description...

Post by Chris Murphy
EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force shutdown.

This too. Can you try adding "noefi" to the kernel command line for
both?

CSM boots aren't expected to work in the slightest.

[Chris Murphy]

Post by Matthew Garrett

Post by Chris Murphy
EFI Boot= Grub prompt, no menu

Can you type "root" and see what it says, followed by "findiso" and then
"root"?

USB stick:
grub> root
(hd0,2,a): Filesystem type unknown, partition type 0x0
grub> findiso
grub> root
(hd0): Filesystem type is iso9660, using whole disk

DVD:
grub> root
(hd0,2,a): Filesystem type unknown, partition type 0x0
grub> findiso
grub> root
(fd256): Filesystem type is iso9660, using whole disk

Post by Matthew Garrett

Post by Chris Murphy
EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine

That'll be a kernel bug of some description...

Post by Chris Murphy
EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force shutdown.

This too. Can you try adding "noefi" to the kernel command line for
both?

Makes no difference in either case. Same result. This is inserted after 'rd.dm=0'.

Post by Matthew Garrett
CSM boots aren't expected to work in the slightest.

But it does work. All the way to anaconda and installation. It's the EFI options that aren't working so far.


Chris Murphy

[Chris Murphy]

Detail version of previous post's in-line summary results.


Burned to DVD
------------------
Macbook Pro 4,1 (2008)
Four additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot, EFI Boot
*2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon.

1. Windows= Boots fine, all the way to anaconda.

2. EFI Boot= Grub prompt, no menu.
grub> root
(hd0,2,a): Filesystem type unknown, partition type 0x0
grub> findiso
grub> root
(fd256): Filesystem type is iso9660, using whole disk


3. *EFI Boot= Grub prompt, no menu
grub> root
(hd0,2,a): Filesystem type unknown, partition type 0x0
grub> findiso
grub> root
(fd256): Filesystem type is iso9660, using whole disk


4. EFI Boot= Boots Mac OS X.


Macbook Pro 8,2 (2011)
Three additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot
*2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon.

1. Windows=Boots CSM/BIOS mode successfully, to anaconda.

2. EFI Boot= Grub prompt, no menu
grub> root
(hd0,2,a): Filesystem type unknown, partition type 0x0
grub> findiso
grub> root
(fd256): Filesystem type is iso9660, using whole disk


3. *EFI Boot= Grub prompt, no menu
grub> root
(hd0,2,a): Filesystem type unknown, partition type 0x0
grub> findiso
grub> root
(fd256): Filesystem type is iso9660, using whole disk


============

dd to USB stick
------------------
Macbook Pro 4,1 (2008)
Four additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot, EFI Boot
*2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon.

1. EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine.
When inserting noefi as kernel parameter, there is no change in behavior. FYI I'm inserting it right after 'rd.dm=0'.

2. *EFI Boot= Grub prompt, no menu
grub> root
(hd0,2,a): Filesystem type unknown, partition type 0x0
grub> findiso
grub> root
(hd0): Filesystem type is iso9660, using whole disk

3. EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine
When inserting noefi as kernel parameter, there is no change in behavior.


Macbook Pro 8,2 (2011)
Three additional CD/DVD icon options labeled as: EFI Boot, EFI Boot, EFI Boot
*2nd icon is a custom Fedora logo icon, not generic USB icon.

1. EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force shutdown.
With noefi as kernel parameter, no change in behavior.

2. *EFI Boot= Grub prompt, no menu
grub> root
(hd0,2,a): Filesystem type unknown, partition type 0x0
grub> findiso
grub> root
(hd0): Filesystem type is iso9660, using whole disk

3. EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force shutdown.
With noefi as kernel parameter, no change in behavior.

[Matthew Garrett]

Post by Chris Murphy

Post by Matthew Garrett

Post by Chris Murphy
EFI Boot= Grub prompt, no menu

Can you type "root" and see what it says, followed by "findiso" and then
"root"?

grub> root
(hd0,2,a): Filesystem type unknown, partition type 0x0
grub> findiso
grub> root
(hd0): Filesystem type is iso9660, using whole disk
grub> root
(hd0,2,a): Filesystem type unknown, partition type 0x0
grub> findiso
grub> root
(fd256): Filesystem type is iso9660, using whole disk

Interesting. This probably means that grub is failing to find its config
file for some reason, which really isn't something that should go wrong.
I'll look into it.

Post by Chris Murphy

Post by Matthew Garrett
This too. Can you try adding "noefi" to the kernel command line for
both?

Makes no difference in either case. Same result. This is inserted after 'rd.dm=0'.

Ok, so it's nothing to do with our efi accesses. Irritating. I'll
probably need to track down hardware.

Post by Chris Murphy

Post by Matthew Garrett
CSM boots aren't expected to work in the slightest.

But it does work. All the way to anaconda and installation. It's the EFI options that aren't working so far.

You pointed out that CSM installs don't work - the partition table is
entirely inappropriate for them. We're not planning on fixing that.

[Chris Murphy]

Post by Matthew Garrett
You pointed out that CSM installs don't work - the partition table is
entirely inappropriate for them. We're not planning on fixing that.

CSM boot from install media does work. CSM installations don't reboot successfully, without manual creation of a hybrid MBR.

While I understand the reluctance to support hybrid MBR, that is how Apple supports Windows CSM installations. I don't know which is more difficult, squashing the myriad VBIOS bugs with Apple EFI booting, or tolerating hybrid MBRs.

Even with successful livecd-iso-to-disk USB stick boots in EFI, both of my test computers have outstanding video bugs that translate into no GUI. By successful, I mean the kernel, initrd, and services load - except for X and gnome/kde. I can ssh in and interact text only.

https://bugzilla.redhat.com/show_bug.cgi?id=765954
https://bugzilla.redhat.com/show_bug.cgi?id=751147


Chris Murphy

[Matthew Garrett]

Post by Chris Murphy
CSM boot from install media does work. CSM installations don't reboot successfully, without manual creation of a hybrid MBR.

Yes, and support for handling and managing hybrid MBRs is difficult.
Apple can manage it by simply constraining it to a very simple case.
Create more partitions and disk utility stops wanting to be your friend.
Trying to handle hybrid media in the larger number of storage cases we
have to support is a non-starter.

[Chris Murphy]

Post by Matthew Garrett
Yes, and support for handling and managing hybrid MBRs is difficult.
Apple can manage it by simply constraining it to a very simple case.
Create more partitions and disk utility stops wanting to be your friend.
Trying to handle hybrid media in the larger number of storage cases we
have to support is a non-starter.

Perhaps it's unreasonable to try to handle the larger number of storage cases with Apple hardware, at least in the short/medium term. Limiting the possible cases, it's at least possible to have a functioning system, with a GUI, using CSM-BIOS+hybrid MBR.

With a wider set of cases, I have effectively a useless system in all such cases with EFI, as I have no graphics with either test hardware. And one of them I have neither graphics nor text with built-in display, I can only interact via ssh - requiring a 2nd system to do so.


Chris Murphy

[Adam Williamson]

Post by Andreas Tunek
Has there been any more tests getting F17 to boot on macs, with or
without refit? I would love to test, but if macs are not any target
hardware for fedora it would be pretty pointless.

I didn't really manage to make time to get anywhere with formal testing
as part of the QA processes, unfortunately (I was hoping to have a test
case or two and get someone in QA some Mac hardware), but mjg59 is
working on things on the development end and testing with the hardware
he has available, and there has been some discussion and testing going
on particularly in the mactel-boot review request bug:

https://bugzilla.redhat.com/show_bug.cgi?id=755093

Chris Murphy is pretty active testing various things in regards to Mac
booting, and I've been meaning to get in touch and ask if he's taken a
look at F17 Alpha.

[Chris Murphy]

Post by Adam Williamson
Chris Murphy is pretty active testing various things in regards to Mac
booting, and I've been meaning to get in touch and ask if he's taken a
look at F17 Alpha.

I just downloaded the LiveCD, installed it in VM so I can use the latest livecd-tools to make an EFI bootable USB stick for the Mac hardware I have here. Will report back.

Chris Murphy

[Adam Williamson]

Post by Chris Murphy

Post by Adam Williamson
Chris Murphy is pretty active testing various things in regards to Mac
booting, and I've been meaning to get in touch and ask if he's taken a
look at F17 Alpha.

I just downloaded the LiveCD, installed it in VM so I can use the
latest livecd-tools to make an EFI bootable USB stick for the Mac
hardware I have here. Will report back.

Thanks! It's much appreciated.

[Matthew Garrett]

(Note: *DO NOT* run the installer that is on this image. You'll probably
end up with a broken grub. Should be fixed soon)

I've put a test image up at
http://mjg59.fedorapeople.org/Fedora-Mac-EFI-test.iso - this should work
if burned to a CD or dded to a USB stick. Insert, hold down alt, select
the Fedora logo. Possible outcomes:

1) Complete failure. I've fixed all the cases I know of that could cause
this, but there may still be possibilities. Please file a bug.
2) Boots, but graphics don't work. Please try with nomodeset as a kernel
option, then file a bug.
3) Success. Hurrah! Do nothing more.

[Matthew Garrett]

Ok, once hitch with this. Due to an error on my part it's possible that
the Fedora logo option may not work. In that case, plesae try one of the
other "EFI Boot" options.

[Chris Murphy]

Post by Matthew Garrett
(Note: *DO NOT* run the installer that is on this image. You'll probably
end up with a broken grub. Should be fixed soon)
I've put a test image up at
http://mjg59.fedorapeople.org/Fedora-Mac-EFI-test.iso - this should work
if burned to a CD or dded to a USB stick. Insert, hold down alt, select
1) Complete failure. I've fixed all the cases I know of that could cause
this, but there may still be possibilities. Please file a bug.
2) Boots, but graphics don't work. Please try with nomodeset as a kernel
option, then file a bug.
3) Success. Hurrah! Do nothing more.

2008 MacBook Pro 4,1 results:
----------------------------------------

DVD: Three EFI Boot options, one has a Fedora logo. All drop me to a GRUB 0.97 prompt.

USB stick: Initramfs unpacking failed: broken padding. Kernel panic - not syncing: No init found.

Each reproducible 3x.
======


2011 MacBook Pro 8,2 results:
------------------------------------------

DVD: Two EFI Boot options, one has a Fedora logo. Both drop me to a GRUB 0.97 prompt.

USB stick: Video problem as described in Bug 765954, however it only goes half way down and there's no further USB activity. Switching to console and issuing reboot commands doesn't work (like it does with a livecd-iso-to-disk produced stick), so I'm thinking probably a kernel panic here too but I can't tell why.
https://bugzilla.redhat.com/show_bug.cgi?id=765954


Also each reproducible 3x.
========

How many bug reports do you want? One for all, one for each model, one for each result? And against what components?


Chris Murphy

[Matthew Garrett]

Ok, I'll have to look at the CD issue. Can you report the initramfs
problem?

[Chris Murphy]

Post by Matthew Garrett
Ok, I'll have to look at the CD issue. Can you report the initramfs
problem?

Yes. What component?


Chris Murphy

[Matthew Garrett]

Post by Chris Murphy

Post by Matthew Garrett
Ok, I'll have to look at the CD issue. Can you report the initramfs
problem?

Yes. What component?

Put it against the kernel for now, and we'll see if we can figure out
what's going on.

[Chris Murphy]

Post by Matthew Garrett

Post by Chris Murphy

Post by Matthew Garrett
Ok, I'll have to look at the CD issue. Can you report the initramfs
problem?

Yes. What component?

Put it against the kernel for now, and we'll see if we can figure out
what's going on.

https://bugzilla.redhat.com/show_bug.cgi?id=816040

[Matthew Garrett]

Post by Matthew Garrett
Ok, I'll have to look at the CD issue. Can you report the initramfs
problem?

Figured out the CD problem, I'll push a fix to git. Looking at the
initramfs problem now.

[John Reiser]

Post by Matthew Garrett
http://mjg59.fedorapeople.org/Fedora-Mac-EFI-test.iso

On Apple Macmini1,1 Intel Core Duo [i686 only] booted with DVD in builtin
drive and Alt held down: I get one EFI Boot with Fedora logo, and one
Windows with platter logo (and two harddrive logos, corresponding to
pre-existing resident OS).

Choosing EFI Boot diplays a large folder icon with a question mark, which
blinks a couple times; then the regular Apple large logo and normal Apple boot.
So FAIL for Fedora EFI boot.

Choosing the Windows logo gets a VGA-like display (black with white
character-cell text):
1.
2.
3.
Select CD-ROM Boot Type :
and there is no response to console keyboard. So FAIL again.

Booting with C key held down [no Shift; should force "default" CD/DVD choice]
gives the same as choosing Windows logo from booting with Alt held down.
FAIL the third time.

Which component should I file for bugzilla?

--

[Matthew Garrett]

Post by John Reiser
Booting with C key held down [no Shift; should force "default" CD/DVD choice]
gives the same as choosing Windows logo from booting with Alt held down.
FAIL the third time.
Which component should I file for bugzilla?

Ah, sorry, I should have specified - this will only work on machines
with 64-bit firmware, which is basically any machine released after
mid-2007. My fault.

[Peter Jones]

Post by John Reiser
Choosing the Windows logo gets a VGA-like display (black with white
1.
2.
3.
and there is no response to console keyboard. So FAIL again.

Even though this disc is wrong for that machine, so the test isn't really valid,
it's worth mentioning that *any* time you see this screen, it's a bug in the
CSM - the BIOS emulation layer on top of UEFI is completely failing to comply
with the El Torito standard for CD booting when it sees multiple boot sections
on a CD. Rather than implementing correct support to select which boot
section to use, this version of the CSM, which is shared among Apple machines
and other vendors' alike, presents all of the choices as a menu instead.

Awesomely the keyboard driver not being present is a /second/ firmware bug. On
some machines it is present, and on those selecting "1" will work and continue
booting as if on a BIOS machine.

Apple have fixed this on newer hardware, but I don't think they've ever pushed
a fix back to this generation.

[Bastien Nocera]

Post by Matthew Garrett
(Note: *DO NOT* run the installer that is on this image. You'll probably
end up with a broken grub. Should be fixed soon)
I've put a test image up at
http://mjg59.fedorapeople.org/Fedora-Mac-EFI-test.iso - this should work
if burned to a CD or dded to a USB stick. Insert, hold down alt, select

I cannot see the Fedora logo at all. I see 2 additional "EFI Boot"
options (I would usually only see "rEFIt" and "Windows", as the firmware
calls my Linux booting through MBR), and both of them take me to a grub
prompt that asks me for a kernel to be loaded.

MacBookAir4,1 (2011 11" one)

Did you have a newer version to test?

Post by Matthew Garrett
1) Complete failure. I've fixed all the cases I know of that could cause
this, but there may still be possibilities. Please file a bug.
2) Boots, but graphics don't work. Please try with nomodeset as a kernel
option, then file a bug.
3) Success. Hurrah! Do nothing more.

Cheers

[Andreas Tunek]

I get an md5 error when I try to make a live usb with fedora's
live-usb creator. Anyone else seen this?

[Adam Williamson]

Post by Bastien Nocera

Post by Matthew Garrett
(Note: *DO NOT* run the installer that is on this image. You'll probably
end up with a broken grub. Should be fixed soon)
I've put a test image up at
http://mjg59.fedorapeople.org/Fedora-Mac-EFI-test.iso - this should work
if burned to a CD or dded to a USB stick. Insert, hold down alt, select

I cannot see the Fedora logo at all. I see 2 additional "EFI Boot"
options (I would usually only see "rEFIt" and "Windows", as the firmware
calls my Linux booting through MBR), and both of them take me to a grub
prompt that asks me for a kernel to be loaded.
MacBookAir4,1 (2011 11" one)
Did you have a newer version to test?

TC1 is the current state of the art:

http://dl.fedoraproject.org/pub/alt/stage/17.TC1/

with TC1, we think, the live images written to USB with l-i-t-d (use the
very latest livecd-tools you can find) or dd should boot on at least
most Mactels. The DVD / netinst image written to USB apparently doesn't
work (though the new livecd-tools might change that).

There will be a TC2 shortly incorporating a new anaconda and built with
a new livecd-tools; TC2 written with the very latest livecd-tools
(updates are submitted for 16 and 17) should be the best we can do, and
a significant improvement for EFI / Mac booting, lots of bugs have been
squished. Additionally, it makes dd of the DVD ISO to USB 'just work' -
it will pick up the packages on the USB stick without any manual kernel
parameter addition being needed. Which is cool.

So, long story short - we'll be very interested in reports of
success/failure with TC2 (which should show up tonight or tomorrow)
written with dd or the very latest livecd-tools builds for F16/F17:
livecd-tools-16.14-1.fc16 and livecd-tools-17.10-1.fc17 .

[Chris Murphy]

Post by Adam Williamson
So, long story short - we'll be very interested in reports of
success/failure with TC2 (which should show up tonight or tomorrow)

DVD ISO burned to DVD-RW media: Boots EFI mode, with nouveau, with X, just fine off media as the LiveCD cases I mention below. However, at the end of the installation I get an error "There was an error installing the bootloader. The system may not be bootable." System is in fact not bootable. Filed a bug with anaconda logs:

https://bugzilla.redhat.com/show_bug.cgi?id=817225


========

LiveCD. Holy crap the whole thing works. EFI boot and install. Works. Macbook Pro 4,1 (2008).
LiveCD ISO burned to DVD-RW media = boots, installs, reboots.
LiveCD ISO dd'd to USB stick = boots, installs, reboots.


Question 1:
Is this bug fixed?! Nouveau is working for the first time ever with EFI booting on this hardware.
https://bugzilla.redhat.com/show_bug.cgi?id=751147


Question 2:
Most Mac users will boot CD/DVD media with a 'c' key. Should it be documented somewhere to boot with the option key at the startup chime? Previously, 'c' key would get me a working CSM boot, but that is no longer the case with at least DVD TC2, I get a flashing white cursor (I understand this is not expected to work, hence wondering if it's worth mentioning somewhere.)

----------


Next testing MBP8,2. And then dual boot once 10.7.x is done installing on the MBP4,1.

[Chris Murphy]

Post by Chris Murphy
https://bugzilla.redhat.com/show_bug.cgi?id=817225

Could be false alarm due to me unchecking packages in Customize Now, to save time. Not reproducible with DVD Graphical Desktop default. Bootloader error is reproducible if I do it again unchecking a bunch of things. So my confusion is probably that I don't expect anaconda to let me customize packages that result in a broken installation. Updated bug including what options I unchecked.

--------

Problem: Flakey reboot and poweroffs. CSM boot and installs were lightening fast with previous FC17 builds. EFI boot reboots, after executing command, result in a 1-2 minute hang. I can switch consoles, but they are unresponsive and provide no information. Presently on the MBP4,1 it's been hanging for 8 minutes so I'm going to force it off with the power button. File a bug? I don't know what to add or include.

--------

MacbookPro8,2: Major improvement in that I no longer have a garbled display. However either with or without 'nomodeset' it only boots so far and then dies: no further activity from USB stick, can't blindly get to a console and reboot or dmesg out to another stick; if I attach another USB device, no activity from it or the boot USB stick. So I'm not sure what's going on.

I have photos of the screen, but it's not very illuminating, lemme know if they should go in this bug, or start a new one.

https://bugzilla.redhat.com/show_bug.cgi?id=765954

[Chris Murphy]

Dual boot Mac OS 10.7 + F17, MBP4,1.

Failure after partitioning/lvm/filesystem creation, and before copying live image beings. Error message:

"ext4 filesystem check failure on /dev/mapper/vg_f17s-lv_root:
File system errors left uncorrected.
<remainder snipped> "

This is a 1 fail for 1 attempt, with this configuration. I've posted logs and steps in this bug, and will try and reproduce it again myself after I get some sleep:

https://bugzilla.redhat.com/show_bug.cgi?id=817262

[Matthew Garrett]

Post by Chris Murphy
Problem: Flakey reboot and poweroffs. CSM boot and installs were
lightening fast with previous FC17 builds. EFI boot reboots, after
executing command, result in a 1-2 minute hang. I can switch consoles,
but they are unresponsive and provide no information. Presently on the
MBP4,1 it's been hanging for 8 minutes so I'm going to force it off
with the power button. File a bug? I don't know what to add or
include.

I /think/ this is a generic problem somewhere in userspace - I've seen
the same on other machines. I'll try to track it down this week if
nobody else is.

Post by Chris Murphy
MacbookPro8,2: Major improvement in that I no longer have a garbled
display. However either with or without 'nomodeset' it only boots so
far and then dies: no further activity from USB stick, can't blindly
get to a console and reboot or dmesg out to another stick; if I attach
another USB device, no activity from it or the boot USB stick. So I'm
not sure what's going on.

This is a Radeon? We're doing something wrong in the DisplayPort setup,
and I'm trying to hunt it down - it seems to affect most modern Macs
with Radeons.

[Chris Murphy]

Post by Matthew Garrett
This is a Radeon? We're doing something wrong in the DisplayPort setup,
and I'm trying to hunt it down - it seems to affect most modern Macs
with Radeons.

Yes, both Radeon and Intel Graphics are on that mDP port.

Post by Matthew Garrett
https://bugzilla.redhat.com/show_bug.cgi?id=817262

I'm 5 for 5 attempts with the LiveCD. Installation along side Mac OS is presently a fail. And I'm not finding a work around, other than possibly installing Mac OS X after Fedora might work. But alongside an existing is not.

I can go to a console while booted from the LiveCD, and use 'mke2fs -t ext4' on the same lv_home, and right after that e2fsck is completely clean. But through the installer, the resulting file system is somehow trashed every time. Yet this wasn't happening with "Use All Space" option.


Chris Murphy

[Chris Murphy]

File system errors left uncorrected, failure to install along side Mac OS, Mactel boot
https://bugzilla.redhat.com/show_bug.cgi?id=817262

This problem is not occurring when using the LiveCD ISO burned to DVD-RW media. It's only occurring with a USB stick produced by dd'ing the LiveCD ISO. The GRUB option to Verify and Boot does not fail the USB stick.

New problem is that the successfully installed system (from LiveCD ISO burned to DVD-RW media), upon reboot, does not eject the disc, rather it boots from it not the HDD. When I reboot with option key at the startup chime, I'm presented with six icons, none of which are Fedora. If I boot Mac OS and go to System Preferences > Startup Disk, I have only a Mac OS option.

So Fedora was installed successfully, but can't be chosen as a boot option.


Chris Murphy


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120428/dba29ec0/attachment.html>

[Chris Murphy]

File system errors left uncorrected, failure to install along side Mac OS, Mactel boot
https://bugzilla.redhat.com/show_bug.cgi?id=817262

I have updated this bug. Does not occur with burned media. Only a dd'd USB stick, which fails verification but the user is not informed of the failure. I've recreated the USB stick twice, and both times if fails verification.

Interesting that "Use All Space" produces a bootable system. But "Replace Existing" and "Use Free Space" fail.

In any case, even with burned media and successful installation, the resulting F17 system is not choosable for booting. So dual boot installation is in effect a fail in all cases, I haven't figured out a work around.

==========

Triple boot: Mac OS + Windows + Fedora is another matter, as Windows is rendered unbootable.

Because parted obliterates an existing hybrid MBR no matter what installation type is chosen, and the hybrid MBR is required for Windows to boot, any attempt to install F17 along side existing Mac OS + Windows will render Windows unbootable. The manual post install fix is to use gdisk to create a new hybrid MBR.

The question is how to position this in Release Notes or Installation Guide documentation. I think there should be a warning that Windows will be rendered unbootable, in any case:

1. Warn.
2. Warn and explain cause (hybrid MBR is removed).
3. Warn, explain, and suggest work around (gdisk).

I suggest option 1 or 2.


Chris Murphy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120428/5de663ee/attachment.html>

[Matthew Garrett]

Post by Chris Murphy
New problem is that the successfully installed system (from LiveCD ISO
burned to DVD-RW media), upon reboot, does not eject the disc, rather
it boots from it not the HDD. When I reboot with option key at the
startup chime, I'm presented with six icons, none of which are Fedora.
If I boot Mac OS and go to System Preferences > Startup Disk, I have
only a Mac OS option.

#816288

[Chris Murphy]

Post by Matthew Garrett

Post by Chris Murphy
New problem is that the successfully installed system (from LiveCD ISO
burned to DVD-RW media), upon reboot, does not eject the disc, rather
it boots from it not the HDD. When I reboot with option key at the
startup chime, I'm presented with six icons, none of which are Fedora.
If I boot Mac OS and go to System Preferences > Startup Disk, I have
only a Mac OS option.

#816288

I get the same result from DVD ISO burned to actual media. Not just Live-Desktop.


Chris Murphy

[Chris Murphy]

Post by Matthew Garrett

Post by Chris Murphy
New problem is that the successfully installed system (from LiveCD ISO
burned to DVD-RW media), upon reboot, does not eject the disc, rather
it boots from it not the HDD. When I reboot with option key at the
startup chime, I'm presented with six icons, none of which are Fedora.
If I boot Mac OS and go to System Preferences > Startup Disk, I have
only a Mac OS option.

#816288

ETA?

I get the same results whether the installation is based on Live Desktop or DVD based installs.


Chris Murphy

[Chris Murphy]

Is this a bug? If so I'll file it.

When performing Replace Existing installation types, the 200MB HFS+ partition used for /boot/efi is not replaced. Instead, a new one is created each time.

So if I perform five (5) Replace Existing installation types after the first Fedora install, I end up with six (6) of these 200MB HFS+ partitions.


Chris Murphy

[Adam Williamson]

Post by Chris Murphy
Is this a bug? If so I'll file it.
When performing Replace Existing installation types, the 200MB HFS+ partition used for /boot/efi is not replaced. Instead, a new one is created each time.
So if I perform five (5) Replace Existing installation types after the first Fedora install, I end up with six (6) of these 200MB HFS+ partitions.

I'd say almost certainly yes. AIUI on any EFI system there's only ever a
reason to have _one_ EFI system partition.

[Chris Murphy]

Post by Adam Williamson
I'd say almost certainly yes. AIUI on any EFI system there's only ever a
reason to have _one_ EFI system partition.

mactel-boot in effect creates an HFS+ /boot/efi partition, and does not use the existing FAT32 EFI System partition. So there are already two for Macs. But I'll take it to mean that anaconda should be able to identify and reuse a pre-existing HFS+ /boot/efi instead of creating another one.

Chris Murphy

[John Reiser]

Post by Chris Murphy

Post by Adam Williamson
I'd say almost certainly yes. AIUI on any EFI system there's only ever a
reason to have _one_ EFI system partition.

mactel-boot in effect creates an HFS+ /boot/efi partition, and does not use the existing
FAT32 EFI System partition. So there are already two for Macs. But I'll take it to mean
that anaconda should be able to identify and reuse a pre-existing HFS+ /boot/efi
instead of creating another one.

Anaconda claims that the natural sharing of EFI System Partition
across multiple OS is not supported, neither for Install nor for Update:

"EFI install from DVD forgets previous EFI boot"
https://bugzilla.redhat.com/show_bug.cgi?id=809963#c7
"As far as sharing the same /boot/efi directory between installs, we don't
support that -- a new copy of the grub.efi binary is written as well as a new
grub.conf."

--

[John Reiser]

Post by John Reiser
"EFI install from DVD forgets previous EFI boot"
https://bugzilla.redhat.com/show_bug.cgi?id=809963#c7
"As far as sharing the same /boot/efi directory between installs, we don't
support that -- a new copy of the grub.efi binary is written as well as a new
grub.conf."

In a related case, anaconda states again that shared, merged grub.conf for EFI
booting is not supported:

"upgrade using boot.iso destroys EFI boot"
https://bugzilla.redhat.com/show_bug.cgi?id=816238

--

[Chris Murphy]

Post by John Reiser

Post by Chris Murphy

Post by Adam Williamson
I'd say almost certainly yes. AIUI on any EFI system there's only ever a
reason to have _one_ EFI system partition.

mactel-boot in effect creates an HFS+ /boot/efi partition, and does not use the existing
FAT32 EFI System partition. So there are already two for Macs. But I'll take it to mean
that anaconda should be able to identify and reuse a pre-existing HFS+ /boot/efi
instead of creating another one.

Anaconda claims that the natural sharing of EFI System Partition
"EFI install from DVD forgets previous EFI boot"
https://bugzilla.redhat.com/show_bug.cgi?id=809963#c7
"As far as sharing the same /boot/efi directory between installs, we don't
support that -- a new copy of the grub.efi binary is written as well as a new
grub.conf."

Unrelated. It created this HFS+ /boot/efi during the first install. And for subsequent installs, it doesn't replace, delete, or reuse it. If I do a Replace Existing 10 times, I end up with 11 of these 200MB HFS+ partitions.


Chris Murphy

[Chris Murphy]

TC5 Live Desktop burned to actual media is not EFI bootable on MBP41. The only option for the media is "Windows". I'm not sure if this regression occurred in TC4 or TC5.


Chris Murphy

[Nikos Roussos]

Some feedback from a succefull installation of F17 TC4 on a Macbook Air 13"
(Model number A1369). Unfortunately the TC5 didn't boot. For TC4 we had to
change label grub option to LIVE in order to boot. Is this a typo?

Anaconda worked just fine and installation was completed succefully. Only
thing didn't work as expected is that grub overwrited OsX bootloader but
didn't create an OsX menu entry. We manually had to add a chainloader menu
entry for /usr/share/standalone/i386/boot.efi

Other than that everything seems to work great.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120514/9d32a8ee/attachment.html>

[Adam Williamson]

Post by Chris Murphy
TC5 Live Desktop burned to actual media is not EFI bootable on MBP41.
The only option for the media is "Windows". I'm not sure if this
regression occurred in TC4 or TC5.

As noted in https://bugzilla.redhat.com/show_bug.cgi?id=810104 , this
turns out to be because a stale livecd-tools build was in the 'bleed'
repo used for sideloading builds into TC/RC composes, so we built TC4
and TC5 with that old livecd-tools instead of the newest one. This
should be resolved for TC6/RC1.