Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asus Zenbook UX533FD don't boot with intel-ucode 20190312 #1

Open
jledun opened this issue Apr 29, 2019 · 96 comments
Open

Asus Zenbook UX533FD don't boot with intel-ucode 20190312 #1

jledun opened this issue Apr 29, 2019 · 96 comments

Comments

@jledun
Copy link

@jledun jledun commented Apr 29, 2019

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 :

$ pacman -Q | grep -e linux-lts -e systemd -e intel-ucode -e iucode
intel-ucode 20180807.a-1
iucode-tool 2.3.1-2
linux-lts 4.19.37-1
linux-lts-headers 4.19.37-1
systemd 242.16-1
systemd-libs 242.16-1
systemd-sysvcompat 242.16-1

The laptop boots with systemd EFI boot :

$ cat /boot/loader/entries/arch-lts.conf 
title	Arch Linux lts
linux	/vmlinuz-linux-lts
initrd	/intel-ucode.img
initrd	/initramfs-linux-lts.img
options	root=UUID=522a7ae9-8ad6-441e-85e2-baf1074be7f2  rw debug

journalctl

$ journalctl -b
-- Logs begin at Sun 2019-01-13 21:29:21 CET, end at Mon 2019-04-29 10:54:51 CEST. --
-- No entries --

CPU details (8 identical CPUs)

$ head -n26 /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 142
model name	: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
stepping	: 11
microcode	: 0x98
cpu MHz		: 800.029
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d arch_capabilities
bugs		: spectre_v1 spectre_v2 spec_store_bypass
bogomips	: 3984.00
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

lspci

$ lspci 
00:00.0 Host bridge: Intel Corporation Device 3e34 (rev 0b)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (Whiskey Lake)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 0b)
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model
00:12.0 Signal processing controller: Intel Corporation Cannon Point-LP Thermal Controller (rev 30)
00:14.0 USB controller: Intel Corporation Cannon Point-LP USB 3.1 xHCI Controller (rev 30)
00:14.2 RAM memory: Intel Corporation Cannon Point-LP Shared SRAM (rev 30)
00:14.3 Network controller: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] (rev 30)
00:14.5 SD Host controller: Intel Corporation Device 9df5 (rev 30)
00:15.0 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP Serial IO I2C Controller #0 (rev 30)
00:15.1 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP Serial IO I2C Controller #1 (rev 30)
00:15.3 Serial bus controller [0c80]: Intel Corporation Device 9deb (rev 30)
00:16.0 Communication controller: Intel Corporation Cannon Point-LP MEI Controller #1 (rev 30)
00:19.0 Serial bus controller [0c80]: Intel Corporation Device 9dc5 (rev 30)
00:1c.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #1 (rev f0)
00:1c.4 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #5 (rev f0)
00:1d.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #13 (rev f0)
00:1f.0 ISA bridge: Intel Corporation Cannon Point-LP LPC Controller (rev 30)
00:1f.3 Audio device: Intel Corporation Cannon Point-LP High Definition Audio Controller (rev 30)
00:1f.4 SMBus: Intel Corporation Cannon Point-LP SMBus Controller (rev 30)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP SPI Controller (rev 30)
02:00.0 3D controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] (rev ff)
03:00.0 Non-Volatile memory controller: Sandisk Corp WD Black 2018/PC SN520 NVMe SSD (rev 01)
@Heidistein
Copy link

@Heidistein Heidistein commented May 20, 2019

Confirmed. I tossed the microcode out of the initrd, the system works as expected.
Reloading it in the os (echo 1 > /sys/devices/something/something/reload) hangs the system immediately.

Loading

@mcu-administrator
Copy link
Contributor

@mcu-administrator mcu-administrator commented May 20, 2019

Confirmed. I tossed the microcode out of the initrd, the system works as expected.
Reloading it in the os (echo 1 > /sys/devices/something/something/reload) hangs the system immediately.

Does this also reproduce with the 20190514 release? Or only with the 20190312 release?

Loading

@jledun
Copy link
Author

@jledun jledun commented May 21, 2019

@mcu-administrator yes, I've got the same problem with 20190514 release.

Loading

@Heidistein
Copy link

@Heidistein Heidistein commented May 21, 2019

Indeed, this problem is actual on the 20190514 release.

Edit: I see now that you run Arch, I experience the same thing on Fedora30.
Kernel version seems not to matter, seen on 5.0.{3,6,16}-300.fc30

Loading

@victormmtorres
Copy link

@victormmtorres victormmtorres commented May 21, 2019

I came to this issue after tried many combinations and many times installing Linux distros (Ubuntu 16.04, 18.04, 19.04, Xubuntu 18.04) all had same issue after few restarts freeze at me moment of boot and it's same laptop Asus UX533FD.

Any hope of having Linux on my new laptop?

Loading

@mcu-administrator
Copy link
Contributor

