I have another suspicion - and a possible solution - as I had the exact same thing happen with my PC (and an intel Broadwell E, Core i7 6800K CPU).
After an update on Friday to
- kernel : 4.4.104-39.1
- ucode-intel : 20170707-13.1
My computer didn’t boot anymore and was hanging in the “loading initil ramdisk” screen.
After some researching and experimenting, I got the tip to try disabling the loading of custom microcode with the kernel parameter “dis_ucode_ldr**”**!
As soon as i did this, I could again boot my machine without any problems.
This then brought me the idea, to check what has been updated in the microcode area, and indeed, there was that latest ucode-intel update: 20170707-13.1
After going back to an old ucode-intel (20170511-8.1) - and locking it until things get fixed - I can normally boot up without the need to use “dis_ucode_ldr”.
I also checked a little bit, what kind of microcode updates this ucode-intel-20170707-13.1.x86_64.rpm offered. First I scanned for my CPU ID with iucode_tool:
- iucode_tool: system has processor(s) with signature 0x000406f1
Then looked with iucode_tool what was included in the current ucode set:
1. 085/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624
1. 085/002: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624
1. 085/003: sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
Its quite likely, that the latest line (with date 2017-11-18) was / is the culprit, as it seems to be a relatively new ucode.
But what made me really surprised was, when I checked what the latest - downloadable - Intel (official) packaes includes which one can download here https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File
So, there you get the latest 20171117.tgz … and this one only offers one ucode for my CPU:
089/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624
So, obviously there is quite some confusion (quite likely on Intels side), on what theyhave (keep) in their current ucode package … and what Suse has to offer in the latest update. Maybe Intel already removed the ucode update for my CPU because they know that it created some issues.
What ever. For the moment it seems that some - definitely my - CPUs don’t boot (or hang) when they get treated with the latest ucode. Thus maybe - for now - its better to stay with an older (but stable) ucode package on CPUs which exhibit these issues.
PS … as a reference, I also wrote about this on a the German opensuse-forum: