** Changed in: intel-microcode (Ubuntu)
Status: Fix Released => Won't Fix
** Changed in: intel-microcode (Ubuntu Xenial)
Status: New => Won't Fix
** Changed in: intel-microcode (Ubuntu Bionic)
Status: New => Won't Fix
** Changed in: intel-microcode (Ubuntu Eoan)
Statu
The version in eoan was superceded by the 20200609 release. In focal and
groovy, this change was reverted in 3.20200609.0ubuntu0.20.04.2 because
the tmpfiles.d approach, in addition to attmepting to late load early in
the boot process, also caused late loading to trigger during package
installation
On Fri, 14 Feb 2020, Steve Beattie wrote:
> The reason I ask is that every communication I've had with Intel has
> indicated that late loading is risky and should not be used. The reason
Well, it is risky, it is actively discouraged, and regular users are
NEVER expected to come anywhere close to l
I'm trying to fix the case when users/manufacturers failed to
provide/install uefi capsule update on the motherboard, failed to first-
boot with up to date microcode, and thus remain unsecured, whilst one
can install microcode. In bare-metal cloud context, late loading of
microcode can be done as t
Hey Dimitri,
Can you expand on what problems/situations where you're actually seeing
late loading be a solution?
The reason I ask is that every communication I've had with Intel has
indicated that late loading is risky and should not be used. The reason
for this is that performing late loading on
Hello Dimitri, or anyone else affected,
Accepted intel-microcode into eoan-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/intel-
microcode/3.20191115.1ubuntu0.19.10.3 in a few hours, and then in the
-proposed repository.
Please help us by testing thi
intel-microcode (3.20191115.1ubuntu3) focal; urgency=medium
* Ship tmpfiles.d snippet to attempt late loading of microcode during
boot, in case early loading of microcode did not happen. Early
microcode loading might not happen if booting without initramfs or a
missbuilt one.
-- Di
