Description of problem: When booting from CD burned with Fedora-14-x86_64-netinst.iso, grub starts but when handing off to kernel, text appears in upper left corner of screen and system locks up, requiring power-off to be performed to return functionality. In testing, grub itself has always worked without visible flaw, and the various built-in functions are accessible (menu editing, command line, etc.). It's just once tries to go any further that it breaks. Version-Release number of selected component (if applicable): unknown How reproducible: Always reproducible Steps to Reproduce: 1. Download Fedora-14-x86_64-netinst.iso and burn to disc 2. Select optical drive from Dell Latitude E6510 notebook from boot options menu 3. Allow boot process to proceed Actual results: System lock after displaying the following text: Trying to allocate 921 pages for VMLINUZ [Linux-EFI, setup=0x1017, size=398180] [Initrd, addr=0x7dc69000, size=0x1e8faee] Expected results: Successful launch of Fedora installer. Additional info: System is running BIOS revision A05. CPU is Intel Core i7 Q720, and memory total is 4GB. Grub identifies 640K lower and 3,339,004K upper memory (commas inserted for clarity). Windows 7 Enterprise 64-bit installation performed properly in UEFI mode.
Peter, any ideas?
I upgrade BIOS to revision A06, but the issue is unchanged.
An upgrade to revision A07 also did not help. However, this afternoon, I attempted to boot using a CD burned from the Fedora 15 Alpha boot.iso, which seems to have slightly different contents in the EFI directory. This boot attempt displayed the following: Trying to allocate 940 pages for VMLINUZ [Linux-EFI, setup=0x1017, size=3ab910] The CD was still reading, though, and after approximately 90 seconds, the boot screen switched out to a screen showing a number of Tuxes across the top and device identification text began scrolling across the screen. It stops with the following: [ 10.128129] cpuidle: using governor ladder [ 10.543771] cpuidle: using governor menu [ 10.128129] EFI Variables Facility v0.08 2004-May-17 It apparently locks up at that point. No keyboard functionality is available, at any rate, and the optical drive spins down. After a couple of minutes, the cooling fans kick up, which makes me wonder if there's some loop going on that's keeping the CPU active.
[ 10.128129] EFI Variables Facility v0.08 2004-May-17 Same as bug 683693 ?
I'm not really sure. 683693 has another line after it which does not appear to show up in my boot sequence. Mine stops at the EFI Variables Facility but does not throw the invalid op code (at least that shows on the display).
Using the new image posted on or about 03 Apr 11 (md5sum 2d6aeb3ae0b0637659ea7b59c70459b6) and the use of the noefi kernel option mentioned in bug 683693, I am able to get into the installer and at least as far as the drive space allocation. However, I am warned there about using a GPT bootdisk on a non-EFI system, presumably because Windows 7 is already installed in EFI mode. This is definitely getting closer. The kernel change mentioned in the other report seems to have enabled the basic operations to proceed, but I'm still left with an installer that doesn't know it's working on an EFI-capable system.
Using noefi means you're not touching the codepath that was involved in 683693. The installer is complaining because you're unable to set EFI boot variables (due to using noefi), which means it has no way to configure your system to boot. What happens if you attempt booting without noefi?
I get a result basically identical to the original issue here.
Text using boot disc created from ISO posted on 07 Apr 2011: Trying to allocate 940 pages for VMLINUZ [Linux-EFI, setup=0x1017, size=0x3ab7f0] [Initrd, addr=0x770f6000, size=0x8a02ddf] Should this bug be moved to Fedora 15?
Is anyone looking at this? Is it an EFI firmware bug?
I'll see if I can find some appropriate hardware to duplicate, but right now we have enough EFI issues where systems boot Windows that it's hard to determine whether we're hitting firmware bugs or legitimate differences in spec interpretation.
How much memory is in the machine that's failing?
It has 4GB. I'm not sure off the top of my head what the physical configuration is, but I think it's 2x2GB. I tried a couple of weeks ago using kernel options to restrict memory use, but aside from changing up the address and size parameters returned in the message, it doesn't change up anything.
I cracked open the case and confirmed. It is a 2x2GB configuration.
There are still problems with EFI in 3.0-rc, and even if we eventually get the fixes into F15 there will not be an official respin of the install disks. Please test rawhide/F16.