@mcu-administrator mcu-administrator commented May 21, 2019

@jledun , @Heidistein , @victormmtorres Thanks for reporting this issue. We've opened an investigation based on your reports.

Loading

@breznak
Copy link

@breznak breznak commented May 22, 2019

I confirm this on Ubuntu and any of 4.15, 4.18, 5.0 kernels.

Any hope of having Linux on my new laptop?

@victormmtorres as a workaround, you can add dis_ucode_ldr to your kernel command line (even from GRUB), you'll be able to boot normally then.

Loading

@jerbob92
Copy link

@jerbob92 jerbob92 commented May 22, 2019

Can confirm, same CPU, same bug. Tried kernel 4.15, 4.18 and 5.1. Have 20190514 release installed (3.20190514.0ubuntu0.18.04.2). dis_ucode_ldr does fix boot.
If I can do anything to help/debug, let me know.

Loading

@victormmtorres
Copy link

@victormmtorres victormmtorres commented May 23, 2019

Surely there is a guide to install dis_ucode_ldr could anybody give me a reference about how to do it?

cc @jerbob92 @breznak

Loading

@jerbob92
Copy link

@jerbob92 jerbob92 commented May 23, 2019

@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 add dis_ucode_ldr to the linux line.

You can also edit /etc/default/grub and add it to GRUB_CMDLINE_LINUX_DEFAULT, then run sudo 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

Loading

@mcu-administrator
Copy link
Contributor

@mcu-administrator mcu-administrator commented May 24, 2019

@jledun Can you contact me through this email address? mcu_administrator@intel.com I have some additional questions and data we would like to collect to help us debug this.

@jerbob92 Can you do the same?

Loading

@tyhicks
Copy link

@tyhicks tyhicks commented May 29, 2019

@mcu-administrator I recognize that it can help to take debugging offline but could you please provide periodic updates in this bug report? It will help redistributors of microcode to make decisions on whether or not rolling back this particular microcode is necessary in the short term.

Loading

@jerbob92
Copy link

@jerbob92 jerbob92 commented May 29, 2019

@tyhicks, I'm not sure anything is happening at all... I emailed but never got a reply.

Loading

@tyhicks
Copy link

@tyhicks tyhicks commented May 29, 2019

@tyhicks, I'm not sure anything is happening at all... I emailed but never got a reply.

I've spoken to their engineers about it and they are working on it.

Loading

@mcu-administrator
Copy link
Contributor

@mcu-administrator mcu-administrator commented May 29, 2019

@jerbob92 Sorry for the delay. We've been working on a list of what data we would like to help debug the issue. In the meantime, we have also been working to reproduce the issue and are also in contact with the system vendor. We'll get a response to you by the end of the week.

Loading

@mcu-administrator
Copy link
Contributor

@mcu-administrator mcu-administrator commented May 29, 2019

@jerbob92 I took a look in my inbox and I cannot seem to locate an email from you. Can you resend please?

Loading

@jerbob92
Copy link

@jerbob92 jerbob92 commented May 30, 2019

Loading

@jledun
Copy link
Author

@jledun jledun commented May 31, 2019

@mcu-administrator done too!

Loading

@jerbob92
Copy link

@jerbob92 jerbob92 commented Jun 5, 2019

@mcu-administrator did you receive my mail? I did not hear anything back.

Loading

@jledun
Copy link
Author

@jledun jledun commented Jun 5, 2019

@jerbob92 I've got this awswer from @mcu-administrator :

Thanks for reaching out to us with the offer to help in debugging this issue. We are currently working with Asus to reproduce the issue. Based on the outcome of that work, we may have some additional questions or data we need to collect. I'll be in touch to keep you updated as we progress.

Seems like it takes some time to reproduce.

Loading

@svedrenne
Copy link

@svedrenne svedrenne commented Jun 5, 2019

This tracker reports the issue on ASUS UX533FD.
For information, I have the same issue on ASUS UX533FN.

Loading

@Heidistein
Copy link

@Heidistein Heidistein commented Jun 5, 2019

@svedrenne Actually, yes. Reading is something. I have the UX333FN_RX333FN edition.
However, I think it is not linked to the specific notebook, but the CPU.

Loading

@jerbob92
Copy link

@jerbob92 jerbob92 commented Jun 5, 2019

For anyone that uses the downgrade method for the intel-microcode package, be sure to lock the version while they work on a fix to be sure that you won't upgrade it by accident. You can do this using sudo apt-mark hold intel-microcode. When a fix is released you can use sudo apt-mark unhold intel-microcode to unlock.

Loading

@mcu-administrator
Copy link
Contributor

@mcu-administrator mcu-administrator commented Jun 5, 2019

Update: Asus has shipped us a system to work with on this issue. We are expecting to have it in the lab before the weekend. I'll provide an update on progress as we have something to report.

Loading

@mcu-administrator
Copy link
Contributor

