December 2022 - kernel - Fedora Mailing-Lists

Re: Small rant: installer environment size

by Richard W.M. Jones

On Wed, Dec 07, 2022 at 04:42:05PM -0800, Adam Williamson wrote: > 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? You only need network / wifi firmware blobs (although I'm sure they are in themselves large) and then you can fetch anything else needed for the hardware including graphics, right? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html

5 months, 3 weeks

2
2
0 / 0

Re: Small rant: installer environment size

by Peter Robinson

On Thu, Dec 8, 2022 at 4:56 PM Adam Williamson <adamwill(a)fedoraproject.org> wrote: > > On Thu, 2022-12-08 at 12:58 +0000, Peter Robinson wrote: > > > > 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. > > Sorry if this is way off, but - do we need the GPU firmwares to run a > graphical install on the fallback path, just using the framebuffer set > up by the firmware? How crazy would it be to just do that - ship the > installer env with no GPU firmware? That has crossed my mind, and with simpledrm that may be more straight forward now, but TBH it's not something I am skilled enough to deal with, nor have the resources to test, or actually care enough about, but the big GPU firmwares are now all split out so that should be much more straightforward for someone with the resources to investigate.

5 months, 3 weeks

1
0
0 / 0

Re: Small rant: installer environment size

by Gerd Hoffmann

On Thu, Dec 08, 2022 at 11:49:16AM -0800, Adam Williamson wrote: > On Thu, 2022-12-08 at 20:23 +0100, drago01 wrote: > > The problem I see here is not the presence of the firmware on the > > image, > > but the fact that it seems to be loaded into memory despite not being > > used. > > This is the direction Daniel was thinking down. I'm waiting for someone > with more expertise to reply, but I suspect the reply is going to be > along the lines of "yes, we *can* do that, but it's somewhat tricky > work that involves thinking about lots of paths that aren't obvious, > and somebody would need to dedicate their time to working on that". Split install.img into install.img + firmware.img? I think we already have support for multiple images (I see requests for updates.img when watching httpd logs while doing network installs), so the split should be easy. The somewhat more tricky part is probably to figure whenever we need the firmware or not. take care, Gerd

5 months, 3 weeks

1
0
0 / 0

✅ PASS (3/297 SKIPPED): Test report for 6.0.12-300.fc37 (fedora-37)

by cki-project＠redhat.com

Hi, we tested your kernel and here are the results: Overall result: PASSED Merge: OK Compile: OK Test: OK Tested-by: CKI Project <cki-project(a)redhat.com> Kernel information: Brew / Koji Task ID: 95095340 You can find all the details about the test run at https://datawarehouse.cki-project.org/kcidb/checkouts/62626 One or more kernel tests failed: We also see the following known issues which are not related to your changes: Issue: Storage block - storage fio numa: Performance comparison: min:40535 * 1.15 < max:81259 URL: https://bugzilla.redhat.com/show_bug.cgi?id=2032094 Affected tests: x86_64 - Storage - block - storage fio numa Issue: NFS Connectathon: SELinux prevents rpcbind URL: https://gitlab.com/redhat/centos-stream/tests/kernel/kernel-tests/-/issue... Affected tests: aarch64 - NFS Connectathon s390x - NFS Connectathon x86_64 - NFS Connectathon Issue: avc: denied { sys_admin } for pid=674004 comm="systemd-gpt-aut" capability=21 scontext=system_u:system_r:systemd_gpt_generator_t:s0 tcontext=system_u:system_r:systemd_gpt_generator_t:s0 tclass=capability permissive=0 URL: https://bugzilla.redhat.com/show_bug.cgi?id=2083900 Affected tests: aarch64 - Networking MACsec: sanity aarch64 - Networking cki netfilter test aarch64 - ALSA PCM loopback test aarch64 - Storage - SCSI VPD ppc64le - Networking MACsec: sanity ppc64le - Networking cki netfilter test ppc64le - ALSA PCM loopback test x86_64 - Networking MACsec: sanity x86_64 - Networking cki netfilter test x86_64 - ALSA PCM loopback test x86_64 - Storage - SCSI VPD Issue: Networking MACsec: sanity: Cannot find device "dummy0" URL: https://gitlab.com/redhat/centos-stream/tests/kernel/kernel-tests/-/issue... Affected tests: aarch64 - Networking MACsec: sanity ppc64le - Networking MACsec: sanity x86_64 - Networking MACsec: sanity Issue: xfstests - _check_xfs_filesystem: filesystem on /dev/nvme0n1p4 is inconsistent (r) URL: https://bugzilla.redhat.com/show_bug.cgi?id=1989409 Affected tests: aarch64 - xfstests - btrfs If you find a failure unrelated to your changes, please ask the test maintainer to review it. This will prevent the failures from being incorrectly reported in the future. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________

5 months, 3 weeks

1
0
0 / 0

Re: Small rant: installer environment size

by drago01

On Thursday, December 8, 2022, Adam Williamson <adamwill(a)fedoraproject.org> wrote: > On Thu, 2022-12-08 at 12:58 +0000, Peter Robinson wrote: > > > > 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. > > Sorry if this is way off, but - do we need the GPU firmwares to run a > graphical install on the fallback path, just using the framebuffer set > up by the firmware? How crazy would it be to just do that - ship the > installer env with no GPU firmware? That would be very crazy, as you will have a degraded user experience (laggy UI, wrong resolution, ...) to save a couple of megabytes that are a non issue for today's hardware. > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > _______________________________________________ > desktop mailing list -- desktop(a)lists.fedoraproject.org > To unsubscribe send an email to desktop-leave(a)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/desktop@ > lists.fedoraproject.org > Do not reply to spam, report it: https://pagure.io/fedora- > infrastructure/new_issue >

5 months, 3 weeks

2
2
0 / 0

Re: Small rant: installer environment size

by Daniel P. Berrangé

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. snip > 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. Is there something that can be done to optimize the RAM usage, in spite of the large installer env size ? If we're installing off DVD media, it shouldn't be required to pull all of the content into RAM, since it can be fetched on demand from the media. IOW, 99% of the firmware never need leave the ISO, so shouldn't matter if firmware is GBs in size [1] if we never load it off the media. Same for languages, only the one we actually want to use should ever get into RAM. If we're installing off a network source, we need to pull content into RAM, but that doesn't mean we should pull everything in at once upfront. Is it possible to delay pulling in non-NIC firmware until we have a NIC configured, and just rely on the basic generic framebuffer setup by UEFI/BIOS until we get far enugh to pull in video card firmware ? For localization, is it possible to split the localization into per-language bundles, and delay loading off the network until we know what language we want to load, instead of pre-loading all languages ? With regards, Daniel [1] Yes, I know it matters for user media download size in reality -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

5 months, 3 weeks

1
0
0 / 0

[OS-BUILD PATCHv3 0/2] redhat/configs: aarch64: reorganize tegra configs to common dir

by Mark Salter (via Email Bridge)

From: Mark Salter on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2172 RHEL needs support for tegra194 and tegra234 SoCs, so move some configs from redhat/configs/fedora to redhat/configs/common where they can be shared. Signed-off-by: Mark Salter <msalter(a)redhat.com> --- redhat/configs/ark/generic/arm/aarch64/CONFIG_ARCH_TEGRA_194_SOC | 1 - redhat/configs/ark/generic/arm/aarch64/CONFIG_ARCH_TEGRA_234_SOC | 1 - redhat/configs/ark/generic/arm/aarch64/CONFIG_ARM_TEGRA186_CPUFREQ | 1 + redhat/configs/ark/generic/arm/aarch64/CONFIG_TEGRA_IVC | 1 - redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARCH_TEGRA_194_SOC => redhat/configs/common/generic/arm/aarch64/CONFIG_ARCH_TEGRA_194_SOC | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARCH_TEGRA_234_SOC => redhat/configs/common/generic/arm/aarch64/CONFIG_ARCH_TEGRA_234_SOC | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM_TEGRA194_CPUFREQ => redhat/configs/common/generic/arm/aarch64/CONFIG_ARM_TEGRA194_CPUFREQ | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_GPIO_TEGRA186 => redhat/configs/common/generic/arm/aarch64/CONFIG_GPIO_TEGRA186 | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_PCIE_TEGRA194_HOST => redhat/configs/common/generic/arm/aarch64/CONFIG_PCIE_TEGRA194_HOST | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_PHY_TEGRA194_P2U => redhat/configs/common/generic/arm/aarch64/CONFIG_PHY_TEGRA194_P2U | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_SERIAL_TEGRA_TCU => redhat/configs/common/generic/arm/aarch64/CONFIG_SERIAL_TEGRA_TCU | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_SERIAL_TEGRA_TCU_CONSOLE => redhat/configs/common/generic/arm/aarch64/CONFIG_SERIAL_TEGRA_TCU_CONSOLE | 0 redhat/configs/common/generic/arm/aarch64/CONFIG_SOC_TEGRA_CBB | 1 + redhat/configs/fedora/generic/arm/aarch64/CONFIG_TEGRA_BPMP_THERMAL => redhat/configs/common/generic/arm/aarch64/CONFIG_TEGRA_BPMP_THERMAL | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_TEGRA_HSP_MBOX => redhat/configs/common/generic/arm/aarch64/CONFIG_TEGRA_HSP_MBOX | 0 redhat/configs/fedora/generic/arm/CONFIG_I2C_TEGRA_BPMP => redhat/configs/common/generic/arm/CONFIG_I2C_TEGRA_BPMP | 0 redhat/configs/ark/generic/arm/aarch64/CONFIG_TEGRA_HSP_MBOX => redhat/configs/common/generic/arm/CONFIG_TEGRA_HSP_MBOX | 0 redhat/configs/fedora/generic/arm/CONFIG_TEGRA_IVC => redhat/configs/common/generic/arm/CONFIG_TEGRA_IVC | 0 redhat/configs/fedora/generic/arm/CONFIG_ARM_TEGRA194_CPUFREQ | 1 - redhat/configs/fedora/generic/arm/CONFIG_TEGRA_HSP_MBOX | 1 - redhat/configs/pending-fedora/generic/CONFIG_SOC_TEGRA_CBB | 13 ---------- 21 files changed, 2 insertions(+), 18 deletions(-)

5 months, 3 weeks

2
3
0 / 0

Re: Small rant: installer environment size

by Florian Weimer

* Adam Williamson: > 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) Isn't the compression block-based? I think it would be interesting to measure the image size with the file removed. For the non-live installer, we can *significantly* cut down its size, without degrading localization of the installer itself. > 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*? It has all the targets in it. As it's for JIT, we'd only need one target. Thanks, Florian

