Hi,
On 12/8/22 06:58, Peter Robinson 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.
Ok, I have a couple ideas, but they start with the question, why do we
need fully accelerated graphics for an installer (live image excepted)
that works nearly as well in text mode? That gets the GPU firmware off
the install ramdisk.
Just being a bit more fine grained with the firmware package and only
installing the pieces needed by the running machine shrinks could shrink
the footprint too. Something that looks for kernel firmware load errors,
and installs a package solves the issue of HW that has been dynamically
added after the fact (of course disk/network card firmware would still
be needed by the installer).
Although, just doing per arch firmware shrinks it too. Both the x86 and
arm64 packages are both 177M, and it seems unlikely my arm machine needs
amd microcode, or that my amd needs the dpaa firmware or firmware
specific to some arm SBCs.
So, ideas, but then someone needs to spend the time fixing the problem.
Peter
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-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/kernel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
Anaconda-devel mailing list -- anaconda-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to anaconda-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/anaconda-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
