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.
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
--Andy