On Thu, 8 Dec 2022 at 08:15, Peter Robinson <pbrobinson@xxxxxxxxx> wrote:
On Thu, Dec 8, 2022 at 12:42 AM Adam Williamson
<adamwill@xxxxxxxxxxxxxxxxx> 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@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
