On 2021-07-08 16:59:42, Justin B Rye wrote: > Paul Gevers wrote: > >> We could replace this with "See the instructions in the DSA (also in > >> the intel-microcode README.Debian)". Mind you, it would be nice if > >> that README started with "TLDR: boot with dis_ucode_ldr"! > > > > To get this straight, you only propose to replace the piece between > > brackets (inclusive) with that right? I think it's worth saying "you can > > recover". > > Yes, though I was vaguely thinking that in the process of adding > markup we might reorganise the links, since we don't need full URLs in > the text. Something like > > <section id="intel-microcode"> > <!-- buster to bullseye --> > <title>Intel CPU microcode issues</title> > <para> > The <systemitem role="package">intel-microcode</systemitem> package > currently in bullseye and buster-security (see <ulink > url="https://www.debian.org/security/2021/dsa-4934";>DSA-4934-1</ulink>) > is known to contain two significant bugs. For some CoffeeLake CPUs this > update <ulink > > url="https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/56";>may > break network interfaces</ulink> that use <systemitem > role="package">firmware-iwlwifi</systemitem>, and for some Skylake > R0/D0 CPUs on systems using a very outdated firmware/BIOS, <ulink > > url="https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31";>the > system may hang on boot</ulink>. > </para> > <para> > If you held back the update from DSA-4934-1 due to either of these > issues, or do not have the security archive enabled, be aware that > upgrading to the <systemitem > role="package">intel-microcode</systemitem> package in bullseye may > cause your system to hang on boot or break iwlwifi. In that case, you > can recover by disabling microcode loading on boot; see the > instructions in the DSA, which are also in the <systemitem > role="package">intel-microcode</systemitem> > <filename>README.Debian</filename>. > </para> > </section> > > (When it says "currently in bullseye and buster-security", are there > plans for this to change? If not, drop the "currently"; if so, we > have to remember to update the release notes when it happens.)
This will change, yes. After the next buster release, it should read buster instead of buster-security. Once there is a fixed firmware-iwlwifi available, affected users no longer need to disable microcode loading to work around broken wifi. Cheers -- Sebastian Ramacher
