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

Bug#989863: debian-installer: Firmware problems in bullseye

Cyril Brulebois <kibi@debian.org> (2021-07-26):
> > ## proposed solution
> > 
> > If others agree, I suggest we add the following somewhere in the
> > installation guide (I don't think we should have a specific warning
> > in the installer; or more specifically it would be way too late to
> > have it be shown localized at this stage; more on that in the second
> > part of my mail). Heavily summarized (to give readers of this bug
> > report an idea, not for direct user consumption!!!): […]
> Given Paul's ACK, I'll turn this into a bug report against the
> installation guide, with a slightly better draft.

This is my next action.

> This was uploaded to unstable, I'm currently waiting for the updated
> metadata to show up in the archive.

That propagated to unstable, resulted in successful testing with a
hacked debian-cd setup (pulling metadata from unstable instead of
testing), so I augmented Paul's unblock hint for firmware-nonfree with a
urgent, and we tested a non-hacked debian-cd setup as well.

> Basically, we extract the relevant bits from the DEP-11 YAML file, and
> generate patterns files that we ship on the firmware-enabled images:
>  - /firmware has firmware-*.deb
>  - /firmware/dep-11 has firmare-*.patterns
> Meanwhile, I've hacked d-i to include those files, built manually
> while the rest was being worked on, so that I could test the runtime
> on my test laptops.

A difference between both (hacked d-i vs. proper debian-cd build) is
where the firmware directory appears, and that was addressed in this
upload (pushed to testing already):

With that fix in place, I discovered another annoyance (this wouldn't
have been a blocker in my book, but that could surprise people):
  https://bugs.debian.org/991587 [cdrom-detect]
  https://bugs.debian.org/991590 [iso-scan, cloned]

which I've just fixed (even if that was only manually tested) in
hw-detect + cdrom-detect; the iso-scan bug report can stay around, I
don't think we need to rush acting on it: the cdrom-detect codepath is
much more likely to be hit as far as I understand it (that's what
happens with ISO images like netinst at least…).

I'll retest “for real” once packages are in the archive, once I've
triggered a new d-i daily build, and once debian-cd has spinned another
firmware-enabled netinst daily build, but besides a possible typo here
or there, I think I'm out of obvious issues that need fixing!

(At least on those two machines I've been re-installing over and over.)

> >  - make sure the relevant information bubbles up to the dep11/Components
> >    files (YAML format, even if the excerpts above were XML);

Done, with unstable, then with testing; everything looks good.

> >  - have debian-cd extract the relevant firmware package←→modalias
> >    mapping from YAML into one or N flat files to be consumed by d-i, for
> >    firmware-enabled images primarily (or exclusively);
> DONE, to be checked once the previous item is complete, and some
> fixups might be required until a full image build behaves like my
> heavily hacked netboot-gtk images (meaning purely from
> debian-installer.git, no debian-cd involved).

Done checking… and fixing (see details above).

> Therefore, I'm tempted to blacklist this firmware file in hw-detect
> (i.e. pretend it was never requested).

Given Salvatore's mention of #969264 & #966218 (thanks!), I've added
this commit:

Besides some builds (hw-detect, cdrom-detect, linux) and some final
tests (then migration to testing), I think we have all the pieces for
D-I Bullseye RC 3.

Whether we need a D-I Bullseye RC 4 (or 5…) for the final 11.0 builds
will depend on bug reports we might received on RC 3 is out, and our
ability (and confidence) with respect to triaging/fixing issues in a
timely manner. If RC 3 doesn't end in seasonal fireworks, I'd be happy
to defer any more code changes to 11.1… Time (and tests) will tell!

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: