Request: Add firmware selection

[h8d13]

describe the request

Currently in __base_packages__ we always add the full meta linux-firmware and pulls in ~600mb

For VM, minimal server setups this is massive overkill we could extend to allow explicit selection over https://archlinux.org/packages/?sort=&q=linux-firmware using: Full | Minimal | Vendor and vendor being a multi-select

[Torxed]

I do like the idea, not sure what minimal would be (other than, not installing any firmware)? And my only wish is that full is default unless users choose otherwise.

[h8d13]

Yes same pattern as profiles minimal = nothing :D And still would run fine on VM for example !

And yes agree on full default. Going to test this afternoon on fork(c258f01)

[dylanmtaylor]

I feel like firmware selection belongs in an advanced option to not confuse people. I don't know if --advanced is still a thing or not.

[Softer]

Supportive of this. The ~600MB linux-firmware meta is painful for VMs, containers, and minimal server setups, and Arch already split the package specifically to enable this granularity.

One safety angle worth considering: Minimal (and arguably Vendor with a narrow selection) is a footgun on bare metal - user picks Minimal, reboots, no WiFi or GPU firmware, has no idea why. Two complementary safeguards come to mind:

1. Gate Minimal / Vendor behind --advanced, as @dylanmtaylor suggested.
2. Emit an install-time warning on the confirm screen when firmware_type != FULL, so the user sees a yellow "device firmware may fail to load" line before committing.

For (2), there's infrastructure already sitting in PR #4408 - ConfigurationOutput.get_install_warnings() / _render_install_warnings() driven by a list of short yellow strings shown in the confirmation header. It was added for the "no network configuration" case but is generic. I'd like to iterate on that system (more scenarios, richer messages), so plumbing a Minimal/Vendor-firmware warning through it would be a natural fit and wouldn't need a new mechanism.

On UX: an eventual follow-up could auto-populate the Vendor set from lspci -k output (parse Kernel modules: / vendor id lookups against pci.ids) so the user starts with a sane pre-selection and tweaks from there. Not for v1 - just noting so the design of the menu item leaves room for it (e.g., a "Detect" button alongside the multi-select).

[h8d13]

I disagree with gating everything under advanced. Sane default and a yellow warning seems plenty.

Aside from that, stealing that lspci idea :D

[Softer]

You're welcome! :)

[dylanmtaylor]

I approve of everything that reduces footguns for our users, and think that firmware selection is one people might not know the implication of. FWIW, we do already detect running in a hypervisor, so maybe we can default to not installing firmware on a VM?

[h8d13]

I like the auto detection idea proposed by Softer

Best I found was to map IDs directly from

/sys/bus/pci/devices

{
			'0x10de': ('NVIDIA',),
			'0x8086': ('INTEL',),
			'0x10ec': ('REALTEK',),
			'0x14e4': ('BROADCOM',),
			'0x168c': ('ATHEROS',),
			'0x0cf3': ('ATHEROS',),
			'0x14c3': ('MEDIATEK',),
			'0x17cb': ('QCOM',),
		}

Then just some special handling for the radeon vs amdgpu (same code 0x1002)

• VM just gets minimal default