Red Hat Bugzilla – Bug 441868
[STRATUS F12] grub loading of xen Linux dom0 initrd: Error 28: Selected item can not fit into memory
Last modified: 2013-08-05 23:27:28 EDT
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
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
Version-Release number of selected component (if applicable):
GNU grub 0.97, with RHEL 5.2 Build 84
Steps to Reproduce:
1. IPL of RHEL 5.2 Build 84
2. Install xen
After grub.conf line to load xen initrd error message:
Error 28: Selected item can not fit into memory
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:
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
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
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
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:
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:
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:
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.