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
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
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
On Dec 25, 2011, at 3:22 PM, Chris Murphy lists@colorremedies.com wrote:
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
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Dec 26, 2011, at 5:55 PM, Todd V Orvieto wrote:
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.
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.
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
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 On Dec 27, 2011 4:09 AM, "Chris Murphy" lists@colorremedies.com wrote:
On Dec 26, 2011, at 5:55 PM, Todd V Orvieto wrote:
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.
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.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Feb 28, 2012 at 05:57:38PM +0100, Andreas Tunek wrote:
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.
On Tue, Feb 28, 2012 at 05:22:22PM +0000, Matthew Garrett wrote:
On Tue, Feb 28, 2012 at 05:57:38PM +0100, Andreas Tunek wrote:
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,
Den 28 februari 2012 18:22 skrev Matthew Garrett mjg59@srcf.ucam.org:
On Tue, Feb 28, 2012 at 05:57:38PM +0100, Andreas Tunek wrote:
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
-- Matthew Garrett | mjg59@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Feb 28, 2012 at 08:34:22PM +0100, Andreas Tunek wrote:
Den 28 februari 2012 18:22 skrev Matthew Garrett mjg59@srcf.ucam.org:
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.
On Tue, 2012-02-28 at 19:53 +0000, Matthew Garrett wrote:
On Tue, Feb 28, 2012 at 08:34:22PM +0100, Andreas Tunek wrote:
Den 28 februari 2012 18:22 skrev Matthew Garrett mjg59@srcf.ucam.org:
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.)
On Feb 28, 2012, at 12:53 PM, Matthew Garrett wrote:
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/Fed...
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.
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/Fed...
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
Starting with a USB stick produced with the following: http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fed...
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
On Feb 28, 2012, at 2:37 PM, Chris Murphy wrote:
Starting with a USB stick produced with the following: http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fed...
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
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
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
On Tue, 2012-02-28 at 16:36 -0700, Chris Murphy wrote:
Following applies to a 2008, Macbook Pro 4,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.
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.
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.
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...
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.
On Feb 28, 2012, at 11:21 PM, Adam Williamson wrote:
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.
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
On Tue, 2012-02-28 at 23:30 -0700, Chris Murphy wrote:
On Feb 28, 2012, at 11:21 PM, Adam Williamson wrote:
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.
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.
On Feb 29, 2012, at 12:09 AM, Adam Williamson wrote:
On Tue, 2012-02-28 at 23:30 -0700, Chris Murphy wrote:
On Feb 28, 2012, at 11:21 PM, Adam Williamson wrote:
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.
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
On Wed, 2012-02-29 at 00:22 -0700, Chris Murphy wrote:
On Feb 29, 2012, at 12:09 AM, Adam Williamson wrote:
On Tue, 2012-02-28 at 23:30 -0700, Chris Murphy wrote:
On Feb 28, 2012, at 11:21 PM, Adam Williamson wrote:
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.
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.
Dne 29.2.2012 08:36, Adam Williamson napsal(a):
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
On Feb 28, 2012, at 12:53 PM, Matthew Garrett wrote:
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
On Feb 28, 2012, at 12:53 PM, Matthew Garrett wrote:
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
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? On Mar 13, 2012 10:06 AM, "Chris Murphy" lists@colorremedies.com wrote:
On Feb 28, 2012, at 12:53 PM, Matthew Garrett wrote:
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
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Mar 13, 2012 at 03:06:31AM -0600, Chris Murphy wrote:
EFI Boot= Grub prompt, no menu
Can you type "root" and see what it says, followed by "findiso" and then "root"?
EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine
That'll be a kernel bug of some description...
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.
On Mar 13, 2012, at 7:10 AM, Matthew Garrett wrote:
On Tue, Mar 13, 2012 at 03:06:31AM -0600, Chris Murphy wrote:
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
EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine
That'll be a kernel bug of some description...
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'.
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
On Tue, Mar 13, 2012 at 02:02:50PM -0600, Chris Murphy wrote:
On Mar 13, 2012, at 7:10 AM, Matthew Garrett wrote:
On Tue, Mar 13, 2012 at 03:06:31AM -0600, Chris Murphy wrote:
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
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.
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.
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.
On Mar 13, 2012, at 2:07 PM, Matthew Garrett wrote:
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
On Tue, Mar 13, 2012 at 02:26:03PM -0600, Chris Murphy wrote:
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.
On Mar 13, 2012, at 3:37 PM, Matthew Garrett wrote:
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
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.
On Tue, 2012-02-28 at 17:57 +0100, Andreas Tunek wrote:
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.
On Feb 28, 2012, at 12:15 PM, Adam Williamson wrote:
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
On Tue, 2012-02-28 at 12:23 -0700, Chris Murphy wrote:
On Feb 28, 2012, at 12:15 PM, Adam Williamson wrote:
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.
(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.
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.
On Apr 24, 2012, at 3:31 PM, Matthew Garrett wrote:
(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:
- 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
Ok, I'll have to look at the CD issue. Can you report the initramfs problem?
On Tue, Apr 24, 2012 at 07:08:39PM -0600, Chris Murphy wrote:
On Apr 24, 2012, at 6:39 PM, Matthew Garrett wrote:
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.
On Apr 24, 2012, at 7:39 PM, Matthew Garrett wrote:
On Tue, Apr 24, 2012 at 07:08:39PM -0600, Chris Murphy wrote:
On Apr 24, 2012, at 6:39 PM, Matthew Garrett wrote:
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.
On Wed, Apr 25, 2012 at 01:39:20AM +0100, Matthew Garrett wrote:
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.
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?
--
On Tue, Apr 24, 2012 at 07:20:00PM -0700, John Reiser wrote:
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.
On 04/24/2012 10:20 PM, John Reiser wrote:
Choosing the Windows logo gets a VGA-like display (black with white character-cell text):
Select CD-ROM Boot Type : 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.
On Tue, 2012-04-24 at 22:31 +0100, Matthew Garrett wrote:
(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:
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?
- 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
I get an md5 error when I try to make a live usb with fedora's live-usb creator. Anyone else seen this?
On Thu, 2012-04-26 at 13:34 +0100, Bastien Nocera wrote:
On Tue, 2012-04-24 at 22:31 +0100, Matthew Garrett wrote:
(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:
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 .
On Apr 27, 2012, at 10:21 AM, Adam Williamson wrote:
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.
On Apr 28, 2012, at 12:58 AM, Chris Murphy wrote:
"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:
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.
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:
On Sat, Apr 28, 2012 at 02:11:06AM -0600, Chris Murphy wrote:
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.
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.
On Apr 28, 2012, at 9:27 AM, Matthew Garrett wrote:
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.
As for this:
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
On Apr 28, 2012, at 1:22 PM, Chris Murphy wrote:
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
On Apr 28, 2012, at 1:53 PM, Chris Murphy wrote:
On Apr 28, 2012, at 1:22 PM, Chris Murphy wrote:
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
On Sat, Apr 28, 2012 at 01:53:19PM -0600, Chris Murphy wrote:
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
On Apr 29, 2012, at 6:20 AM, Matthew Garrett wrote:
On Sat, Apr 28, 2012 at 01:53:19PM -0600, Chris Murphy wrote:
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
On Apr 29, 2012, at 6:20 AM, Matthew Garrett wrote:
On Sat, Apr 28, 2012 at 01:53:19PM -0600, Chris Murphy wrote:
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
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
On Thu, 2012-05-10 at 15:02 -0600, Chris Murphy wrote:
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.
On May 10, 2012, at 8:56 PM, Adam Williamson wrote:
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
On 05/10/2012 09:34 PM, Chris Murphy wrote:
On May 10, 2012, at 8:56 PM, Adam Williamson wrote:
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."
--
"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
--
On May 10, 2012, at 10:52 PM, John Reiser wrote:
On 05/10/2012 09:34 PM, Chris Murphy wrote:
On May 10, 2012, at 8:56 PM, Adam Williamson wrote:
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."
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
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
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.
On Mon, 2012-05-14 at 09:07 -0600, Chris Murphy wrote:
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.
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Andreas Tunek -
Bastien Nocera -
Chris Murphy -
John Reiser -
Matthew Garrett -
Michal Schmidt -
Michele Baldessari -
Nikos Roussos -
Peter Jones -
Todd V Orvieto