Brandon Werner <brandon_c...@fastmail.fm> (2023-02-06): > This makes sense, and both solutions seem like they would work. It > seems like the second solution of keeping the unconditional reload and > testing if the list of files was smaller after the reload would be > easier to implement for Bookworm, but I think you and the rest of the > installer team are better informed to make that decision. :)
Heh. :) > I think assuming the module is working if the list of requested files > is smaller after a reload is a fairly safe bet for network hardware, > but If the installer team implemented either of these solutions, I > could test on a bunch of old and new machines that are available at a > computer club I attend. I unfortunately don't feel like I personally > understand the installer well enough to fix this properly, and any > merge request I would create would be a sad hack. Hopefully many folks > will be testing Alpha 2 of Bookworm as well, to find any problems that > would result from a change like this. To be honest, there were a lot of changes already, and I'm not sure I'll be able to squeeze that in before the next release (to be confirmed but we were aiming at a release next week-end, and we still have to upload d-i and see whether it becomes eligible for testing…). The safest bet at this point would be to release with what's in the archive (basically what you tested), warn against this specific issue (that wouldn't be a regression from previous releases anyway), and mention it should go away in the following release. That's not to say I won't try and get a tentative patch before then… Would you be happy to test a custom netinst that I would build locally (i.e. outside cdimage.debian.org and the official infrastructure)? Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
