Can't boot after microcode update

Hello forum,
I am one of those guys whose computer fails to boot after updating intel’s microcode.

I am using: openSUSE Leap 42.2 (64 bit); KDE Plasma 5.8.6; Intel Core i3-4005U; Acer Aspire E15. Besides Suse, there are also installed Windows 8 (?) and Linux Mint 18 (Sarah), the bootloader is grub2 2.02-beta 94.3.1

After last week’s update my computer froze during the boot process with the kernel 4.4.104-18.44.1 default, stopping after showing the message “loading initial ramdisk”. Booting with parameters nopt, nospec, dis_ucode_ldr, noefi wasn’t successful either.

Since my computer booted successfully with kernel 4.4.103-18.41.1, I didn’t bother too much and just waited for the next update. However, after having just installed the new ucode-intel 20180108-7.12.1 the notebook still freezes when I want to boot with kernel 4.4.104

Could it be helpful to re-install kernel 4.4.104? If yes, is there any special procedure required?

Since an upgrade to Leap 42.3 is necessary anyway, would it be advisable to upgrade the current system or should I better make a fresh installation?

It would be great if someone could give me tip what to do next in order to re-establish old functionality. If there are important information missing to solve the problem, I will give them as soon as I can. It would be useful if you could give me directions how to obtain them.

What CPU do you have?
If you have different CPU (family) - because Broadwell-E offending microcode should be retracted - by all means open another bug report, mention it on on the above bug report as well. Post number here for others to follow.

E-h-h … but what makes you think it is microcode update? You say you can boot using older kernel and during update microcode is integrated in initrd of all installed kernels. You should check dmesg for microcode version.

In any case you should open bug report, as there are quite a lot of issues with new patches.

That the microcode is the culprit was only a conjecture formed after reading in the forum. Following your advice I filled in filled in a bug-report

Thank you for your help.

It is actually “nopti”. If you really used “nopt” it is worth to try the correct parameter.

You are right, but it was just a typo. This issue could gladly be resolved by installing a different kernel - see above bug-report.