On Thu, Dec 8, 2022 at 12:42 AM Adam Williamson adamwill@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:
- firmware
- 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.
Peter
Hi,
On 12/8/22 06:58, Peter Robinson wrote:
On Thu, Dec 8, 2022 at 12:42 AM Adam Williamson adamwill@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:
- firmware
- 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@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@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/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
kernel@lists.fedoraproject.org
-
Jeremy Linton -
Peter Robinson