@mcu-administrator mcu-administrator commented Jun 10, 2019

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.

Loading

@philjoseph
Copy link

@philjoseph philjoseph commented Jun 11, 2019

I confirm this on Ubuntu and any of 4.15, 4.18, 5.0 kernels.

Any hope of having Linux on my new laptop?

@victormmtorres as a workaround, you can add dis_ucode_ldr to your kernel command line (even from GRUB), you'll be able to boot normally then.

What is the impact of the workaround on the performance of the laptop ? Shall we switch to the fix once available or the workaround has no effect ?

Loading

@victormmtorres
Copy link

@victormmtorres victormmtorres commented Jun 11, 2019

What is the impact of the workaround on the performance of the laptop ? Shall we switch to the fix once available or the workaround has no effect ?

I could not notice any impact as this was truly blocking for me, without this workaround just after install ubuntu and restart have this issue

Loading

@markgross
Copy link

@markgross markgross commented Jun 11, 2019

What BIOS versions are folks reproducing this problem with?

Loading

@Heidistein
Copy link

@Heidistein Heidistein commented Jun 11, 2019

BIOS Information
        Vendor: American Megatrends Inc.
        Version: UX333FN.204
        Release Date: 09/20/2018
<snip>
        BIOS Revision: 5.13

Loading

@pcans
Copy link

@pcans pcans commented Jun 12, 2019

        Vendor: American Megatrends Inc.
        Version: X530FN.300
        Release Date: 11/01/2018
        BIOS Revision: 5.13

and the X530FN.207 also.

Loading

@tpapp
Copy link

@tpapp tpapp commented Sep 30, 2019

Update: on an Asus UX362FA with an Intel i7-8565U, running Ubuntu 19.04, the latest BIOS from Asus (version 303) fixes this bug.

Loading

@jerbob92
Copy link

@jerbob92 jerbob92 commented Sep 30, 2019

@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.

Loading

@tpapp
Copy link

@tpapp tpapp commented Sep 30, 2019

@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.

Loading

@jerbob92
Copy link

@jerbob92 jerbob92 commented Sep 30, 2019

@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.

Loading

@tpapp
Copy link

@tpapp tpapp commented Sep 30, 2019

@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.

Loading

@jerbob92
Copy link

@jerbob92 jerbob92 commented Sep 30, 2019

@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.

Loading

@TroyDowling
Copy link

@TroyDowling TroyDowling commented Oct 11, 2019

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...)

Loading

@svedrenne
Copy link

@svedrenne svedrenne commented Oct 11, 2019

@mcu-administrator Could you please let us know the actual status of the problem investigation/solving?

Loading

@jledun
Copy link
Author

@jledun jledun commented Nov 4, 2019

I confirm: after BIOS upgrade to 304, no problem anymore, I can update intel-ucode then my laptop boots as usual.

Loading

@jledun jledun closed this Nov 4, 2019
@breznak
Copy link

@breznak breznak commented Nov 4, 2019

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.

Loading

@jledun jledun reopened this Nov 4, 2019
@vieirajlt
Copy link

@vieirajlt vieirajlt commented Nov 19, 2019

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.

Loading

@jsfry
Copy link

@jsfry jsfry commented Nov 25, 2019

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

Loading

@esyr-rh
Copy link
Contributor

@esyr-rh esyr-rh commented Nov 26, 2019

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.

Loading

@jsfry
Copy link

@jsfry jsfry commented Nov 26, 2019

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

Loading

@KathyReid
Copy link

@KathyReid KathyReid commented Jan 7, 2020

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

Loading

@Edward-Zion-Saji
Copy link

@Edward-Zion-Saji Edward-Zion-Saji commented Mar 31, 2020

@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 add dis_ucode_ldr to the linux line.

You can also edit /etc/default/grub and add it to GRUB_CMDLINE_LINUX_DEFAULT, then run sudo 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'

Loading

@tornado80
Copy link

@tornado80 tornado80 commented Apr 1, 2020

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

Loading

@tornado80
Copy link

@tornado80 tornado80 commented Apr 1, 2020

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.

Loading

@svedrenne
Copy link

@svedrenne svedrenne commented Apr 2, 2020

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!

Loading

@tornado80
Copy link

@tornado80 tornado80 commented Apr 2, 2020

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?

Loading

@svedrenne
Copy link

@svedrenne svedrenne commented Apr 2, 2020

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.

Loading

@ramayer
Copy link

@ramayer ramayer commented Jun 12, 2020

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.

Loading

@block6791
Copy link

@block6791 block6791 commented Aug 4, 2020

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.

Loading

@rhiaro
Copy link

@rhiaro rhiaro commented Oct 21, 2020

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").

Loading

@svedrenne
Copy link

@svedrenne svedrenne commented Oct 21, 2020

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

Loading

@block6791
Copy link

@block6791 block6791 commented Oct 21, 2020

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.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet