I've been unable to get Fedora to EFI boot on my 24-inch iMac. I've tried dd'ing the efiboot.img, using livecd-iso-to-disk --mactel, and using the latest EFI code in the liveusb-creator. Both F11 and desktop-x86_64-20091008.15 I can get to grub, but when attempting to boot a kernel, the screen just stays on the grub background, and nothing happens. Version-Release number of selected component (if applicable): F11 & F12 20091008 snapshot
Created attachment 364290 [details] EFI Shell Screenshot #1
Created attachment 364291 [details] EFI Shell Screenshot #2
Created attachment 364911 [details] dmidecode output
Created attachment 364912 [details] dmidecode output
Created attachment 365132 [details] lspci output
So I wrote this patch, and have been testing it with various base values (0x80010000, 0xc0010000, 0xc0000000), but to no avail. I'm not even quite sure if it's taking the proper code-path and detected my system as M_I24. Since I do not see any kernel output, only the grub background, its really difficult for me to debug this. --- a/drivers/video/efifb.c +++ b/drivers/video/efifb.c @@ -62,7 +62,7 @@ static struct efifb_dmi_info { [M_I17] = { "i17", 0x80010000, 1472 * 4, 1440, 900 }, [M_I20] = { "i20", 0x80010000, 1728 * 4, 1680, 1050 }, /* guess */ [M_I20_SR] = { "imac7", 0x40010000, 1728 * 4, 1680, 1050 }, - [M_I24] = { "i24", 0x80010000, 2048 * 4, 1920, 1200 }, /* guess */ + [M_I24] = { "i24", 0xc0010000, 2048 * 4, 1920, 1200 }, /* guess */ [M_MINI]= { "mini", 0x80000000, 2048 * 4, 1024, 768 }, [M_MB] = { "macbook", 0x80000000, 2048 * 4, 1280, 800 }, [M_MBA] = { "mba", 0x80000000, 2048 * 4, 1280, 800 }, @@ -90,6 +90,7 @@ static struct dmi_system_id __initdata dmi_system_table[] = { EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "iMac6,1", M_I24), EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac6,1", M_I24), EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac7,1", M_I20_SR), + EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac8,1", M_I24), EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "Macmini1,1", M_MINI), EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBook1,1", M_MB), /* At least one of these two will be right; maybe both? */
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Adding as a SOAS-3 blocker as this is causing issues with the SOAS liveCD on Macs which alot of schools have.
CC'ing Ajax and Peter, whom I discussed this with at FUDCon. So, to figure out the base address, this apparently involves writing code to walk through memory writing various pixel values, and figuring out which one displays the correct output. I think Peter said he had already written this, or was going to?
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I have a similar problem on a macbook pro 3,1 , when trying to run the Fedora 13 live CD (both with an USB media or a DVD). The screen is stuck just after booting on the Fedora 13 entry. No kernel message, no anaconda message. Is there a way I could debug this boot process ? By giving boot options or something else ?
Updating to rawhide, also not sure if there's a 'generic' way we can do this for all Mac's or EFI systems as we're going to get a lot more EFI systems this release cycle
ping pjones.
Confirming this bug with desktop-x86_64-20100725.17. I have same question as Axel.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Probably dupe: #521474 (older, but this report has more info) @RedHat: Any info on how we can get more data to help you debug this?
pjones: any update on this? i believe you had plans to fix the mac graphics initialisation issues.
Used a custom Fedora spin to get around Bug 608034 with the new Mac Mini (mid 2010), than ran into this bug! Confirming.
Not sure if this helps... but Ubuntu works on the new Mac Mini with this patched version of 10.04: https://help.ubuntu.com/community/Macmini4-1/Lucid
Please run the following command in a MacOS X terminal in order to get the values you need : sudo ioreg -lw0 |grep manufacturer|cut -b25-80;sudo ioreg -lw0|grep "product-name"|cut -b 25-80;sudo dtrace -qn 'BEGIN{boot_args=((struct boot_args*)(`PE_state).bootArgs);printf("FrameBuff erBase: 0x%08x\nPixelsPerScanLine: %d\nHorizontalResolution: %d\nVerticalResolution: %d", boot_args->Video.v_baseAddr, boot_args->Video.v_rowBytes/4, boot_args->Video.v_width, boot_args->Video.v_height);exit(0)} '
That gave: <"Apple Inc."> <"Macmini4,1"> FrameBuff erBase:0xc0010000 PixelsPerScanLine: 2048 HorizontalResolution: 1920 VerticalResolution:1200 So the only solution at the moment is to use the patch included in comment 6 (with correct values)?
M.H., Yes my understanding is that with the current kernel code, hard-coding these values per model is the only way to make it work. In the longer term, the kernel could retrieve these values using the EFI API or grub-efi could maybe pass these values to the kernel (grub-efi is already using it). Regards, metatech
Created attachment 440178 [details] efifb: support framebuffer for NVIDIA GeForce 8800 GS in iMac 8,1 This patch gets the efifb working on my iMac, with the following specs: <"Apple Inc."> <"iMac8,1"> FrameBuff erBase: 0xc0060000 PixelsPerScanLine: 2048 HorizontalResolution: 1920 VerticalResolution: 1200
Created attachment 440179 [details] efifb: support framebuffer for the Macmini 4,1 A patch to enable the Macmini4,1 framebuffer, based on the values provided in Comment #21
I spun up a live F13 image with both of these patches: http://lewk.org/livecd-fedora-livecd-desktop-201008212237.iso I also had to pass in the 'nomodeset' argument to the kernel.
Confirmed the patched kernel included in the image from comment 25 works with my Mac mini.
Created attachment 441383 [details] /0003-efifb-support-framebuffer-for-the-iMac10-1.patch <"Apple Inc."> <"iMac10,1"> FrameBuff erBase: 0xc0010000. PixelsPerScanLine: 2048 HorizontalResolution: 1920 VerticalResolution: 1080
Created attachment 441385 [details] 0004-efifb-support-framebuffer-for-the-Macmini3-1.patch <"Apple Inc."> <"Macmini3,1"> FrameBufferBase: 0x40010000 PixelsPerScanLine: 1024 HorizontalResolution: 1024 VerticalResolution: 768
Created attachment 441387 [details] 0005-efifb-support-framebuffer-for-the-MacBookPro2-2.patch <"Apple Computer, Inc."> <"MacBookPro2,2"> FrameBufferBase: 0x80010000 PixelsPerScanLine: 1472 HorizontalResolution: 1440 VerticalResolution: 900
Created attachment 441389 [details] 0005-efifb-support-framebuffer-for-the-MacBookPro2-2.patch Multiply the PixelsPerScanLine by 4, like every other entry.
Created attachment 441390 [details] 0005-efifb-support-framebuffer-for-the-MacBookPro2-2.patch Actually upload the right patch this time...
Luke, From the kernel source it seems that it is not needed to recompile the kernel, adding this kernel parameter should be enough (the values are specific to your model, coming from the ioreg/dtrace output) : video=efifb:base:0xc0030000,stride:2048,width:1440,height:900 I could not test it yet because my grub is still hanging after loading initrd... metatech
We have a possible patch, looks like an easy fix. Increasing priority, as it's also affecting most of new Mac users. Luke, would you please help on having somebody at RH close this? Hoping this will be fixed for FC14 beta.
*** Bug 521474 has been marked as a duplicate of this bug. ***
Created attachment 441597 [details] efifb: Support framebuffer for a variety of Macs A patch against our current F14 kernel package
Tommaso, could you please provide us with the output from the command in Comment #20 for your MacBookPro5,5?
Created attachment 441600 [details] Combined patch Rollup of the five patches
Other values reported by users are available here : http://ubuntuforums.org/showthread.php?t=1557326
<"MacBookPro3,1"> FrameBuff erBase:0xc0030000 PixelsPerScanLine: 2048 HorizontalResolution: 1440 VerticalResolution:900
I d like to add that Fedora 13 live doesn't boot either on a Virtualbox virtual machine setup with an EFI rom. Is this problem related ?
I was considering improving the grub2 code in order to automatically add the correct efifb values : In file loader/i386/efi/linux.c, in the "for" loop after the line "dest = grub_stpcpy (dest, argv[0]);" If the parameter "video=efifb:auto" exists, it would be replaced by "video=efifb:base:0xc0030000,stride:2048,width:1440,height:900" with the values dynamically discovered at the beginning of the function (fb_base + line_len). Do you think it would work ? metatech
Warning : beware that these values seem to depend on the amount of RAM when it is 4GB or less. http://ubuntuforums.org/showthread.php?t=995704&page=17 post #164 So they cannot be hard-coded, except as a fallback value for those models.
I just sent a patch upstream containing entries for a dozen new macs: http://lkml.org/lkml/2010/9/1/346 I only added models that did not conflict with any existing entries. As mentioned in Comment #42, hard-coding these values is not a proper solution. The driver currently matches based on vendor+model, yet there are many models that contain different addresses/resolution/etc. The efifb driver will probably need to be improved to match against PCI vendor/model/subvendor/submodel IDs. Here are some machines that I omitted due to conflicts: <"MacBookPro3,1"> FrameBuff erBase:0xc0030000 PixelsPerScanLine: 2048 HorizontalResolution: 1440 VerticalResolution:900 <"Apple Inc."> <"Macmini3,1"> FrameBufferBase: 0xc0010000 PixelsPerScanLine: 2048 HorizontalResolution: 1280 VerticalResolution: 800 <"Apple Inc."> <"MacBookPro4,1"> FrameBuff erBase: 0xc0060000 PixelsPerScanLine: 2048 HorizontalResolution: 1440 VerticalResolution: 900 <"Apple Inc."> <"iMac10,1"> FrameBuff erBase: 0xc0010000 PixelsPerScanLine: 1920 HorizontalResolution: 1920 VerticalResolution: 1080 <"Apple Inc."> <"MacBookPro5,1"> FrameBufferBase: 0x90010000 PixelsPerScanLine: 2048 HorizontalResolution: 1440 VerticalResolution: 900 <"MacBook6,1"> FrameBuff erBase: 0x80010000 PixelsPerScanLine: 2048 HorizontalResolution: 1280 VerticalResolution: 800 <"MacBook6,1"> FrameBuff erBase: 0xc0010000 PixelsPerScanLine: 2048 HorizontalResolution: 1280 VerticalResolution: 800 <"Apple Inc."> <"iMac10,1"> FrameBuff erBase: 0xc0010000 PixelsPerScanLine: 2048 HorizontalResolution: 1920 VerticalResolution: 1080
Hi Luke ! Thanks for the nice compilation work ! I intended to do the patch, but you did it before me... The following model has no conflicts but was not part of the submission : [M_MBP_5_3] = { "mbp53", 0xd0010000, 2048 * 4, 1440, 900 }, Can you add it to your patch or I generate a new patch ? Thanks. metatech
(In reply to comment #44) > Hi Luke ! > > Thanks for the nice compilation work ! > I intended to do the patch, but you did it before me... Ah, sorry about that. Once you mentioned the command to spit out the appropriate values, I wanted to enable as much hardware as possible before F14. Thank you for helping to wrangle a lot of machine. > The following model has no conflicts but was not part of the submission : > [M_MBP_5_3] = { "mbp53", 0xd0010000, 2048 * 4, 1440, 900 }, > Can you add it to your patch or I generate a new patch ? Thanks, I just sent an updated patch upstream with the MacBookPro5,3 and MacBook6,1 (I gathered conflicting values for the 6,1, but we might as well have 1 entry listed in the driver as opposed to none).
Created attachment 442546 [details] Consolidated patch containing EFI framebuffer support for 14 more macs
Luke, Regarding the out-of-the-box support for these models, the sooner the better ! So it is good if your patch can already be fast tracked into Fedora Core 14. Will it be already included in the beta release ? Regarding the conflicts, when there are several values for the FrameBufferBase, I would always take the smallest one, because it is the value of the standard model variant, without memory upgrade options. This is the variant that people are the most likely to have. Thanks again for your work, metatech
(In reply to comment #47) > Luke, > > Regarding the out-of-the-box support for these models, the sooner the better ! > So it is good if your patch can already be fast tracked into Fedora Core 14. > Will it be already included in the beta release ? The patch has already been committed to the F14 kernel branch, so I assume it'll be in the beta. > Regarding the conflicts, when there are several values for the FrameBufferBase, > I would always take the smallest one, because it is the value of the standard > model variant, without memory upgrade options. This is the variant that people > are the most likely to have. Peter just wrote a patch for the efifb driver that will allow us to define multiple entries for each model containing different values. The driver will then only use the entry containing a base address that falls within the range of a PCI BAR on a VGA device in the machine. http://git.kernel.org/?p=linux/kernel/git/pjones/efi.git;a=commitdiff;h=0678f5a34a3d6a42ed234195d0e93298e0f6ae15;hp=2bfc96a127bc1cc94d26bfaa40159966064f9c8c
Luke and Peter, Thanks for your progress on the matter ! I have another suggestion that might eliminate the need for hard-coded framebuffer base [list of] values altogether. Grub2 contains code to automatically discover the framebuffer base address : see grub 1.98 in file loader/i386/efi/linux.c function "find_framebuf". Unfortunately, the PCI code looks cryptic to me, so I do not dare to give a try. Do you think the same logic could be used in the efifb driver ? Thanks. metatech
(In reply to comment #48) > The patch has already been committed to the F14 kernel branch, so I assume > it'll be in the beta. The nightly F14 branch compose from here http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ still doesn't work: grub, loads, counts down, then remains on blue screen. Does it work for anybody else? Should it? (is the patch actually in)
(In reply to comment #50) > (In reply to comment #48) > > The patch has already been committed to the F14 kernel branch, so I assume > > it'll be in the beta. > The nightly F14 branch compose from here > http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ > still doesn't work: grub, loads, counts down, then remains on blue screen. > > Does it work for anybody else? Should it? (is the patch actually in) That live image does not work for me. It looks like the patch made it into the F14 kernel branch, but not rawhide (which is what I assume the nighly-composes are based on).
(In reply to comment #51) > (In reply to comment #50) > > (In reply to comment #48) > > > The patch has already been committed to the F14 kernel branch, so I assume > > > it'll be in the beta. > > The nightly F14 branch compose from here > > http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ > > still doesn't work: grub, loads, counts down, then remains on blue screen. > > > > Does it work for anybody else? Should it? (is the patch actually in) > > That live image does not work for me. It looks like the patch made it into the > F14 kernel branch, but not rawhide (which is what I assume the nighly-composes > are based on). Nightly composes are based on the upcoming release and not rawhide so its likely its made it to rawhide and not F-14.
Today's rawhide doesn't work either. I'll wait for somebody to confirm patch was actually committed, mark this issue fixed, let us know what live boot iso we can use for testing and gladly test it. Thanks
FWIW Discussed at blocker meeting today. Under #4 http://fedoraproject.org/wiki/Fedora_14_Beta_Release_Criteria this bug does not qualify as a release blocker.
kernel-2.6.35.4-28.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/kernel-2.6.35.4-28.fc14
kernel-2.6.35.4-28.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/kernel-2.6.35.4-28.fc14
kernel-2.6.35.4-28.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
It would be interesting to know whether the patched kernel actually works on a MBP 6.2, I suppose the original poster owns one ? I have some doubts, because in the post #1140 in this thread http://ww.ubuntuforums.org/showthread.php?t=995704&page=114, Andreas Heider, author of the GPU swiching driver in this thread http://ubuntuforums.org/showthread.php?t=1564298, reports that on a MBP6,2 this other kernel patch is needed https://patchwork.kernel.org/patch/119823/ in order to boot without "noefi" kernel parameter. Unfortunately, the "noefi" has serious inconveniences, such as disabling the screen brightness control. On my MBP5,3, I also need to use the "noefi" parameter to allow EFI booting. metatech
I just tried desktop-x86_64-20100924.16.iso on a usb drive using liveusb-creator, and my MacBook Pro 6,2 currently does not boot using EFI. I'm able boot GRUB ok, but once I select a boot option it freezes like originally reported. Is there an easy way to generate a livecd iso with the above patch? I'm comfortable compiling the kernel, but not very familiar on how to prepare the kernel for a live cd. Let me know if there's any additional information I can provide to solve this issue.
I'm looking at the git branch for f14, and it looks like this patch didn't get fully applied. efifb-add-more-models.patch only appears to add a subset of what was proposed here and what was recently applied upstream here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a5757c2a474a15f87e5baa9a4caacc31cde2bae6. Among the models missing is the MacBook Pro 6,2. I'm in the process of building the kernel from source using a vm with the upstream patch, and substituting the kernel rpm in the livecd-creator config. I'll post an update later today if I'm able to boot with this change.
Re-opening per above comments. This would be critical to fix before F14 release rather than as an update, as MBP 6.2 (and maybe others?) can't even boot.
Peter, I finally found out why passing the efifb parameters on the kernel parameter line like the following does not work (anymore) : video=efifb:base:0xc0030000,stride:2048,width:1440,height:900 In function "efifb_init" : 481 dmi_check_system(dmi_system_table); 482 483 if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI) 484 return -ENODEV; 485 486 if (fb_get_options("efifb", &option)) 487 return -ENODEV; 488 efifb_setup(option); The check at line 483 is done too soon : it should be done after line 488. This seems to be a side effect of the efifb/imacfb consolidation two years ago. Can you please move or remove the check, so that unknown systems can easily be supported by editing grub configuration file ? Other topic: I saw that the PCI checking code already made its way to the Linux main branch, I guess it will part of 2.6.36... that is awesome ! Thanks in advance, metatech
Give me a bit of time to do more tests regarding my last comment, something does not sound quite right in the reasoning. I will keep you posted.
I confirm comment#62, but a step is missing : the orig_video_isVGA is 0, so it must be set to VIDEO_TYPE_EFI (same reason I guess as the past contribution of Brian Maly in efifb.c). I will post the patch once it cleanly works on my machine. metatech
kernel-2.6.35.6-39.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/kernel-2.6.35.6-39.fc14
kernel-2.6.35.6-39.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Support for the iMac9.1 also needs to be added. The details are: <"Apple Inc."> <"iMac9,1"> FrameBuff erBase: 0xc0060000 PixelPerScanLine: 2048 HorizontalResolution: 1920 VerticalResolution:1200
Tested desktop-x86_64-20101009.19 on MacBook Pro 6,2: it still freezes right after grub countdown gets to 0. Adding "noefi text" will start booting with a garbled screen resolution (can't read text), and then freeze after ~3seconds. It looks like the same behaviour as the regular boot.
(In reply to comment #68) > Tested desktop-x86_64-20101009.19 on MacBook Pro 6,2: it still freezes right > after grub countdown gets to 0. Can you run the command in Comment #20 and give us the output? Thanks.
Sure, I've missed that comment: <"Apple Inc."> <"MacBookPro6,2"> FrameBuff erBase: 0x90030000 PixelsPerScanLine: 2048 HorizontalResolution: 1680 VerticalResolution: 1050 Please let me know if I can help with other info, testing or anything.
(In reply to comment #70) > Sure, I've missed that comment: > > <"Apple Inc."> > <"MacBookPro6,2"> > FrameBuff erBase: 0x90030000 > PixelsPerScanLine: 2048 > HorizontalResolution: 1680 > VerticalResolution: 1050 > > Please let me know if I can help with other info, testing or anything. These numbers match up with the patch found in kernel-2.6.35.6-39.fc14, which is in the desktop-x86_64-20101009.19 live image.
(In reply to comment #71) > These numbers match up with the patch found in kernel-2.6.35.6-39.fc14, which > is in the desktop-x86_64-20101009.19 live image. With desktop-x86_64-20101016.18 I still get results in comment #68. I've tried nomodeset, video=efifb... parameters (with my numbers), still freezes at grub blue screen when it attempts to boot. The only parameter making a difference is noefi, which gets Fedora booting, but with garbled screen and a freeze seconds later.
I'm a bit concerned that the EFI bootloader isn't even running, because I can run the i386 efidisk.img and I get the same result. I shouldn't even be able to get to the i386 bootloader in that environment. FWIW, my MacBookPro6,2 has a different resolution but the same base address. It has 4 GiB of memory; does the address move around based on how much RAM a system has? <"Apple Inc."> <"MacBookPro6,2"> FrameBuff erBase: 0x90030000 PixelsPerScanLine: 2048 HorizontalResolution: 1440 VerticalResolution: 900
Here is mine : <"Apple Inc."> <"MacBookPro5,5"> FrameBufferBase:0xc0010000 PixelsPerScanLine: 2048 HorizontalResolution: 1280 VerticalResolution:800
Same on my MacBookPro 5,5 with 4G of memory: <"Apple Inc."> <"MacBookPro5,5"> FrameBuff erBase: 0xc0010000 PixelsPerScanLine: 2048 HorizontalResolution: 1280 VerticalResolution: 800
Another one to add to the list. <"Apple Inc."> <"MacBookAir2,1"> FrameBuff erBase: 0x80010000 PixelsPerScanLine: 2048 HorizontalResolution: 1280 VerticalResolution: 800
Fedora-14-x86_64-Live-SoaS.iso Final release as CD CD boots with USB external DVD/CD in Apple MacBook Air if you select the second option on boot menu: (contains nomodeset xdriver=vesa) The first boot option works but display is garbled.
I could not get your command to run: Here is About this machine/more/Graphics/Display info <"Apple Inc."> <"MacBookAir3,1"> Chipset Model: NVIDIA GeForce 320M Type: GPU Bus: PCI VRAM (Total): 256 MB Vendor: NVIDIA (0x10de) Device ID: 0x08a2 Revision ID: 0x00a2 ROM Revision: 3571 Displays: Color LCD: Resolution: 1366 x 768 Pixel Depth: 32-Bit Color (ARGB8888) Main Display: Yes Mirror: Off Online: Yes Built-In: Yes Connection Type: DisplayPort Display Connector: Status: No Display Connected
https://bugzilla.redhat.com/show_bug.cgi?id=528232#c20
Still not booting on 6.2 with "nomodeset xdriver=vesa"
I was booting from an USB stick, which results in a freeze after passing grub boot. Booting from CD works on 6.2, with "nomodeset xdriver=vesa"
Marius, you and I have the same MBP6,2 model - a mid-2010 15-inch with the hi-resolution display, Intel Core i7 2.66GHz CPU. I too am experiencing the problem in this thread. I tried several times to boot from a USB flash drive containing either the x86_64 netinst.iso image, or the x86_64 efidisk.img found on the DVD and extracted to the USB flash drive. I simply could not get either to boot properly... The x86_64 F14 netinst.iso simply did not boot at all from USB. The x86_64 F14 efidisk.img, extracted from the DVD, actually booted(!) from the USB drive, and I got to see the Fedora 14 initial splash screen and countdown, but at the end of the countdown (14 seconds?), it would hang and go nowhere. After many unsuccessful attempts, last night, I gave up and just inserted the F14 x86_64 DVD into the MBP CD/DVD drive slot, and... It booted right up! I continued and did the entire F14 installation off the DVD. I got all the way through, no problems at all, and the video/display was perfect from the beginning of the installation, all the way through to the end. On the final reboot at the end of the installation, the MBP could not EFI boot my new F14 installation. So, I went and got the latest rEFIt v0.14 bootloader and installed that onto Mac OS X, restarted 2 times, and on the second restart, I saw the prompt to boot either Mac OS X or the penguin (F14)... I chose F14 and booted right into my new F14 installation! Warning: Get rid of the rghb kernel startup param, and the quiet param, and anything else graphically related, in order to see exactly what's going on during the F14 boot process... Why? Because I got a prompt from SELinux that it would have to make changes to the partition. I'm not certain why, but I went ahead with that, and did not touch anything and allowed SELinux to proceed, which took about 10 minutes. If all those graphical booting images and crap were active, then the user would not even know what's going on, and would likely think that the boot process had hung - because during an F14 boot on the MBP, you cannot SHIFT-ALT-F1, F2, F3... Anyway, I just let it go, and eventually it finished, and I was prompted for another reboot, and sure enough, I got into F14 and began the yum updating, via wired ethernet, because the wireless was not detected. One thing I forgot to mention: After the F14 and the rEFIt installs, you might need to use the rEFIt partition utility to write the new MBR/GPT. So, it does seem like F14 has problems EFI-booting from USB flash drives, or any image installed on them, for MBPs, and maybe even all Macs, in general? I really have to congratulate the whole Red Hat and Fedora teams because Fedora 14 is just wonderful. Yes, there are problems, but I have been using Fedora since v6, and it just keeps getting better, and better. Frankly, I really hate having to rely on rEFIt to EFI dual boot Mac OS X and Fedora, so I hope that this gets fixed and that F15 EFI boots from any media! Thanks, guys.
look at: I am routinely booting live USB's with persistence on my MacBook Air http://people.sugarlabs.org/Tgillard/soas-3-boot-test.txt (Credits to Programmer) http://people.sugarlabs.org/Tgillard/soas-3-boot-test.iso (f13) http://www.wronkiewicz.net/soas-4-boot-test.iso (f14) http://wiki.sugarlabs.org/go/Mac_OS_X-Boot_USB_with_Virtualbox#Boot_Helper_CD.27s These Helper CD's boot fine in a MacBook Air by holding "C" until fedora Blue boot screen appears (Use low graphics selection) and look for a USB labelled FEDORA (CAPS) fat 16 in OSX Disk utility / erase) /(fat16) Label=FEDORA Note: attempting to boot this Live USB outside of OSX ruins it. I do not know why.
all_bugzilla: I can confirm your experiences, same here
I updated our patch to support the following models: iMac9,1 MacBookAir2,1 MacBookPro5,5 MacBookPro6,2 I also spun up an F14 x86_64 live image with this patch. Testing appreciated. http://lewk.org/livecd-fedora-live-desktop-201101311532.iso
Tried the above image on USB with no luck. I have a MacBook Pro 6,2 with efifb values matching those in comment #70. I tried booting with the default commands, noefi, and setting the efifb addresses manually. Should there be a specific command I should be trying?
MacBook Air 11.3" 128GB Test: boot with "C" held down using Mac External DVD/CD Drive. Boots to (gdm) Automatic Login from Live CD Then to Gnome Desktop Live System User Magic Mouse and wireless DO NO WORK Plug in MacBook USB Ethernet adapter and it finds network. Wired Network Auto eth0 Bluetooth on Laptop Battery (98.1%) Works Nicely ---------------------------------- About this computer: Release Kernel Linux 2.6.35.10-81.fc14x86_64 Gnome 2.32.0 Hardware: Memory 1.7 GiB Processor 0: Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz Processor 1: Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz System Status Available disk space: 192.2 Mib File Systems: Device Directory Type Total Free Available Used /dev/mapper/live-rw / ext4 3.0 GiB 222.9 MiB 192.2 MiB 2.7 GiB
Installs to VirtualBox 4.02 8GB HD correctly firstboot/smolt/gdm login Installed sugar-desktop #yum groupinstall sugar-desktop #yum install sugar-emulator (About my computer: Fedora release 14 (Laughlin) Sugar: 0.90.1 Telepathy gabble works on f1 on Jabber software update does not work (known bug) keyring knows user password sugar-browse works and downloads IRC-8.xo from ASLO
Using the patched 201101311532.iso burned to a DVD, I was able to do the Live boot on my Macbook Pro 3,1. (I could not get it to boot from a USB I normally use to install on Lintel systems, but I believe that's related to the old Apple EFI.) From the Live OS, I ran liveinst (from a terminal as the desktop file wasn't launching). The install went perfectly. The Apple trackpad did not work until I did the update. Now with the closed nvidia drivers, life is beautiful. Many thanks Luke!
EFI boot works. http://alt.fedoraproject.org/pub/alt/stage/15.RC3/Live/i686/Fedora-15-i686-Live-SoaS.iso Macbook Pro8,1 2.7 Ghz Intel core i7 Intel HD Graphics 3000 GPU 1280x800 32 bit Burned to a CD it boots with"C" key held on power on. Does not require safe graphics wish the Airport Extreme (0x14E4, 0xD6) Broadcom BMC43xx 1.0 5.100.198.10.2 card worked... Wired ethernet does work. Thanks
Hello satellit, You say you are using the i686 version, which should not work on a 64-bit EFI (at least without "noefi" option). Also, MacBookPro8,1 is 13 inch model with only one graphic card card (Intel, no ATI), so the benefit of EFI is not so big. Are you sure you are using the EFI boot and not the BIOS boot ? Thanks, metatech
All, For the record, I came to the conclusion that the "efifb.c patching" is the wrong approach. Normally the bootloader is responsible for querying the graphics hardware properties (FrameBufferBase, PixelsPerScanLine, HorizontalResolution, VerticalResolution), and then it passes them to the kernel through the "linux_kernel_params" structure. Grub2 can do that, for both UGA (PCI scanning trick) or GOP (returned by the official EFI API). The kernel should not have this list of hard-coded values. Furthermore, these values are not unique for a Mac model, but can very depending on the amount of RAM and possibly also on the connected devices at boot time. See user submissions in this thread : http://ubuntuforums.org/showthread.php?t=1557326 On top of that, these values in efifb.c are really misleading : someone looking for a reason why the EFI boot does not work on a brand new model might think that his model is missing in the list and that causes the problem, which is a wrong track. I think we should remove these hard-coded values from the kernel and only rely on values passed by the booloader (which should be dynamically queried), so that it will work on all models. Regards, metatech
RC3 Version burned to CD "C" held at boot until CD Boots TAB at boot; > vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-15-i686-Live-Desktop.iso rootfstype=auto re liveimg quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 ------- Plymouth boot (f) startx starts (Note no 5 minute delay here like soas spin has) gnome3-shell system Info: Gnome3.0.1 Intel Core i7-2620M CPU @2.70 GHzx4 Graphics Intel Sandybridge Mobile (Standard) 32 bit 3.1 GB Normal Gnome3-shell exept no wireless available (wired works fine)
grub2 has support for probing UGA systems to determine the screen pitch and framebuffer offset. No other EFI bootloader has that support, so right now that data lives in the kernel. For the GOP machines, entries have only been added to efifb.c when the firmware gives us back lies (such as an incorrect pitch on 11" Macbook Airs). The alternative to patching the kernel in these cases is to patch the system firmware, which is generally considered less practical and maintainable.
MacBook Pro 15in from 1Q2011. All variants have "Intel HD Graphics 3000" and "AMD Radeon HD 6490M". The amount of GDDR5 memory attached to the Radeon varies: machines with a 2.0GHz Core i7 having 256MB, those with a 2.2GHz Core i7 having 1GB. In the 15in variants there are three display options: "Glossy widescreen display" (1440x900), "Hi-res glossy widescreen display" (1680x1050), and "Hi-res antiglare widescreen display" (1680x1050). This particular machine MacBook Pro 15in from 1Q2011 has: 2.2GHz Core i7, and thus 1GB memory for the Radeon; "Hi-res antiglare widescreen display". The program from #20 prints: <"Apple Inc."> <"MacBookPro8,2"> FrameBuff erBase: 0x90010000 PixelsPerScanLine: 1728 HorizontalResolution: 1680 VerticalResolution: 1050
I'm using a MacBookPro6,2 with the same values as https://bugzilla.redhat.com/show_bug.cgi?id=528232#c73. Using the efidisk.img from Fedora 15, and I'm getting the standard "hangs after grub countdown." Is there a new image I can try?
Mike, On MacBookPro 6,x or 8,x the following kernel patch is known to act as a good workaround : "Run EFI in physical mode" https://patchwork.kernel.org/patch/337911/ The patch "Retain boot service code until after switching to virtual mode" can provide an actual fix. https://patchwork.kernel.org/patch/798202/
> The patch "Retain boot service code until after switching to virtual mode" can > provide an actual fix. > https://patchwork.kernel.org/patch/798202/ Is there an ETA for getting this in mainline or Fedora's kernel? And then a rebuilt efidisk.img?
Mike, The patch "Retain boot service code until after switching to virtual mode" is included in 2.6.39.1 (and higher). Hopefully it will provide a fix most (if not all) users.
Mike, In the mean time, you can try booting using the "noefi" or "noexec=off" kernel parameters.
This should finally be fixed in F16, please test and file bugs against rawhide.
Good day. I apologize if this is probably the incorrect place to put my question, but so far this is the closest thing i've been able to find to what i'm seeking for. I've installed FC15 on an iMac 7,1 (with an ati HD2600pro card) and use the open source ati driver for graphical output. Well, i've installed grub2 and i've been able to boot flawlessly into Fedora in single mode (i.e. no X!) using EFI. What isn't working is X, and i've found confusing indications about X supporting my graphic card in EFI mode. Googling around, it seems that X *can* start on apple systems (noticeably, Ubuntu distros) with ATI cards, even using KMS (and grub2 obviously) but i've found no explicit reference to my hardware combination (iMac 7,1 an ati HD2600pro). I've tried various combinations of grub2 hacks (such as fakebios, loadbios, or so) but to no avail. X starts, the screen stays blank but the system is not frozen. I can issue commands (such as quitting X for example). So my question is: X is still heavily relying on bios for setting up the graphic card, or what? Thank you for any hint and again i apologize if this is not the correct thread.
I've forgotten one more little question. I have expanded the RAM in my iMac to 4GB so that the framebuffer base address is different from iMacs with only 1 GB (which is the default configuration). The question is: with recent version of the kernel (>= 2.6.40)is it possible to pass the base address via the video=efifb:base:0xXXXXXXXXX... trick or these settings are still ignored? Do i need to recompile the kernel from scratch? Thanks again