Bug 691860 - UEFI version of ISO fails to boot when >4gig (since f14)
Summary: UEFI version of ISO fails to boot when >4gig (since f14)
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 16
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Matthew Garrett
QA Contact: Fedora Extras Quality Assurance
: 691862 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2011-03-29 17:10 UTC by Harry Hsiung
Modified: 2013-03-25 00:37 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-02-13 18:59:23 UTC
Type: ---

Attachments (Terms of Use)
Screen capture just prior to system reset (1.46 MB, image/jpeg)
2011-04-07 03:58 UTC, Aaron Spurlock
no flags Details

Description Harry Hsiung 2011-03-29 17:10:28 UTC
Description of problem: Fedora 14 UEFI enabled ISO image fails when system has >4gig of memory.

Version-Release number of selected component (if applicable): not sure if it is grub, anaconda or kernel failing.
was tested initially on Intel Starlake xeon UEFI 2.1 system with 6gig.
works fine if memory is lowered to 2gig

How reproducible: always fails

Steps to Reproduce:
1. pull iso from http://fedorapeople.org/groups/anaconda/uefi/ 
2. boot to UEFI session on dvdrom/cdrom from bios
3. grub will start and then system will hang (screen is blank)
Actual results:

Expected results:
 should install fine from dvdrom/cdrom.

Additional info:

Comment 1 Aaron Spurlock 2011-04-07 03:58:55 UTC
Created attachment 490472 [details]
Screen capture just prior to system reset

Comment 2 Aaron Spurlock 2011-04-07 04:08:02 UTC
Issue can also be recreated on an Asus E35M1-M Pro AMD Zacate system.  Configured with 1x4GB RAM & 1 x WD30EZRSDTL.  Behaviour is as follows:

1.  System splash screen displayed stating 'Press any key to enter menu' and 'Booting Fedora 14 in 4, 3, 2 ,1' etc.
2. When counter reaches 0, 2 lines of text in upper left (see attached image) appear, followed approximately 6 seconds afterward by 3rd line.  Text is as follows:

Trying to allocate 921 pages for VMLINUZ
[Linux-EFI, setup=0x1011, size=0x398180]
   [Initrd, addr=0x7dd6c000, size=0x1e8faeee]

Comment 3 Peter Jones 2011-04-13 17:20:56 UTC
At first glance, this appears to be the kernel failing.

Comment 4 Matthew Garrett 2011-04-13 17:24:21 UTC
*** Bug 691862 has been marked as a duplicate of this bug. ***

Comment 5 Peter Jones 2011-04-13 18:48:45 UTC
This works for me with efidisk.img (via a usb stick) with 8gb of ram.  Right now I'm unable to get even this far with an actual CD or DVD; it's not even finding and mounting the partition.  I've inspected the iso image and it appears to be fine, so I'm wondering if the UEFI driver for the SATA optical drive is actually working correctly with this much RAM, or if the drive in this test box has reached its failure point. Right now I'm waiting for the RAM to cool down so I can remove some of it and try again.

Comment 6 Peter Jones 2011-04-14 16:09:19 UTC
It seems that my starlake machine can no longer reliably read CDs or DVDs of any kind, with any drive or cable. I'm very confused about this.

Comment 7 Peter Jones 2011-04-14 17:36:26 UTC
Okay, my starlake is working again. It also successfully boots the F14 boot.iso on a CD-R with both 4 and 6 GB of RAM installed.

Can you attach the output from the 'memmap' command so we can see what's being laid out differently on that machine than this one?

Comment 8 Aaron Spurlock 2011-05-09 21:30:56 UTC
Update on comment 2: More evidence which (I think) supports the kernel-failure hypothesis.  I have now had the opportunity to experiment with the following:

1.  Removing the 3TB drive and replacing it with a smaller HDD (120GB)
2.  Using 1x2GB DIMM (either socket)
3.  Using 1x4GB DIMM (either socket)
4.  Booting in EFI mode
5.  Using system to connect to EFI shell
6.  Installing from EFI-mode F15 beta

