Re: Freeze exception request for intel-microcode and amd64-microcode
On Thu, 01 Nov 2012, Philipp Kern wrote:
> On Tue, Oct 30, 2012 at 09:14:48PM -0200, Henrique de Moraes Holschuh wrote:
> > References: bugs #690285 and #690286
> >
> > The versions of both intel-microcode and amd64-microcode currently in Wheezy
> > can trigger a nasty bug in initramfs-tools that renders the system
> > unbootable. The packages in unstable work around this issue.
> >
> > The bug will only happen when $TMPDIR (usually /tmp) is mounted noexec at
> > the time "update-initramfs" is run. While this is quite unusual, it did hit
> > one user (bug #689301).
> >
> > In addition to the changes fixing that issue, the intel-microcode package
> > also contains a new upstream release. Intel issued a microcode hotfix for
> > all current i5/i7/Xeon processors in 2012-10-01. Due to the very unusual
> > nature of this microcode update (it is labeled "20120606-v2" by Intel, a
> > strong hint that it is fixing mishaps in the microcode release currently in
> > Wheezy), and the inclusion of microcode updates even to very high-end Xeon
> > E7 processors, it is likely fixing something very relevant.
> >
> > The packages have been 20 days in unstable already, without any issues
> > reported.
> >
> > Please consider unblocking intel-microcode (#690286) and amd64-microcode
> > (#690285).
>
> Really pretty please file an unblock bug for each package next time, thanks.
I did! The bug numbers mentioned in the "please consider unblocking"
sentence are the bug numbers of the unblock request bugs (#690285 and #690286).
I am sorry I was not sufficiently clear about it in the message.
> @@ -9,7 +9,7 @@
>
> # dependencies: firmware loader, microcode kernel support (built-in/module)
>
> -PREREQ="udev"
> +PREREQ=""
>
> prereqs()
> {
>
> If the main problem was in the name of the script, why is this still needed?
Because udev is not present in the hook level intel-microcode and
amd64-microcode runs (init-premount), it belongs to a hook level that runs
BEFORE that (init-top).
Therefore, that PREREQ was an error, and since I was already fixing breakage
in the interaction with initramfs-tools, I decided it was better to remove
the bogus PREREQ in case someone backports the package to a system with a
much older initramfs-tools (which doesn't support missing prereqs), or a
future version of initramfs-tools decides to not ignore the bogus PREREQ
anymore.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: