Increased Anaconda memory requirements?

Chuck Anderson cra at WPI.EDU
Sat Feb 26 16:17:41 UTC 2011

On Sat, Feb 26, 2011 at 07:50:37AM -0800, John Reiser wrote:
> >
> Much of this is not a bug, it is intentional.  The F14 way of

That bug is that the kernel doesn't display a simple "out of memory" 
error message, instead scrolling a huge traceback off the screen that 
is useless for the user to tell what happened.

>     32MB  isolinux/initrd.img
>    155MB  images/install.img
>     32MB  images/pxeboot/initrd.img  [same as isolinux/initrd.img]
> has become in F15
>    141MB  isolinux/initrd.img
>      0MB  images/install.img  [not present]
>    141MB  images/pxeboot/initrd.img  [same as isolinux/initrd.img]
> [The part that *may* be a space-on-the-platter bug is that the .iso
> might not "de-dup" isolinux/initrd.img and images/pxeboot/initrd.img
> by sharing the extents for those files, which have identical contents.]
> Note that 141MB < (32MB + 155MB) so that the .iso and the total size
> of data fetched for any install can be smaller.  However the main reason
> for the change is for simplicity and correctness in anaconda itself.
> Having a separate "stage2" meant significant complexity and many bugs.

Ok, so why does it need more memory then?  Is it because it has to 
hold the 141MB initrd.img in RAM, and then still have enough RAM to 
hold the decompressed copy as well?

> In this message, Will Woods says that using xz compression instead of
> gzip can reduce the size of initrd.img to about 90MB:
> So that will reduce the size of downloaded data, but the expanded initramfs
> could be almost the same size, requiring more RAM in F15 than F14.

Was the F14 install.img decompressed in RAM?  Or was it accessed by 
on-the-fly decompression as needed?  F14 141MB < F15 151MB so 
something else must be at work here...

More information about the devel mailing list