XPost: linux.debian.devel.release, linux.debian.maint.boot, linux.debian.maint.x
[ 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):
https://www.debian.org/devel/debian-installer/errata
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
side.
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:
https://bugs.debian.org/987441
Cheers,
--
Cyril Brulebois (
kibi@debian.org) <
https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmCFMKoACgkQ/5FK8MKz VSCuXQ/+MI1Yv60ULGrpNtRLMYWijslsOtkr8CoqKKupbl0jC0dTcEOaD4ECJGZq fLjBS0MyvX5hH0Dr5w/kmdJUfmScSS6rC3Xazs/ypZ2rsAHLdZV3dBwib1HJ6b9R dAfVqiRcdTiInzb54LFPxggm8dLw1+Jcx0xb5Fx5aADKvID3v11UIzH716z9WL3x iBgRspXiciLddg220ED2l5te/v2JKkI6F/UsfbMRiln/+bdbsRmy4fcgZA1W45Bk sllBJBsvjgC9UR5KQ99OxtDPj5GCL2rg/xlBSPtwYGHptRFoOR3zjnnYL8ZhMBta NurzkLUkEKsSpcEaeCJTWDnfXuAxDZg79B50GGXcYL0/p5hchwt4ZHcVB5keVmv3 uJPVvbSDV4o8f1Go1V+Sf1qFL6PmsNTjCZd4z/HzAfGyik5LZzyiaAQDyViA1qLr jlDmUY2MPjxMd91ZYQPxrb/MVuGCkst2OgNOVwLGU1+TgnWGKx8wD9rspkKl92Ft rW8nWk7jWzo8Xyskqh75HqHpQxnY5DoETKVxqg/aKGHFNFAD+UwR35G/pHySzNEx 1DsuN58kvFInlvbZex0NYwuZOehuxm3Hi+VYSPxbNqFMZRbyIXkvU+g8z7Z8xlXN Z93Ct0oXBWNh8wfAGrLQYsRPI1rTtVBKjUcqCUowTnt1qOdqh7k=
=OVTI
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
*