You are not logged in.
Hello, today the linux-firmware package was updated and I noticed that nvidia firmware was Split into a different optional package. Now i get "WARNING: Possibly missing firmware for module: 'nouveau'" message.
The corresponding change does not describe why this was done, it just say that nvidia firmware took 100 MB https://gitlab.archlinux.org/archlinux/ … 104709623a
Can someone explain the following questions in more detail:
1) The purpose of this change is to save 100 Mb or there are other reasons for it ?
2) Do I need the linux-firmware-nvidia package for nvidia-dkms or nvidia-open-dkms ? At the moment I don’t see that it would specified as dependency for other packages.
3) Will this package be specified as additional dependency for mesa ?
Thanks.
Last edited by node (2025-06-17 14:53:30)
Offline
The MR has more rationale: https://gitlab.archlinux.org/archlinux/ … requests/3
Offline
The MR has more rationale: https://gitlab.archlinux.org/archlinux/ … requests/3
sorry, but "Firmware for NVIDIA devices now accounts for almost a third of the size of the main firmware package." doesn’t tell me much and doesn't answer on my questions.
Last edited by node (2025-06-15 20:14:12)
Offline
The package `linux-firmware` is very big and splitting big parts from it is a good idea I think. I don't have any NVIDIA unit in any of my computers but still I am waiting for it to be installed and hosting it in my systems for years; this shouldn't be optimal. BTW, isn't there a solution to identify the hardware and install necessary firmware afterwards?
Offline
BTW, isn't there a solution to identify the hardware and install necessary firmware afterwards?
AFAIK, there is no such tool for Arch. In the case of linux-firmware-nvidia, it could be very simply solved by adding it as a dependency to nvidia-open, nvidia-open-lts, nvidia-open-dkms, nvidia, nvidia-lts, nvidia-dkms and vulkan-nouveau.
Offline
The package `linux-firmware` is very big and splitting big parts from it is a good idea
Saving horribly giant 100 MB doesn’t seem like a big achievement to me. At the moment I’m forced to have three different electron versions instead of one, this could save 600 MB.
AFAIK, there is no such tool for Arch. In the case of linux-firmware-nvidia, it could be very simply solved by adding it as a dependency to nvidia-open, nvidia-open-lts, nvidia-open-dkms, nvidia, nvidia-lts, nvidia-dkms and vulkan-nouveau.
Well apparently linux-firmware-nvidia is not needed for nvidia-dkms, I had to figure it out after rebooting the system, although I would prefer to know about it before shutting down the computer.
If I understand correctly, then linux-firmware-nvidia would need that nouveau/ nova in principle could work, not only for NVK work.
Last edited by node (2025-06-16 08:35:42)
Offline
Saving horribly giant 100 MB doesn’t seem like a big achievement to me. At the moment I’m forced to have three different electron versions instead of one, this could save 600 MB.
FWIW the firmware files are copied into each and every initramfs, for people with a small EFI system partition the space saving is significant.
Edit: as corrected by Scimmia, I wanted to talk about the fallback initramfs, in particular with multiple kernels installed.
Last edited by Erus_Iluvatar (2025-06-17 06:03:46)
I'm french, don't mind my mistakes in english.
Offline
node wrote:Saving horribly giant 100 MB doesn’t seem like a big achievement to me. At the moment I’m forced to have three different electron versions instead of one, this could save 600 MB.
FWIW the firmware files are copied into each and every initramfs, for people with a small EFI system partition the space saving is significant.
Not true at all. They would only be in every one if you're using the kms hook (or modules array directly) and are using one of the relevant modules. In those cases, you need the package anyway, so no change at all. Otherwise using the kms hook would put it in the fallback only, and there are plenty of ways to mitigate that. Not using the kms hook for one.
Offline
FWIW the firmware files are copied into each and every initramfs, for people with a small EFI system partition the space saving is significant.
Standard efi partition now has a size of 500 Mib That’s more than enough to store any efi files there, I don’t know why keep mkinitcpio there. this is not a /boot partition to store them here .
Last edited by node (2025-06-16 14:09:31)
Offline
I don’t know why keep mkinitcpio there. this is not a /boot partition to store them here .
Maybe not on your system, but that is a very common setup.
Offline
Maybe not on your system, but that is a very common setup.
it’s weird, I’ve seen /boot use a separate partition or boot in / (the most common solution), but never see anything like boot in /efi
Offline
Who said anything about /efi?
Offline
Who said anything about /efi?
"for people with a small EFI system partition the space saving is significant."
In any case it has nothing to do with the questions I asked, let’s stick to the topic
Last edited by node (2025-06-16 14:34:10)
Offline
Right, that's the partition, it has nothing to do with an /efi mount point.
Offline
Right, that's the partition, it has nothing to do with an /efi mount point.
In any case it has nothing to do with the questions I asked, let’s stick to the topic
Offline
Well, now linux-firmware a metapackage, which requires as dependencies all other firmware packages that were previously contained in it
https://gitlab.archlinux.org/archlinux/ … f5530cbdbc
Offline
Then many users will remove linux-firmware and replace it with only the parts they need.
For my desktop f.e I'll need amdgpu firmware (proc + videocard) and whichever one holds iwlwifi firmware (guess that will be in the intel one) .
Looks like an improvement to me.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Is it the intended behavior to have all of the firmware packages installed with linux-firmware?
pacman -Syu
:: Synchronizing package databases...
router is up to date
core-testing 7.9 KiB 19.3 KiB/s 00:00 [############################################] 100%
extra-testing 7.8 MiB 6.36 MiB/s 00:01 [############################################] 100%
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
Packages (22) amd-ucode-20250613.12fe085f-5 bind-9.20.10-1 dbus-broker-37-2 dbus-broker-units-37-2 graphviz-13.0.1-1
iana-etc-20250612-1 libnghttp2-1.66.0-1 libxml2-2.14.4-1 linux-firmware-20250613.12fe085f-5
linux-firmware-amdgpu-20250613.12fe085f-5 linux-firmware-atheros-20250613.12fe085f-5
linux-firmware-broadcom-20250613.12fe085f-5 linux-firmware-intel-20250613.12fe085f-5
linux-firmware-mediatek-20250613.12fe085f-5 linux-firmware-nvidia-20250613.12fe085f-5
linux-firmware-other-20250613.12fe085f-5 linux-firmware-radeon-20250613.12fe085f-5
linux-firmware-realtek-20250613.12fe085f-5 linux-firmware-whence-20250613.12fe085f-5
python-certifi-2025.06.15-1 xorg-server-21.1.18-1 xorg-server-common-21.1.18-1
Total Download Size: 345.39 MiB
Total Installed Size: 377.66 MiB
Net Upgrade Size: 66.76 MiB
Last edited by graysky (2025-06-18 21:26:38)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Offline
the idea is to not install the metapackage anymore, but only the individual packages depending on your hardware (for me that is amd-ucode, linux-firmware-amdgpu and linux-firmware-realtek)
Offline
I tried to upgrade linux-firmware to the one in testing and it was complaining about file conflicts with some of the nvidia firmware files. I had to remove linux-firmware first and then reinstall from testing. I am guessing it tried to install linux-firmware-nvidia while the old linux-firmware was still installed? Is this to be expected for this upgrade?
Offline
Is this to be expected for this upgrade?
No. It sounds like you might have linux-firmware in IgnorePkg or something?
Offline
I have no packages listed in IgnorePkg. Even if I did, wouldn't that mean it wouldn't have tried to update it in the first place? It was marked for upgrade in the confirmation list.
I believe it was complaining about the `ad103`, etc. folders
Offline
Ah, I see. I guess there will be a NEWS entry for it. Otherwise, all of the packages will be pulled down.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
OK, it appears it *is* expected if you skipped versions.
Offline