5 months, 3 weeks

1
0
0 / 0

[OS-BUILD PATCH] redhat/configs: move SOC_TEGRA_CBB from pending to common

by Mark Salter (via Email Bridge)

From: Mark Salter <msalter(a)redhat.com> redhat/configs: move SOC_TEGRA_CBB from pending to common Move CONFIG_SOC_TEGRA_CBB out of pending-fedora into common so RHEL can use it. Signed-off-by: Mark Salter <msalter(a)redhat.com> diff --git a/redhat/configs/pending-fedora/generic/CONFIG_SOC_TEGRA_CBB b/redhat/configs/common/generic/arm/aarch64/CONFIG_SOC_TEGRA_CBB rename from redhat/configs/pending-fedora/generic/CONFIG_SOC_TEGRA_CBB rename to redhat/configs/common/generic/arm/aarch64/CONFIG_SOC_TEGRA_CBB index blahblah..blahblah 100644 --- a/redhat/configs/pending-fedora/generic/CONFIG_SOC_TEGRA_CBB +++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_SOC_TEGRA_CBB -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2177

5 months, 3 weeks

3
5
0 / 0

[OS-BUILD PATCH] redhat/configs: aarhc64: clean up some erratum configs

by Mark Salter (via Email Bridge)

From: Mark Salter <msalter(a)redhat.com> redhat/configs: aarhc64: clean up some erratum configs There were a number of misplaced aarch64 erratum configs in redhat/configs/ark/generic. RHEL and Fedora both enable all of them so delete the ark ones and make the fedora ones common. Signed-off-by: Mark Salter <msalter(a)redhat.com> diff --git a/redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_1902691 b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_1902691 rename from redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_1902691 rename to redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_1902691 index blahblah..blahblah 100644 --- a/redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_1902691 +++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_1902691 diff --git a/redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2038923 b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2038923 rename from redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2038923 rename to redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2038923 index blahblah..blahblah 100644 --- a/redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2038923 +++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2038923 diff --git a/redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2064142 b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2064142 rename from redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2064142 rename to redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2064142 index blahblah..blahblah 100644 --- a/redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2064142 +++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2064142 diff --git a/redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2441009 b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2441009 rename from redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2441009 rename to redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2441009 index blahblah..blahblah 100644 --- a/redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2441009 +++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2441009 diff --git a/redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2457168 b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2457168 rename from redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2457168 rename to redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2457168 index blahblah..blahblah 100644 --- a/redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2457168 +++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2457168 diff --git a/redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2658417 b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2658417 rename from redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2658417 rename to redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2658417 index blahblah..blahblah 100644 --- a/redhat/configs/ark/generic/CONFIG_ARM64_ERRATUM_2658417 +++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2658417 diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_1902691 b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_1902691 deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_1902691 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_ARM64_ERRATUM_1902691=y diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2038923 b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2038923 deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2038923 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_ARM64_ERRATUM_2038923=y diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2064142 b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2064142 deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2064142 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_ARM64_ERRATUM_2064142=y diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2441009 b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2441009 deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2441009 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_ARM64_ERRATUM_2441009=y diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2457168 b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2457168 deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2457168 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_ARM64_ERRATUM_2457168=y diff --git a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2658417 b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2658417 deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM64_ERRATUM_2658417 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_ARM64_ERRATUM_2658417=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2176

5 months, 4 weeks

2
1
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel December 2022