[ 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 <lu...@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 (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
