On Fri, Sep 26, 2014 at 2:53 PM, Andrew Lutomirski <luto(a)mit.edu> wrote:
On Fri, Sep 26, 2014 at 11:37 AM, Hans de Goede
<hdegoede(a)redhat.com> wrote:
> Hi All,
>
> Just spend some time debugging this and thought I should share this, see:
>
>
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195
>
> for details, I've filed a bug to track fixing this in Fedora:
>
>
https://bugzilla.redhat.com/show_bug.cgi?id=1147062
>
> There are 2 ways this problem shows itself:
>
> 1) If using an initrd which has been generated with the troublesome microcode
> update into it, things may already crash during the initrd, e.g. in my case
> some luks volumes would not unlock because of this
>
> 2) When booting an older kernel (and thus an older initrd) things start crashing
> (mostly systemd* processes, grinding everything to a halt) as soon as udev
> from the rootfs loads the microcode update
>
> 2. often will still get you to an emergency shell, at which point one can
> create a /etc/modprobe.conf.d/no_microcode.conf file with:
>
> blacklist microcode
>
> In there to work around the problem, then regenerate the initrds for newer
> kernels, and you should be good to go until bug 1147062 gets fixed properly.
Yeah, sorry, I should have tried to notify the right Fedora people in advance.
I knew about it. This is basically a breakdown in communication
between the kernel people and the microcode_ctl owner. it was
compounded by the fact that I didn't realize our main dracut
maintainer was on PTO so I didn't fix dracut myself until this
morning.
This is a nasty issue, and no one knows how to solve it for real
yet.
See this long thread:
http://thread.gmane.org/gmane.linux.kernel/1790211
Yeah. FWIW, I just filed an update to have Fedora use early microcode
by default. A COPR of this was tested successfully by a few people
that had the Haswell issue.
https://admin.fedoraproject.org/updates/dracut-038-29.git20140903.fc21,ke...
josh