https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c36
--- Comment #36 from Dirk Weber
(In reply to comment #34) ... Right, I'm still working on those - it looks like 32-bit was completely b0rked from the beginning and it was rushed in without any serious testing. It is probably difficult to test the possible combinations. E.g. if the HW vendor includes the microcode update already in the BIOS/UEFI then this machine can not be used for these tests anymore.
BTW: is there a kernel parameter which inhibits early microcode update which can be used to boot the system in case the early update makes the system unbootable and all available initrds contain the microcode?
Unfortunately, no. The thing is, if the loading would have worked from the beginning, we wouldnt've needed a kernel parameter in the first place. :)
What you can do for now is drop the ucode from the initrd so that it cannot be found and loading fails. yes, currently with openSUSE 13.1 and the official mkinitrd it is easy to have the ucode *NOT* in the initrd. :-) But if mkinitrd gets this functionality and automatically all initrds of the system are updated this could be a problem.
Regarding comment #33: I am now just using /etc/init.d/after.local to check if the ucode was not yet updated and then trigger the update. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.