All of which result in exactly the same behavior as originally reported and illustrated by the attached image.

Comment 9 Matthew Garrett 2011-05-09 21:37:29 UTC

If your system fails with 2GB then it sounds unrelated to this problem.

Comment 10 Glen Turner 2011-05-25 06:30:12 UTC
I have a Macbook Pro 8,2 with 8GB of RAM exhibiting this issue when installing Fedora 15 netinst from USB stick.

Removing all the the graphical stuff (eg, the counting down from 15 above) from BOOTX86.CONF, booting, and typing at the BOOTX86.EFI command line I see:

grub> kernel /images/pxeboot/vmlinuz
Trying to allocate 941 pages for VMLINUZ
[Linux-EFI, setup=0x1017, size=0x3ac310]

grub> initrd /images/pxeboot/initrd.img
   [Initrd, addr=0x79cdf000,size=0x5e1b648]

grub> boot

No output is seen from the kernel and anaconda never starts.

I do wonder if this is a framebuffer issue.

Comment 11 Matthew Garrett 2011-05-25 11:45:55 UTC
Unless your Mac boots when you have less than 4GB of RAM, it's not the same issue.

Comment 12 Glen Turner 2011-05-25 13:47:00 UTC
Agreed, and it's a Mac, so I can't just rip out 4GB.

I suppose I was hinting that perhaps the address of the framebuffer moves when the amount of RAM crosses a magic boundary. I do not know why that would be, but I do know the symptoms above exactly match those experienced on Macs when EFI booting and the kernel determines the wrong frame buffer address.

Comment 13 Matthew Garrett 2011-05-25 13:57:02 UTC
The Mac failure is likely to be due to the firmware making boot services calls from the runtime services. I've just sent a patch upstream to deal with that. This failure is more mysterious.

Comment 14 Johannes Engel 2011-06-09 17:43:08 UTC
I can confirm the described behaviour using Fedora 15 on a Lenovo ThinkPad T420 (SandyBridge) in UEFI mode.

Comment 15 Danny Stieben 2011-08-24 04:04:56 UTC
I can confirm that this bug affects an ASUS Crosshair V Formula motherboard w/ AMD Phenom II X6 1100T processor, both Fedora 15 and Fedora 16 Alpha.

I have a 1TB SATA HDD installed along with 8GB RAM. I haven't tried to change any part of my configuration yet, but I get the exact same error when I try to boot.

BIOS Emulation of the UEFI system on the MB is buggy, so I literally HAVE to boot something via the UEFI way.

Comment 16 Danny Stieben 2011-08-24 04:36:34 UTC
My problem, by the way, is exactly the same as Aaron's. He also has an ASUS MB for AMD Zacacte, which may mean that there's a problem with whatever is in common.

Comment 17 Matthew Garrett 2011-08-24 11:46:39 UTC

Unless your system works with <4GB you have a different problem. Please check that and open a separate bug if necessary.

Comment 18 Dee'Kej 2011-08-24 12:05:29 UTC
Well, as far as I can tell, this 2 options worked for me and my configuration:
(Lenovo T420, Intel Core i7 - SandyBridge, 8 GB DDR3 - underclocked to 1333 MHz, nVidia NVS 4200M Optimus & Intel HD 3000, Intel SSD 320)

1) Using the latest Fedora LiveCD build from here: http://jbwillia.fedorapeople.org/

 - I used "F15-Live-Desk-x86_64-20110808.iso" (It probably won't be there anymore, there'll be some newer, more present build.)

 - I also have to burn the image, using USB LiveCreator (officical or unoffical) doesn't work in Windows - it screwed the image somehow so I would get another 2 problems causing stop of booting. However, using burned image on CD/DVD get it worked and even with those 2 problems booting got over it. [I'm planning to report this behavior of USB LiveCD creator in new thread later.]

(Those 2 problems where specific to my HW, I guess. It was something about Intel DRM platform and something about loading transform for ecb-aes-aesni. I can specify those 2 problems if somebofy wishes.)

