[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