Description of problem: This a duplicate of Stratus bz 5670. With RHEL 5.2, the stock compressed initrd is too large for grub to load into the default Stratus Fusion server memory block. We need to load it into a larger contiguous memory block. On March 20th 2008 Rich J wrote: Grub does not handle large initrds very well on ftServers. The root cause is that the ftServer has a memory hole at either 0xe00000 or 0xf00000. There ftESX source tree keeps its patches ...esx_modified/grub/. Be sure to check the Makefile to see which patches are applied. Beverlys the one who knows the details. The general problem is one of loading non-contiguous memory. Version-Release number of selected component (if applicable): GNU grub 0.97, with RHEL 5.2 Build 84 How reproducible: 100% Steps to Reproduce: 1. IPL of RHEL 5.2 Build 84 2. Install xen 3. Reboot Actual results: After grub.conf line to load xen initrd error message: Error 28: Selected item can not fit into memory Expected results: Successful boot of RHEL 5.2 Xen Dom 0
The simplest work around for Fusion is to edit the /boot/grub.conf file to use: modulenounzip initrd.xen.img So grub does not decompress the file in its load buffer. Instead the linux kernel does the job with its ful knowledge of the memory layout. This works fine for developers. However, you have to first boot from a non-xen kernel to edit this file. Think there are many other options, but changing the RHEL stock kernel-*.rpm installation would be hard to justify. first boot being loaded from the inird, it's too late there.
See this upstream grub patch for BIOS memory holes http://savannah.gnu.org/bugs? 18471 with a minor modification wrt loop termination.
Created attachment 302020 [details] PATCH to allow small capability with large initrd Patch derived from upstream http://savannah.gnu.org/bugs?18471 and adapted for grub 0.97.
Created attachment 302021 [details] PATCH to add patch to grub spec file Adds patch to spec file
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
There is no way we're making a change like this in grub without it going in Fedora and being /in a Fedora release/ first.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Reopening and setting to Fedora.
NOTE #1: You probably need to change configure.ac so that the curses line does not set "dynamic", or GRUB will try to load libc.so dynamically, which of course fails. That is, change GRUB_LIBS = -wl, -Bstatic -lncurses -wl,-Bdynamic to be just GRUB_LIBS = -wl, -Bstatic -lncurses (When testing this, I was doing this manually by editing the various resulting Makefiles, but fixing the configure.ac file will fix them all at once.) NOTE #2: Even with this patch applied to GRUB, in order to get Xen to boot on our hardware, I needed to add an "uppermem" command in the grub.conf file in the stanza for the Xen kernel just before kernel /xen.gz-2.6.18-92.el5 I used uppermem 512000 on a system that actually has 8G of memory (which the Xen kernel could see once it booted); I am not sure that the actual value matters.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
In addition to this patch, it may be necessary to set the "uppermem" grub parameter so that it can find higher regions of memory in which to place the final copy of the initrd.
This patch needs more comments in the code at the very least; as it stands, there's no indication whatsoever of any reason to do the read/copy in a loop instead of as one big blob.
Jim - can you take this over and provide comments? I believe we had this slated for RHEL but need this flushed out in Fedora first.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Does anyone know what the progress/status of this is in Fedora 12?
The attached patch was tested in the venue of RHEL 5.5-Beta via bug 464178. Unfortunately, the testing revealed that this patch does not fix the problem. Stratus has an acceptable work-around for this problem. Therefore we are NOT requesting that a fix be developed.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days