On Wed, Dec 07, 2022 at 04:42:05PM -0800, Adam Williamson wrote: > Hi folks! Today I woke up and found > https://bugzilla.redhat.com/show_bug.cgi?id=2151495 , which diverted me > down a bit of an "installer environment size" rabbit hole. > > As of today, with that new dep in webkitgtk, Rawhide's network install > images are 703M in size. Here's a potted history of network install > image sizes: > > Fedora Core 8: 103.2M (boot.iso 9.2M + stage2.img 94M) > Fedora 13: 208M > Fedora 17: 162M (last "old UI") > Fedora 18: 294M (first "new UI") > Fedora 23: 415M > Fedora 28: 583M > Fedora 33: 686M > Fedora 37: 665M > Fedora Rawhide: 703M > > The installer does not really do much more in Rawhide than it did in > FC8. Even after the UI rewrite in F18, we were only at 294M. Now the > image is well over 2x as big and does...basically the same. I take issue with this. It is not accurate to say that the installer now does not do much more than it did for Fedora Core 8. There is more to the installer than the UI. Broadly speaking, a lot of the growth came from converging the runtime environment for the installer with the installed system. In Fedora Core 8 and previous releases, the "installer environment" was a unique and stripped down install. This was frustrating because it was effectively maintaining a small mini distro for the purposes of running the distro installer. > Why does this matter? Well, the images being large is moderately > annoying in itself just in terms of transfer times and so on. But more > importantly, AIUI at least, the entire installer environment is loaded > into RAM at startup - it kinda has to be, we don't have anywhere else > to put it. The bigger it is, the more RAM you need to install Fedora. > The size of the installer environment (for which the size of the > network install image is more or less a perfect proxy) is one of the > two key factors in this, the other being how much RAM DNF uses during > package install. > > So, I did a bit of poking about into *what* is taking up all that > space. There's a variety of answers, but there's two major culprits: > > 1. firmware > 2. yelp (which pulls in webkitgtk and its deps) > > I've been using du and baobab (the GNOME visual disk usage analyzer, > which is great) to examine the filesystems, but I ran a couple of test > builds to confirm these suspects, especially after the impact of > compression (it's hard to check the *compressed* size of things in the > installer environment directly). > > I did a scratch build of lorax which does not pull in firmware > packages, and had openQA build a netinst using that lorax. It came out > at 489M - 214M smaller than current netinsts, a size we last managed in > Fedora 26. I did a scratch build of anaconda with its requirement of > yelp dropped (which would break help pages), and built a netinst with > that; it came out at 662M - 41M smaller than current images. I haven't > run a combined test yet, but it ought to come out around 448M, around > the size of Fedora 24. > > Even then we'd still be about 50% larger than the Fedora 18 image, for > not really any added functionality. > > I've moaned about the sheer amount and size of firmware blobs in other > forums before, but 214M compressed is *really* obnoxious. We must be > able to do something to clean this up (further than it's already > cleaned up - this is *after* we dropped low-hanging fruit like > enterprise switch 'firmwares' and garbage like that; most of the > remaining size seems to be huge amounts of probably-very-similar > firmware files for AMD graphics adapters and Intel wireless adapters). > I know some folks were trying to work on this (there was talk that we > could drop quite a lot of files that would only be loaded by older > kernels no longer in Fedora); any news on how far along that effort is? I think some curation on firmware could happen. I think probinson@ mentions it later in this thread. If there were a way to identify the firmware necessary for the installer environment that could probably simplify things. > Other obvious things that take up a lot of space: > > 1. /usr/lib/locale/locale-archive , from glibc-all-langpacks - this is > 224M uncompressed. A quick test just compressing the file with xz on my > system shows it compresses to around 11M, though, so that's probably > all it adds up to after compression (the image is an xz-compressed > squashfs) Can this be installed compressed? I'm not sure it can. I guess a more important question is whether or not this file is used at install time. That I do not know. > 2. /usr/lib64/libLLVM-15.so, which is 114M on its own, compresses to > 23M. We are, I think, basically stuck with this for mesa-dri-drivers , > but does it have to be so *big*? If mesa-dri-drivers is not required for installation, it could be removed from the installer environment. > 3. libicudata.so.71.1 - 30.4M, compresses to 7M. This is in the > webkitgtk dep chain but seems to still be pulled in without it, not > sure what else is requiring it. Not sure. On my system I see 175 things in /usr/bin that report libicudata when you ldd the file. Mostly desktop related things. But then there's stuff like zenity which was historically included in the installer environment for people writing interactive %post scripts in kickstart (please don't do this). > 4. /usr/share/locale - 112M in total (uncompressed, not sure how much > compressed) of translated strings from a ton of packages. No idea how > many of these are really *needed* in the installer environment. We can > maybe come up with a way to have lorax strip some, if we can come up > with a viable way to figure out which. Obviously-fairly-large ones are > from gnupg2 and libgweather4. I do recall we have some logic somewhere > to decide which languages have a certain level of translation in > anaconda; perhaps we could only include the strings for these > languages? On that note, /usr/share/doc, /usr/share/man, and /usr/share/info could be removed from the installer image if they are present. That likely won't free a whole lot of space, but it's not nothing. Thanks, -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
