|
Bugzilla – Full Text Bug Listing |
| Summary: | Boot hangs on initrd: ucode-intel-20200609-1.1 | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Tuukka Pasanen <tuukka.pasanen> |
| Component: | Basesystem | Assignee: | E-mail List <screening-team-bugs> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | rickscafe.casablanca |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Tuukka Pasanen
2020-06-14 09:18:28 UTC
same here. For me it is with kernels kernel-default-5.6.12-1.3.x86_64, kernel-default-5.6.14-1.6.x86_64. The older one seems to have a better chance to actually boot but most of the time I get this "Loading initial ramdisk" and then it just sits there. I had a look at initrd contents but they seem to be pretty identical but for the kernel modules. It started after recent updates, here done on 2020-06-13. System is encrypted root with unencrypted /boot, all on btrfs. I think it is related to intel microcode loading. When I disable that via grub linux switch dis_ucode_ldr, all kernels boot fine. For reference, this one year old bug https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/1 Incidentially, my laptop is an ASUS Zenbook UX303UB with this CPU vendor_id : GenuineIntel cpu family : 6 model : 78 model name : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz stepping : 3 microcode : 0x74 and I do have bootloader set to mitigations=off Asus released a bios update for my laptop last year. I was not aware that Asus still maintains this 2016 model. That bios comes with microcode version 0xba which is still less than the 0xdc that grub would load. I still need the dis_ucode_ldr param, though. (In reply to Mark Draheim from comment #3) > Asus released a bios update for my laptop last year. I was not aware that > Asus still maintains this 2016 model. That bios comes with microcode version > 0xba which is still less than the 0xdc that grub would load. > > I still need the dis_ucode_ldr param, though. It seems that this Asus UX**** problem as I also have same old Asus with Intel M-processor and dis_ucode_ldr fixes issue So, there is a workaround but it would still be great to have a real fix. Asus laptops aren't exactly rare ;-) Strange thing is that all three of my installed kernels apperently have the same intel ucode blob in front of their initrds. But only the oldest 5.6.12 boots (sometimes) whereas the newer ones fail consistently. Anyway, can I take the liberty and edit this bug's subject line? Will do (In reply to Mark Draheim from comment #5) > Anyway, can I take the liberty and edit this bug's subject line? Will do Be my guest new topic is more precises. I'm just wondering is this kernel problem. Got to test with vanilla flavor build without any (open)SUSE patching. If it's still hanging then it's something to-do with tooling or this microcode. Just pasting my CPU info also. My microcode is higher than your if there is anything to todo with anything. vendor_id : GenuineIntel cpu family : 6 model : 78 model name : Intel(R) Core(TM) m3-6Y30 CPU @ 0.90GHz stepping : 3 microcode : 0xba Right, maybe I can find the previous ucode-intel still on my home server which has a slower update cycle. I once found a TW mirror that kept old version but I lost the URL. If boot also fails with the older blob, then it might be tooling after all. it is the ucode. And this ticket here is a dup of #1172856 finally found the "mark as duplicate" button. Closing this one as all the action is in the other. And it seems a fix is on the way. Thanks *** This bug has been marked as a duplicate of bug 1172856 *** |