5

Ubuntu 20.04 on ASUS UX303UB:

$ inxi -M -y 80
Machine:   Device: laptop System: ASUSTeK product: UX303UB v: 1.0 serial: N/A
           Mobo: ASUSTeK model: UX303UB v: 1.0 serial: N/A
           UEFI: American Megatrends v: UX303UB.206 date: 03/02/2016

I updated Ubuntu today via the built-in Software Updater program. The update installed the 5.4.0-53 kernel and completed without interruptions. Prior to this update, I had no problems booting Ubuntu.

$ dmesg | grep "microcode"
[ 0.000000] microcode: microcode updated early to revision 0xe2, date = 2020-07-14 
[ 0.558654] microcode: sig=0x406e3, pf=0x80, revision=0xe2 
[ 0.558683] microcode: Microcode Update Driver: v2.2. –

After the update, I was prompted to restart my computer, which I did. However, each time I rebooted I met a non-responsive black screen. I restarted again and could access GRUB. I could access recovery mode but I couldn't boot into normal Ubuntu. I tried rebooting many times and managed to get it working once. I installed and ran boot-repair with default settings. When I restarted it went back to the same black screen. I also tried booting the previous 5.4.0-52 kernel but it froze at "Loading initial ramdisk ...". After that I could not boot into Ubuntu at all.

What eventually worked was accessing the UEFI firmware menu and disabling Secure Boot and enabling CSM. My question is, what went wrong and how can I figure that out?

My output:

$ grep "upgrade " /var/log/dpkg.log
2020-11-11 10:25:47 upgrade network-manager-gnome:amd64 1.8.24-1ubuntu2 1.8.24-1ubuntu3
2020-11-11 10:25:47 upgrade libnma0:amd64 1.8.24-1ubuntu2 1.8.24-1ubuntu3
2020-11-11 10:25:47 upgrade gir1.2-nma-1.0:amd64 1.8.24-1ubuntu2 1.8.24-1ubuntu3
2020-11-11 10:25:55 upgrade intel-microcode:amd64 3.20200609.0ubuntu0.20.04.2 3.20201110.0ubuntu0.20.04.1
2020-11-11 10:25:55 upgrade linux-generic-hwe-20.04:amd64 5.4.0.52.55 5.4.0.53.56
2020-11-11 10:25:56 upgrade linux-image-generic-hwe-20.04:amd64 5.4.0.52.55 5.4.0.53.56
2020-11-11 10:26:06 upgrade linux-headers-generic-hwe-20.04:amd64 5.4.0.52.55 5.4.0.53.56
2020-11-11 10:26:06 upgrade linux-headers-generic:amd64 5.4.0.52.55 5.4.0.53.56
2020-11-11 10:26:07 upgrade linux-libc-dev:amd64 5.4.0-52.57 5.4.0-53.59
2020-11-11 11:02:35 upgrade libplymouth5:amd64 0.9.4git20200323-0ubuntu6.1 0.9.4git20200323-0ubuntu6.2
2020-11-11 11:02:35 upgrade plymouth-theme-ubuntu-text:amd64 0.9.4git20200323-0ubuntu6.1 0.9.4git20200323-0ubuntu6.2
2020-11-11 11:02:35 upgrade plymouth-theme-spinner:amd64 0.9.4git20200323-0ubuntu6.1 0.9.4git20200323-0ubuntu6.2
2020-11-11 11:02:35 upgrade plymouth-label:amd64 0.9.4git20200323-0ubuntu6.1 0.9.4git20200323-0ubuntu6.2
2020-11-11 11:02:36 upgrade plymouth:amd64 0.9.4git20200323-0ubuntu6.1 0.9.4git20200323-0ubuntu6.2
2020-11-11 12:35:35 upgrade libraptor2-0:amd64 2.0.15-0ubuntu1 2.0.15-0ubuntu1.20.04.1
  • Upgrades at 10:25 - the upgrades that caused the boot issue
  • Upgrades at 11:02 - upgrades performed via recovery mode (fix packages)
  • Upgrades at 12:35 - upgrade after successfully booting into Ubuntu by disabling SecureBoot and enabling CSM
2

4 Answers 4

1

There is a new version of intel-microcode package. After the update the PC starts without problems. From apt changelog intel-microcode:

Version 3.20201110.0ubuntu0.20.04.2:
  * SECURITY REGRESSION: Some CPUs in the Tiger Lake family sig=0x806c1
    fail to boot (LP: #1903883)
    - remove 06-8c-01/0x000806c1 microcode
2
  • Which model do you have? lscpu | grep -i 'Model name'. I still had the issue with intel-microcode 3.20201110.0ubuntu0.18.04.2 (I'm using i7-6500U). Downgrading to .1 worked. Disabling altogether should work too. Nov 17, 2020 at 22:09
  • @PabloBianchi It's a Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz CPU with Ubuntu 20.04.1 LTS.
    – inkantis
    Nov 19, 2020 at 9:01
1

Had same problem with Asus UX305CA, boot hangs with black screen after last update. Served me a really bad day: Tried recovery, grub-recovery... nothing helped. I'm only able to boot to recovery mode. Since I have QHD display, I suspect the Intel driver update is the reason.

My temporary fix:

  1. Identfy the prior version by

    sudo apt-cache policy intel-microcode
    
  2. and roll back to this version

    sudo apt-get install intel-microcode=3.20180312.0~ubuntu18.04.1
    

Reboot now works again in normal mode.

1
  • You might need to hold it to avoid future upgrades: sudo apt-mark hold intel-microcode Nov 25, 2020 at 17:44
0

Not sure it is the same problem, but I also had an issue after upgrade to 5.4.0-53 on a dell xps 13 with win 10 dual boot. In the BIOS the hard disk setup had been to changed back to RAID from AHCI (which was required to install ubuntu). Neither Win10 or ubuntu could find the hdd. Changing to AHCI fixed my problem.

0

This worked for me:

Use the "dis_ucode_ldr" boot option to prevent the microcode update during the boot process.

I just updated a laptop, and got basically the same crash. The boot process hangs after loading the ramdisk image. What is interesting is that sometimes the boot will succeed, say in 10% of my attempts (if I don't use dis_ucode_ldr).

My laptop possibly has the same processor as yours, an i5-6200U. You don't say which model of the ASUS UX303UB you have, but one of them has the i5-6200U.

As inkantis pointed out, there has been a recent Intel microcode update, which has caused problems. In your updates list, I can see that this microcode update has been downloaded at 10:25:55, just before you experienced the first boot crash. It's "intel-microcode:amd64 3.20201110.0ubuntu0.20.04.1" (notice that it ends with "1").

There is indeed a new version available, which is "intel-microcode 3.20201110.0ubuntu0.20.04.2" (it ends with "2"), but it is precisely the version that is installed on my laptop! It looks like this new update does not solve the problem on i5-6200U. I must add that this laptop did not go through the "intel-microcode:amd64 3.20201110.0ubuntu0.20.04.1" update, so I don't know if it would have crashed with it.

When I insert "dis_ucode_ldr" in the grub command line, the machine boots up every time (just tried more than a dozen times in a row).

I have used Grub Customizer to add this boot option "permanently", and I will remove it the next time I see an Intel microcode update.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .