[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Tentative summary of the AMD/ATI/NVidia issue (was: Finding a tentative bullseye release date)

[ cc+=-x@ ]

Hi Lucas,

Thanks for your summary, I'm not sure about every single detail, but it
seems to be a good basis for discussion. I might point to it from our
errata page (I didn't have a specific bug report when I wrote the most
recent entries):

Lucas Nussbaum <lucas@debian.org> (2021-04-24):
> Disclaimer: I read the "[AMD/ATI graphics] Missing firmware not declared
> / kernel modules not included in initrd" thread. While my understanding
> of the issue is not complete, I'm trying to summarize what I undertood
> so far in the hope that others can jump in and fill in the blanks or
> correct me.
> There are graphic cards whose in-kernel drivers require non-free
> firmwares. Typically AMD/ATI cards that require firmware-amd-graphics[1]
> to work with the radeon, amdgpu and r128 drivers; or NVIDIA cards that
> require firmware-misc-nonfree to work with the nouveau driver.
> [1] https://packages.debian.org/unstable/firmware-amd-graphics
> With Debian 10, the behaviour was that the installation succeeded
> without installing firmware-* packages, and then, and the first boot, X
> would start in a "degraded" mode (using, for example, the vesa driver).
> The user would generally then install the firmware package (or, in the
> case of NVidia, switch to the proprietary drivers).
> With Debian 11, the installation also succeeds, but then at first boot,
> X fails to work correctly. What happens here is unclear: reports vary
> between "black screen" (but does the system works if the user switches to
> console mode?), "garbled screen", "system crash" (but maybe the user did
> not notice that the system works in console mode).

What I briefly alluded to on IRC (#debian-boot) was something that would
be an A)+B) approach. C) doesn't seem reasonable to me.

> It looks like the three open paths for resolution are:
> A) understand and restore the behaviour from Debian 10, that is, get X
> to work in a degraded mode after installation. How it worked with Debian
> 10 (and why it doesn't with Debian 11) is unknown.

Without checking with X people beforehand, what I imagined we could do
when running an installer that doesn't have non-free enabled could be
adding some X conf snippet to force a generic driver (a while ago, that
would have been fbdev/vesa, not sure about the current state, depending
on whether modesetting kicked in, etc.), to ensure one isn't left with a
black screen. This might involve setting kernel parameters instead or in
addition to that…

It could be accompanied by an information note in the installer (to make
sure the user knows about this degraded mode, and about ways to improve
the situation post-installation) and/or in the installation guide and/or
in the wiki.

https://xorg-team.pages.debian.net/xorg/ doesn't seem like it has had
many updates lately, but it might not be the worst place to have a “how
to undo the snippet things and get the real deal once firmwares are
installed”, or maybe “how to deal with firmwares” in general… that d-i
and the installation guide could point to.

(x.debian.net still exists and redirects there, so that's not a
complicated URL to remember/type if it gets displayed in a note.)

That being said, if an information note gets added in d-i, its content
needs to be checked with the X team, reviewed by the team whose name
has escaped me, and then translated into as many languages as possible.
It could be possible to cheat the translation status to alleviate this
requirement, and contemplate updating the relevant package in 11.1, but
I'm not sure we've ever done that.

On the other hand, docs on x.debian.net aren't translated, so maybe the
installation guide would be a better place in the end…

> B) In the installer, detect that firmware-amd-graphics or
> firmware-misc-nonfree should be installed, and either install it (?),
> or redirect the user to the unofficial installer that includes them.

That could be achieved for an installer that has non-free enabled,
provided the proposal by Ben gets implemented, then consumed on the d-i

> C) Do nothing and document this in the release notes

As said above, I strongly recommend against this.

> The main blocking factor for progress seems to be that not enough
> people have both hardware that is not supported (laptops/desktops with
> AMD or NVidia graphic cards), and the knowledge and time to
> investigate this.

For the avoidance of doubt: I'm fine with working on these topics (and
getting my hands on relevant hardware is in progress), along with other
issues that seem to be potential blockers for the release. I just don't
expect everyone to agree on a (possibly dual) solution immediately, and
the relevant contributions (code, doc, translations) to be available in
the very next few days. Hence my reaction to a very close “tentative
release date” (fewer than 4 weeks).

For completeness, we also have this now:

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply to: