[ipxe-devel] Loading large initrd images without iPXE rebooting or error 2a818006
Michael Brown
mbrown at fensystems.co.uk
Fri Mar 30 21:17:52 UTC 2012
On Friday 30 Mar 2012 21:59:01 Alex Davies wrote:
> I am building a large initrd image (based on a Live CD) [i.e. we are not
> having a small initrd+NFS/SAN root device]. It seems that if this initrd
> gets larger than about 800M we see some interesting behaviour:
>
> - If the ipxe script is kernel/initrd/boot, the server reboots
> immediately and before the kernel has a chance to execute
> - If the ipxe script is initd/chain, we get error
> http://ipxe.org/err/2a818006
>
> Digging into this shows (I think) that iPXE is hitting the
> function bzimage_exec in i386/image/bzimage.c.
You'll need enough RAM for two copies of the initrd (plus the kernel, plus
some headroom). iPXE doesn't use the initrd in-situ; it concatenates all of
the downloaded initrds into a single contiguous image to be passed to the
kernel.
There was a fix a few days ago which enforced a check of the overall amount of
memory used by downloaded images. Prior to this, attempting to download more
images than could fit in memory would result in undefined behaviour.
> We are using undionly.kpxe,
> chain loaded from a legacy TFTP server and with a embedded configuration
> (make bin/undionly.kpxe EMBED=xx.ipxe). I can see that this is using the 32
> bit arch libraries; it it possible to build a 64 bit version of
> unidonly.kpxe that can address all the system memory?
No; there's no support for PAE or long mode in the 32-bit (pcbios) builds of
iPXE.
It would be possible to rewrite bzimage.c so that it rearranged the initrds
in-situ, in order to avoid the double RAM requirement. However, it would be
awkward, since the natural order of the initrds in memory will be the reverse
of what needs to be passed to the kernel.
Michael
More information about the ipxe-devel
mailing list