On Sat, Feb 26, 2011 at 07:50:37AM -0800, John Reiser wrote:
>
https://bugzilla.redhat.com/show_bug.cgi?id=680542
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:
https://www.redhat.com/archives/anaconda-devel-list/2011-February/msg0010...
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...