Open jledun opened 5 years ago
@Phenecy I have an ASUS UX533FN and haven't upgraded the BIOS yet. But I've had problems with the temperature going too high and the fan not running at all, one or two weeks ago (Ubuntu 19.04).
See this post on StackOverflow AskUbuntu:
https://askubuntu.com/q/1148604
No more problem with the fan since I ran sudo prime-select intel
to shut down the NVidia GPU... Now the temperature stays low.
Hope this helps.
@svedrenne Thank you! Sadly, but this workaround is not enough if one planning to play or work with 3D... Gonna look for some more fixes. Thanks a lot
I have started the process of adding dis_ucode_ldr to grub recovery mode in Ubuntu. https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1831789
Same problem here with an ASUSPRO P5440FA. No BIOS update indicated on ASUS website for this model (https://www.asus.com/Laptops/ASUSPRO-P5440FA/HelpDesk_Download/). Kernel version: 4.15.0-52-generic Last working micrcode: Intel-microcode 3.20190514.0ubuntu0.18.04.2 All subsequent updates (I think I saw a 3.xxxxxxxx.0ubuntu0.18.04.3 at some point), up to the latest Intel-microcode 3.20190618.0ubuntu0.18.04.1, did not solve the problem for now.
Processor Information
Socket Designation: U3E1
Type: Central Processor
Family: Core i7
Manufacturer: Intel(R) Corporation
Signature: Type 0, Family 6, Model 142, Stepping 11
Version: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
BIOS Information
Vendor: ASUSTeK COMPUTER INC.
Version: P5440FA.204
Release Date: 10/11/2018
BIOS Revision: 5.13
@jerbob92 I have just read the thread from https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1829620. It is not clear to me what is the best option for now until the microcode gets fixed: booting with the dis_ucode_ldr
option or rather holding the microcode update until a newer update is released?
The only reason the old intel-microcode package version avoids this problem is that the old version does not ship a microcode file for the CPU in question here.
So disabling the microcode update has precisely the same result as the dis_ucode_ldr kernel parameter and it doesn't matter which one you use.
BTW, I just updated the BIOS of my ASUS UX533FN to latest version 302.
My problem now is I can't enter the laptop setup anymore, be it only to check the BIOS was updated with success... I tried pressing the usual F2 key until the ASUS logo displays. I also tried ESC.
I just can't access the setup anymore. Any solution?
@naijopkr Thanks for the suggestion about the shift
key, though it didn't work for me.
Finally, by pressing the ESC
key quickly and repeatedly (like a monkey) right after pressing the power button, I've been able to have the [Select boot device: ] GUI show up and to select the ASUS setup.
From the ASUS Flash Utility of the BIOS setup menu, I've been able to verify the ASUS BIOS of my UX533FN is now up-to-date, it is version 302 ("2019/06/14" on the website and "2019/3/29" in the Flash Utility).
I deactivated "Fast Boot" so as to be able to enter setup more easily, with the F2
key.
Try holding shift
when the ASUS logo is displayed. This should make the Grub menu show up. Then you can select the option System Setup.
I can confirm this bug with an Asus UX362FA with an Intel i7-8565U, running Ubuntu 19.04.
dis_ucode_ldr
provides a workaround.
Update: We have received a system from Asus and have been able to reproduce the failure in our lab. Debug is underway. I'll provide the next update when we have the root cause and a plan for the availability of a fix.
Hello there, do you have any update to share here ?
@naijopkr Now that I'm using BIOS 302 on my UX533FN, I tried removing the dis_ucode_ldr
kernel parameter workaround, and... it worked for me. The laptop booted alright. Strange, isn't it?
$ apt-mark showhold
returns nothing so I'm not holding the intel-microcode package.
$ dpkg -l | grep -i microcode | grep intel
ii intel-microcode 3.20190618.0ubuntu0.19.04.1 amd64 Processor microcode firmware for Intel CPUs
And the kernel is actally running without the dis_ucode_ldr
parameter:
$ dmesg | head
[ 0.000000] microcode: microcode updated early to revision 0xb8, date = 2019-03-30
[ 0.000000] Linux version 5.0.0-17-generic (buildd@lcy01-amd64-015) (gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1)) #18-Ubuntu SMP Tue Jun 4 15:34:08 UTC 2019 (Ubuntu 5.0.0-17.18-generic 5.0.8)
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.0.0-17-generic root=UUID=f643e450-7b07-4a36-ae3f-a20cc3555941 ro
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Hygon HygonGenuine
[ 0.000000] Centaur CentaurHauls
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Hope this helps for debugging, because I haven't heard that the problem is fixed for any platform or is it? @mcu-administrator
By the way, when I run the GRUB menu, most of the time the laptop keyboard gets stuck before I edit the boot commands. I don't remember having this problem before upgrading the BIOS to version 302, but I'm not sure. Each time the keyboard gets stuck (unusable), it follows a sort of display blink that I don't know how to interpret.
I tried removing the dis_ucode_ldr kernel parameter workaround, and... it worked for me. The laptop booted alright. Strange, isn't it?
On an Asus UX362FA, I get the error about 1/3 of the time during boot, it is not deterministic.
I can also confirm I have the same issue with Asus UX533FD, running Ubuntu 18..04 with kernel v5.1.10. I have not tried yet to upgrade BIOS version. Can anyone confirm me which workaround suits the best? Adding the dis_ucode_ldr parameter to the grub or update the BIOS? The version of the BIOS that Asus offers for my computer model is 304.
@soccerdroid you should definitely update the BIOS. Only try the workaround as last resource.
@naijopkr ok thank you, I'll try to update the BIOS then (hope it does not mess up with the grub). I can confirm the other workaround works for now.
@naijopkr what are the negative effects of the workaround ?
@mcu-administrator you've had the affected hardware a while now, is there any progress on resolving this issue?
Updating the BIOS to 302 fixes the problem on model RX533FN.
@mcu-administrator Can you please provide an update? Many of these folks are updating their BIOS so they are no longer experiencing the bug but I feel like there's a high likelihood that they'll have the same boot problems the next time that you release microcode updates for their processor and Linux distros provide the updated microcodes via software updates.
@mcu-administrator Can you please provide an update? Or can you at least confirm that this issue won't return when a new microcode version is released?
Update: on an Asus UX362FA with an Intel i7-8565U, running Ubuntu 19.04, the latest BIOS from Asus (version 303) fixes this bug.
@tpapp That's probably not true. Updating your BIOS does not fix this bug, you BIOS contains the latest microcode, so your BIOS loads it instead of the Linux kernel. When a new microcode is released which is not in your BIOS this bug will probably be triggered again, hence my question.
@jerbob92: all I am saying that I had an issue which required the dis_ucode_ldr
workaround on this laptop, and after the BIOS update it is not required, and the laptop boots normally. I suppose some people may find this information useful. I don't know what, if anything, will break this in the future.
@tpapp I'm just trying to stop spreading misinformation. I don't want people ending up here, updating their BIOS and thinking the issue is gone and then ending up with the same issue in a couple of months.
@jerbob92: I just reported some facts, what you consider "misinformation" is subsequent speculation on your part. Whether this issue will resurface is something that I cannot and did not predict — please don't put words in my mouth.
In any case, I don't see why users should not just update their BIOS (when an update is available), see what happens, and then disable the workarounds if they are no longer necessary. If the issue comes back, they should just report back here, I will also do that if necessary.
@tpapp I'm not saying they should not update their BIOS, I'm saying that upgrading your BIOS does not fix this bug, it's just a workaround. This is still an issue report about a bug in the microcode data, not an Ask Ubuntu topic, please keep this on-topic. Reports on workarounds, being a BIOS upgrade or dis_ucode_ldr
have been widely reported already and don't add anything to this issue anymore.
Anyway, this discussion also does not add anything to the issue, so I will not reply anymore.
To add my report: I had the same problem with an ASUS UX433FA (i7-8565U) on Arch Linux, but not Windows 10. Updating the BIOS from 301 to 309 resolved the issue. /proc/cpuinfo reports being on microcode 0xb8. (My curiosity makes me wonder if Windows has some special sauce to get around the bug, if it was late-loading the microcode safely, or if it ever loaded it at all...)
@mcu-administrator Could you please let us know the actual status of the problem investigation/solving?
I confirm: after BIOS upgrade to 304, no problem anymore, I can update intel-ucode then my laptop boots as usual.
upgrade to 304, no problem anymore, I can update intel-ucode then my laptop boots as usual.
the question asked at the Ubuntu bug is: what happens after another ucode update? Will it again break our notebooks? (unless there's again a new BIOS etc).
So I'd suggest reopening the issue and I wish people from Intel ( @mcu-administrator ?) were more communicative after people here spend time debugging the issue,finding workarounds and answering questions here.
On Asus Zenbook ux461fn (i5-8265U) this also happens, can't even boot. There is no BIOS upgrade (still on 302) so there is no solution.
Bad news. I can confirm that I have this same problem and I am not running an Asus Zen laptop but an Asus G703GXR with Intel i9-9980HK cpu. So this is affecting more than just the i7 cpus (as vieirjlt confirmed above with his i5-8265U). How widespread is this issue? My story is that after installing samba via the right mouse click on a particular folder in Ubuntu 16.04 I could not boot anymore - it stalled with a message saying something about "loading initial ramdisk". My investigations led me to this page. As soon as I instituted the workaround (dis_ucode_ldr) my laptop booted no problem (at least for now - I will in a minute try to make this workaround permanent). But the question persists to the mcu-administrator - what will happen on the next microcode update? Could you pls inform us of your findings.
My details: intel core i9-9980HK cpu @ 2.40Ghz x 16 intel hd graphics (Coffeelake 3x8 GT2) os 64 bit ubuntu 16.04 lts
PS. I have the latest bios update for my laptop - v.302
intel core i9-9980HK cpu @ 2.40Ghz x 16
May I ask you to provide information from /proc/cpuinfo (specifically, grep -E '^(cpu family|model|stepping|microcode)' /proc/cpuinfo | sort -u
)? The previous reports were related to 06-8e-0b CPUs, and this is (presumably) 06-9e-0d.
esyr-rh here you go:
$ grep -E '^(cpu family|model|stepping|microcode)' /proc/cpuinfo | sort -u cpu family : 6 microcode : 0xb8 model : 158 model name : Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz stepping : 13
my machine: Asus g703gxr
I was also experiencing this issue, but an update to BIOS v304 fixed it. Details of CPU and drivers follow for completeness.
kathyreid@kathyreid-zenbook-ux533fd:~$ grep -E '^(cpu family|model|stepping|microcode)' /proc/cpuinfo | sort -u
cpu family : 6
microcode : 0xca
model : 142
model name : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
stepping : 12
kathyreid@kathyreid-zenbook-ux533fd:~$ uname -a
Linux kathyreid-zenbook-ux533fd 5.3.0-26-generic #28-Ubuntu SMP Wed Dec 18 05:37:46 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
I'd previously held back intel-microcode
kathyreid@kathyreid-zenbook-ux533fd:~$ sudo apt-get install intel-microcode
Reading package lists... Done
Building dependency tree
Reading state information... Done
intel-microcode is already the newest version (3.20191115.1ubuntu0.19.10.2).
intel-microcode set to manually installed.
0 to upgrade, 0 to newly install, 0 to remove and 0 not to upgrade.
Happy to provide further diagnostics if needed.
Best, Kathy
@victormmtorres You can add the
dis_ucode_ldr
to the startup line when going to Advanced Startup Options and press e on the option you want to use. Then adddis_ucode_ldr
to the linux line.You can also edit
/etc/default/grub
and add it toGRUB_CMDLINE_LINUX_DEFAULT
, then runsudo update-grub
for a more permanent fix.I'm currently on a downgraded version of the microcode, which is the best fix IMHO:
sudo apt install intel-microcode=3.20180312.0~ubuntu18.04.1
This doesn't seem to work for me. It freezes at 'Loading initial ramdisk'
Since yesterday, technique 'dis_ucode_ldr' is not working anymore after a suspected software install. Normal booting fails at splash screen while recovery mode boot fails and freezes at 'loading initial ramdisk'. System: Asus VivoBook S430FN CPU: Intel i7-8565u OS: Ubuntu 18.04
Also it is worthy to mention that two days ago 'Ubuntu software and updates' brought me a new update and I installed it. The "suspected" term comes from here that after update I booted with no problem but after the second boot (occasionally having installed the software) it failed. Also I have not updated my BIOS but using dis_icode_ldr trick always through grub fix.
I suspect another issue (not Intel microcode related) is causing you current boot failure.
Try to gather more information (kernel version shown in Grub ?, logs if possible, etc.) in order to qualify your current problem.
Good luck!
I suspect another issue (not Intel microcode related) is causing you current boot failure.
Try to gather more information (kernel version shown in Grub ?, logs if possible, etc.) in order to qualify your current problem.
Good luck!
Thanks. By double checking boot logs which failed on Gnome display manager, I found the solution to use "lightdm instead of gdm3. But why did really "gdm3" fail suddenly on Nividia graphics card?
Maybe the Nvidia driver was updated as well when you accepted the Ubuntu update. The fragile configuration for the Nvidia card got broken in the process and needs urgent fine tuning (select the correct driver, etc.).
These Nvidia graphics cards are the cause of many problems. Personnaly I did:
$ sudo prime-select intel
in order to never use it. (I would have selected a laptop without an Nvidia card if I ever had the choice).
This solution is Ok only if, like me, you actually don't need the Nvidia graphics card.
Same problem on a
Asus Q504U Ubuntu 18.04
My workaround is to boot the 4.13.0-37 kernel (which works fine). The 4.15.0-101 and 4.15.0-106 kernels both fail for me.
Surely there is a guide to install
dis_ucode_ldr
could anybody give me a reference about how to do it?cc @jerbob92 @breznak
If you are on Pop_OS! (Systemd), then press e at boot time to add dis_ucode_ldr to the systemd options. If that works, you can make the changes permanent by editing Pop_OS-current.conf in /boot/efi/loader/entries.
Adding my report. I'm using Asus Zenbook UX433FA with i5-8265U, running Ubuntu 18.04. BIOS version is 300. I have had this problem intermittently for a year (usually boots after 3 or 4 attempts), but with a recent kernel update to 5.4.0-51 I can't boot at all (stuck on "Loading initial RAMdisk").
Hi rhiaro, You need to look at the kernel boot logs. Maybe this is another issue that you might solve easily by looking at the logs. Cheers
That error message, "Loading initial RAMdisk", can also be caused by having Secure Boot enabled. Check this setting in your BIOS. Should be somewhere in either the Boot or Security settings.
Hello,
I'm an ArchLinux user on Asus Zenbook laptop and my laptop can't boot with the latest intel-ucode update 20190312. I have to downgrade to 20180807.a to make it run again.
With the latest update of intel-ucode, after power on my laptop, the Asus splash screen appears then nothing else happen. I wait a few minutes then I push the power on button for 20 seconds to hard reset the laptop. After a reboot on live session, journalctl shows no entries even with the debug option in kernel command line.
It really looks like the chipset can't find any CPU.
Here are the system packages :
The laptop boots with systemd EFI boot :
journalctl
CPU details (8 identical CPUs)
lspci