2) Using small BFO Fedora ISO image (booting/installing over network).

 - Get it here: http://boot.fedoraproject.org/index

 - If the BFO is getting stucked, be sure to allow Network connection booting ROM (or something with similar name) in BIOS. If this still doesn't help, try this: http://rtjmay.ca/wiki/doku.php?id=bfo

 - I had to use this option because I wanted to use BTRFS file-system with my SSD. However, LiveCD doesn't offer option of selecting BTRFS as a FS. You have to use DVD version, but there are no DVD versions on the (http://jbwillia.fedorapeople.org/) site. I tried to build my own Rawhide, but it led to Kernel-panic. Anyway, using BFO Fedora ISO image

I had this same problem (bug) when I tried to install Fedora 15. I get to the menu and selected to boot LiveCD to install it and it got stucked. Same way as it is mentioned here on bugzilla.
Thewn I tried both of these "solutions" which I mentioned above and it worked for me. I cannot tell if this will work for the others, but I think it's worth the shot, don't you think? :)

//edit: To the first solution led me Southern_Gentlem in Fedora IRC channel.

Hope this will help somebody.


Comment 19 Dee'Kej 2011-08-24 12:15:42 UTC
Oh, I forgot to add some more information:
 - My BIOS is set up to recognize both UEFI and Legacy mode, but UEFI is prior and the installation were through UEFI mode.
 - I also used that BFO image burned on a CD. I couldn't make it work on USB stick no matter what I tried.

Comment 20 Matthew Garrett 2011-08-24 12:30:01 UTC
If you ever get any messages other than (although maybe with different numbers):

Trying to allocate 921 pages for VMLINUZ
[Linux-EFI, setup=0x1011, size=0x398180]
   [Initrd, addr=0x7dd6c000, size=0x1e8faeee]

then you have a different bug. If you see those messages and your computer does something other than reboot just afterwards, you have a different bug.

Comment 21 Dee'Kej 2011-08-24 12:50:43 UTC
2 Matthew:

I got this message:

Trying to allocate 941 pages for VMLINUZ
[Linux-EFI, setup=0x1017, size=0x3ac310]
   [Initrd, adrr=0x79ce1000, size=0x5e1b648]

Then the cursor stopped blinking and whole notebook got stucked. No response to anything, I had to hold power button for 4 seconds to bring it down.

I got this message when I tried to use offical Fedora 15 desktop (x86_x64) release for installation, using both, CD or USB stick.

