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/msg00107.html > 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... -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
