On Thu, 8 Dec 2022 at 08:15, Peter Robinson <pbrobin...@gmail.com> wrote:
> On Thu, Dec 8, 2022 at 12:42 AM Adam Williamson > <adamw...@fedoraproject.org> 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. > > > > 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've done a few passes, dropping a bunch of older firmware upstream > that are no longer supported in any stable kernel release, also a > bunch of de-dupe and linking of files rather than shipping of multiple > copies of the same firmware. It's improved things a bit, unfortunately > a lot of the dead firmware was tiny compared to say average modern > devices like GPUs or WiFI. > > The problem with a lot of the firmware, and with the new nvidia "open > driver" which shoves a lot of stuff into firmware in order to have an > upstreamable driver apparently the firmwares there are going to be > 30+Mb each, is that they're needed to bring up graphics/network etc to > even just install so I don't know how we can get around this and still > have a device work enough to be able to install the needed firmware > across the network. > > Ideas on how to solve that problem welcome. > > The only ideas I have seen which 'work'* is to ship a minimal set of drivers for some 'chosen' hardware and then you have a bloated kitchen-sink iso which has all the drivers in it. The chosen hardware could be a 'defined' virtual environment which needs a minimal set of firmware, languages, etc. Everything else can be done in the install for getting languages, extra firmware, etc. The kitchen-sink.iso is going to be one which we know is going to be large. Now I have doubled the QA, releng, and product work.. I would say we would focus most of the work on the mini-installer, but we all know that all the work will be in the kitchen-sink one. * for some small definition of 'work' -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
