3

Since today, I encounter this error message whenever I boot Ubuntu, and it won't let me boot Ubuntu. 

[    0:000000] [Firmware Bug]: TSC_DEADLINE disabled due to Errata;  
please update microcode to version: 0x52 (or later)
...  
BusyBox v1.22.1 (ubuntu 1:1.22.0-ubuntu2) built-in shell (ash)   
Enter 'help' for a list of built-in commands  
(initramfs) _

and I am now stuck at the BusyBox (initramfs).

I'm guessing I have to update the microcode, and I couldn't figure out how to do this as I can't even boot Ubuntu. The error message appears after it asks me to enter the pass-phrase for my encrypted hard drive.

Before this it also gives me the error message Error: environment block too small Press any key to continue.

I don't want to reinstall Ubuntu from scratch, as I still hope to get to the data I have on the encrypted drive. I have also attempted to access the encrypted drive booting from the live USB, but received errors when attempting to access/mount it. (mount: wrong fs type, bad option, bad superblock on /dev/mapper/ubuntu--vg-root)

A couple of days before this happened, I had installed the latest updates as suggested to me by the Ubuntu Software Center.

karel
  • 114,770
Lilia
  • 41
  • Can you still boot your original installation media? (DVD/USB)? What's the output of lsb_release --code --release? Please [edit] your question to provide this additional data and leave a comment @fabby to warn me you've done so. – Fabby Feb 02 '18 at 23:10
  • @Fabby thanks for the reply! still have the installation usb, the output is 16.04 xenial. i've tried to recover the data from the encrypted partition using the live usb but failed (can't mount the drive). so i'm still hoping i can solve this problem without loosing data – Lilia Feb 03 '18 at 18:13
  • Please [edit] your question and provide all relevant info! An encrypted partition is very relevant, what did you change before having this error is also relevant. Please help us help you as now it's too unclear as to what the root cause of your problem is. – Fabby Feb 04 '18 at 10:53
  • @Fabby thanks for getting back. i updated the question and added more info. does this help to clarify the problem? – Lilia Feb 04 '18 at 13:07

1 Answers1

0

Microcode isn't updated at [0:000000]. This is what my system revealed:

$ cat /var/log/syslog | grep microcode
Feb  4 15:24:28 alien kernel: [16109.540807] microcode: microcode updated early to revision 0xba, date = 2017-04-09

and from:

$ cat /var/log/syslog.1 | grep microcode
Feb  3 08:08:07 alien kernel: [    1.152389] microcode: sig=0x506e3, pf=0x20, revision=0xba
Feb  3 08:08:07 alien kernel: [    1.152899] microcode: Microcode Update Driver: v2.2.
Feb  3 08:08:53 alien kernel: [    1.150298] microcode: sig=0x506e3, pf=0x20, revision=0xba
Feb  3 08:08:53 alien kernel: [    1.150765] microcode: Microcode Update Driver: v2.2.
Feb  4 08:30:54 alien kernel: [57834.131308] microcode: microcode updated early to revision 0xba, date = 2017-04-09
Feb  4 08:32:28 alien kernel: [    1.143969] microcode: sig=0x506e3, pf=0x20, revision=0xba
Feb  4 08:32:28 alien kernel: [    1.144257] microcode: Microcode Update Driver: v2.2.

...Intel Microcode is updated about 1 second into the boot when using an NVMe M.2 SSD.

Your question might be closed as a duplicate soon and I just wanted to post this information before it was closed.

If you search "TSC_DEADLINE microcode" you'll find a similar question here in Ask Ubuntu that also might be closed as a duplicate soon.

WinEunuuchs2Unix
  • 102,282