1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
intel-microcode (3.20140913.1) unstable; urgency=low
This release drops support for automatically applying microcode
updates without a reboot. The microcode updates can still be applied
without a reboot through manual action of the system administrator, at
his own risk.
Microcodes known to be dangerous have been renamed so that they will
not be found by the kernel. This is a reactive blacklisting: it is
unlikely to be complete at any point in time.
The 3.x branch of the intel-microcode packages will only support Linux
kernels v3.10 and above. For older kernels, you must use the 1.x
branch of the intel-microcode packages.
Refer to /usr/share/doc/intel-microcode/README.Debian for details.
-- Henrique de Moraes Holschuh <hmh@debian.org> Fri, 10 Oct 2014 12:27:57 -0300
intel-microcode (1.20130222.3) unstable; urgency=low
This release adds support for early microcode updates on Linux kernel
v3.9 and later. It requires the kernel support for the feature to be
compiled in, the use of an initramfs, and also recent versions of the
iucode-tool and initramfs-tools packages.
Early microcode updates greatly reduce the chances of system
malfunction due to any issues that are corrected by the microcode
update. The microcode will be updated while the kernel initializes
the boot processor, and before any other processors (in a multicore
system) are enabled.
-- Henrique de Moraes Holschuh <hmh@debian.org> Wed, 19 Jun 2013 22:03:30 -0300
intel-microcode (1.20120606.4) unstable; urgency=low
The initramfs logic to automatically restrict the microcodes that have
to be installed using iucode-tool can fail in a very specific situation
when the intel-microcode package is installed for the first time at the
same time the _currently running_ kernel is being upgraded.
intel-microcode will warn you should that happen, and will install all
microcodes, resulting in a much larger initramfs image than expected.
If you did hit this failure mode and you believe the large initramfs
will cause problems for your system to reboot, please remove the
intel-microcode package to reduce the initramfs size, reboot to load
the upgraded kernel, and then reinstall the intel-microcode package.
Once the intel-microcode package is installed, it will cooperate with
the kernel packages and automatically avoid the issue on future
upgrades.
-- Henrique de Moraes Holschuh <hmh@debian.org> Sat, 11 Aug 2012 19:02:20 -0300
intel-microcode (1.20120606.1) unstable; urgency=low
This major release update changes how Debian handles Intel system
processor microcode updates. Initscripts and the old microcode.ctl
utility are not used to load microcode anymore.
Previously, microcode.ctl would be used to read the text file
distributed by Intel (microcode.dat), convert it to binary, and upload
to /dev/cpu/microcode. This functionality has been deprecated in the
kernel upstream for a long time, the firmware loader and a sysfs
interface should be used instead.
The Intel microcode.dat file is now preprocessed using iucode-tool when
the intel-microcode package is built, and the resulting binary data
files for /lib/firmware/intel-ucode are shipped, ready for use by the
kernel.
The intel-microcode package now provides automation for autoloading
microcode from the initramfs, instead of relying on any initscripts.
Refer to the README files in /usr/share/ doc/intel-microcode for more
details; there is some limited support for /usr/share/misc/
intel-microcode.dat files.
If you don't use an initramfs for a custom-built kernel, please make
sure the microcode driver is a module, and to load it at a time
/lib/firmware is already available. Adding it to /etc/modules is
usually enough. In this specific case, /usr/share/misc/
intel-microcode.dat is not supported, refer to the README files for
more detail.
WARNING: if you have an old /usr/share/misc/intel-microcode.dat file,
it may cause problems because of the way Intel does microcode release
management. As a rule, it is best to remove outdated microcode.dat
files from the system.
-- Henrique de Moraes Holschuh <hmh@debian.org> Tue, 10 Jul 2012 16:06:06 -0300
|
