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. http://fedorapeople.org/groups/anaconda/uefi/ 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:
Created attachment 490472 [details] Screen capture just prior to system reset
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]
At first glance, this appears to be the kernel failing.
*** Bug 691862 has been marked as a duplicate of this bug. ***
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.
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.
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?
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.
Aaron: If your system fails with 2GB then it sounds unrelated to this problem.
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.
Unless your Mac boots when you have less than 4GB of RAM, it's not the same issue.
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.
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.
I can confirm the described behaviour using Fedora 15 on a Lenovo ThinkPad T420 (SandyBridge) in UEFI mode.
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.
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.
Danny, Unless your system works with <4GB you have a different problem. Please check that and open a separate bug if necessary.
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. Dee'Kej
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.
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.
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.
Dee'Kej, Then you don't have this bug.
OK, than thx for info...
Does this bug still exist on the f16-beta ? Given that we don't respin media post-release, changing this from an f14 bug.
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.
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. Thanks
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 .
[mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update.
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.
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?
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.
Peter, do you want to mark this as closed->nextrelease if grub2 has this fixed given that will be used for EFI going forward?
# 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).
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.
(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 error: 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. Solution: In bios setting select Forced FDD option for your USB drive. Explanation: Solution: 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.
Sorry I forgot to mention above test is for both fedora 15 and 16.