Comment # 26 on bug 1217083 from Antonio Feijoo

(In reply to Roeland Jansen from comment #25)
> well....
> 
> 
> The problem is that it's at home and work a TW issue (3 or 4 systems)
> AND it also is a same issue on SLES (*) (at work)
> 
> 100% same issue, same problem, no PVs found after update.
> We do know the work-around" - on all the systems, removing ucode* upfront.
> 
> (*) I could just skip it and let it go like "if someone else has this issue,
> I don't care" but to me that's not helping. 
> 
> Two different teams looking at it to me doesn't seem to me effective use of
> resources?

SLE is a commercial product, therefore all its incidents must be handled
through the SUSE Customer Center (https://scc.suse.com/). That does not mean
different teams, but different processes. Thank you for your understanding and
I hope this does not cause you any inconvenience.

Other than that, I suspect (it's the only thing I can do with the info I have)
that you are experiencing at least 2 different issues:
- 1 : Tumbleweed update from 23031107 to 20231108 on two laptops with Intel CPU
=> problem with ucode-amd (comment #0, comment #3)
- 2 : SLES 15.5, update? laptop or vm? with Intel CPU => problem with
ucode-intel (comment #10)

Both Tumbleweed and SLE have different kernel, dracut, firmware versions...
Tumbleweed is a rolling release, so it's very unlikely that an issue with a TW
update is related to an issue in SLE.

BTW, AFAIK microcode only affects physical CPUs, the vm guests do not have
microcode of it's own, so it's even more strange that a ucode package is
breaking a vm. And, as Takashi said in comment #8, a problem with a microcode
should not allow the system to get this far in the boot process.

So, it'd great if you can provide the Tumbleweed logs requested in comment #11
(`dracut -f --debug test.img 2>&1 &> dracut.log`), and the file
/run/initramfs/rdsosreport.txt after trying to boot with the generated
initramfs test.img, passing also `rd.debug` to the kernel command line. Thanks!