When I forced in BIOS using Legacy mode, the problem disapperead. (But I also couldn't finish the installation, it stucked after a while of booting on something else.

When I used that updated LiveCD (with 2.6.40 kernel) mentioned above, then there was no sign of the problem anymore. I can boot to Fedora fine.

Comment 22 Matthew Garrett 2011-08-24 13:01:23 UTC

Then you don't have this bug.

Comment 23 Dee'Kej 2011-08-24 13:09:27 UTC
OK, than thx for info...

Comment 24 Dave Jones 2011-10-11 18:53:34 UTC
Does this bug still exist on the f16-beta ?
Given that we don't respin media post-release, changing this from an f14 bug.

Comment 25 Qiang Li 2011-11-04 01:27:07 UTC
It seems that this bug still exist with f16-RC5. I filed a bug report at https://bugzilla.redhat.com/show_bug.cgi?id=751036 yesterday. However, I'm not much sure if it is the same with this bug.

Comment 26 xianzong.huang 2012-03-04 13:45:51 UTC
I also have the same problem !!! Today ,I try to install Fedora-16-x86_64-DVD.iso. I doubt that it is cause by reinstall Fedora system because my original system is also Fedora 16, so I don't know whether you is also similar to me?

I hope my doubt is helpful to you.


Comment 27 xianzong.huang 2012-03-04 13:59:25 UTC
 By the way, I think that it shouldn't is cause by >4G, I also try to remove memory from my computer(is original memory space is 6G, remove 4G). furthermore,my computer is also ASUS .

Comment 28 Dave Jones 2012-03-22 17:11:38 UTC
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

Comment 29 Dave Jones 2012-03-22 17:14:09 UTC
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

Comment 30 Dave Jones 2012-03-22 17:23:22 UTC
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

Comment 31 Patrick Uiterwijk 2012-06-26 14:05:50 UTC
At this moment, F17 (kernel 3.4.2-4.fc17.x86_64) on UEFI works fine with up to 16GB of memory.
As soon as I install more (I tried with 20GB), I get the same problem.

Comment 32 Josh Boyer 2012-09-18 15:15:07 UTC
Has anyone tried the F18 Alpha to see if this is resolved?  Comment #31 seems to imply it was working partially in F17.

Matthew, what actually is the technical problem here?

Comment 33 Matthew Garrett 2012-09-19 14:22:11 UTC
grub-efi was failing to pass the upper 32 bits of the EFI table pointer, so could fail depending on what the implementation did. grub2 appears to have this fixed. It's likely that this is a grub problem rather than a kernel problem.

Comment 34 Josh Boyer 2012-09-19 14:30:32 UTC
Peter, do you want to mark this as closed->nextrelease if grub2 has this fixed given that will be used for EFI going forward?

Comment 35 Dave Jones 2012-10-23 15:34:18 UTC
# Mass update to all open bugs.

Kernel 3.6.2-1.fc16 has just been pushed to updates.
This update is a significant rebase from the previous version.

Please retest with this kernel, and let us know if your problem has been fixed.

In the event that you have upgraded to a newer release and the bug you reported
is still present, please change the version field to the newest release you have
encountered the issue with.  Before doing so, please ensure you are testing the
latest kernel update in that release and attach any new and relevant information
you may have gathered.

If you are not the original bug reporter and you still experience this bug,
please file a new report, as it is possible that you may be seeing a
different problem. 
(Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).

Comment 36 Fedora End Of Life 2013-01-16 15:52:10 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 37 Fedora End Of Life 2013-02-13 18:59:28 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 38 humanshubhatia 2013-03-22 15:50:36 UTC
(In reply to comment #37)
> Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
> no longer maintained, which means that it will not receive any further 
> security or bug fix updates. As a result we are closing this bug.
> If you can reproduce this bug against a currently maintained version of 
> Fedora please feel free to reopen this bug against that version.
> Thank you for reporting this bug and we are sorry it could not be fixed.

Hello everyone I have faced same 


Trying to allocate 941 pages for VMLINUZ
[Linux-EFI, setup=0x1017, size=0x3ac310]
   [Initrd, adrr=0x79ce1000, size=0x5e1b648]

while installing fedora 15 on Asus E35M1-M pro board , I am trying to disable UEFI mode but I dnt find any option in bios to do that
so I have tried below option and now fedora 15 is installed using bootable USB created by fedora LiveUSB creator.

In bios setting select Forced FDD option for your USB drive.


The BIOS feature determines if the USB flash drive should be treated as a floppy disk drive or a hard drive. Of course, it only comes into effect if you have a USB flash drive plugged into your computer's USB port when it boots up.

    When set to Auto, USB flash drives that are less than 530 MB in size are automatically emulated as floppy disk drives. USB flash drives larger than 530 MB in size will be treated like hard disk drives.

    When set to Force FDD , the USB flash drive will emulate a bootable floppy disk drive. This setting is used to force a HDD-formatted drive to boot as a floppy disk (e.g. ZIP drive). This is useful for installing operating systems off bootable USB flash drives.

    When set to Force HDD, the USB flash drive will be treated like a hard disk drive, even if it is smaller than 530 MB in size. The BIOS will not check it for boot files.

If you do not intend to boot off your USB flash drive, it is recommended that you set this BIOS feature to HDD. This may speed up the boot-up sequence by skipping the check for boot files in your USB flash drive.

Comment 39 humanshubhatia 2013-03-22 16:12:01 UTC
Sorry I forgot to mention above test is for both fedora 15 and 16.

Note You need to log in before you can comment on or make changes to this bug.