(Re-sending with quoting fixed. Evolution's composer has regressed
again.)
On Fri, 2020-12-04 at 22:08 +0100, Holger Wansing wrote:
[...]
> While debugging this, I found that the "radeon" module - responsible
> for this graphics card - is not included in the installer environment.
>
> So, the kernel cannot load it when detecting the graphics card.
> And because of that, the "check-missing-firmware" mechanism does not get
> notified about missing firmware.
>
> Is this intended this way?
On most architectures, the installer can use generic framebuffer
drivers (VGA, EFI, OpenFirware, or simple-framebuffer) as it does not
require high performance. Adding hardware-specific graphics drivers
would probably increase its size and memory requirements significantly.
> (I was stumbling about the radeon module here, but apparently it's the same
> for other graphic cards too, like Intel? I don't find any video-output
> kernel modules at all in d-i environment ...)
>
> Would adding such graphics modules to the installer cause any harm?
> Or could they be added, and get such problems sorted out?
Adding those drivers just to trigger firmware installation seems like a
silly thing to do. It wouldn't fix the issue in radeon or amdgpu,
because they don't have a working fallback for missing firmware.
(Debian carries a patch to make sure they abort probing early if it's
not installed. So this wouldn't cause a regression but it wouldn't log
the usual "missing firmware" message.)
Could this not be done in "discover"? If it can match PCI devices with
a specific class and vendor, that should be enough to decide that
firmware-amd-graphics (AMD, ATI) or firmware-misc-nonfree (Intel,
Nvidia) might be wanted.
Ben.
> Sorry, if I got something completely wrong here ...
--
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.
Attachment:
signature.asc
Description: This is a digitally signed message part