Same problem
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.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
I'm using Asus UX305CA, have the same problem.
The workaround I use for now is to reinstall the system, then before
updating I make sure intel-microcode is put on hold:
sudo apt-mark hold intel-microcode
--
You received this bug notification because you are a member of Kernel
Packages, which
Upgrading the bios to latest version fixed the problem here.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1829620
Title:
intel-microcode on ASUS makes kernel stuck during loading
is the bug already fixed in ubuntu 20.04?
i tried to install 19.10 before half year, but did not success even if i try
everything -
install nvidia driver, update asus ux314 bios, nomodeset..
i think of try it again with the new dist,
is there any possible way that its already fixed?
thanks
--
Same issue from me after `apt-update`.
- Dell Latitude 7400
- Intel(R) Core(TM) i7-8665U CPU
- Ubuntu 18.04.4 LTS
- Kernel: Linux 4.15.0-1073-oem
- BIOS version 1.6.1
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Same issue.
DELL Latitude 5491
Intel(R) Core(TM) i7-8850H CPU
BIOS version 1.11.11 (most recent at the time of writing this comment)
Is it a Linux or a Asus/Dell bug?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Dell XPS5510 with i7-6820HQ has exactly the same issue on Ubuntu 19.10 after
fresh install, apt-update && apt-upgrade && reboot, gives purple screen / stuck
at Loading initramfs.
Switching kernel works once but next reboot it's stuck again.
Update of BIOS via built in one time setup menu and
FWIW I've had something that looks a lot like this problem (purple
screen; hang at "loading initial ramdisk ..." when booting with text)
after upgrading to the Eoan beta on a Skull Canyon NUC6i7KYB (Intel hw
not ASUS; Core i7-6770HQ).
5.3.0.12 and 5.3.0.13 kernels were affected, but booting with
Jason Bassett,
Sorry you are having a problem, but your laptop I believe has a
different processor family in it, and the issue you are facing is likely
not related to this issue. Please open a new bug report for your issue.
Thanks.
--
You received this bug notification because you are a member
Hello
Same issue with purple screen when login screen should be displayed.
By adding nomodeset to the Linux kernel line in Grub I was able to get
to the login screen.
But now I am just left at the purple screen once I have entered my login
credentials and pressed enter.
I have checked for BIOS
Hello !
I've been following this thread for a solution while not updating my ubuntu
18.04 fresh install.
Seeing that updating the BIOS was a possible fix, i flashed version 302 of my
ASUS BIOS (I own a UX450FD-BE014T) and updated everything.
When time came to reboot, I was stuck on the plain
I can confirm too that the BIOS update from ASUS fixed the problem
(nerve wrecking moment, though, for a someone new to Linux/Ubuntu).
Thanks for the help!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Can confirm that after the latest BIOS update from ASUS, I'm also able
to boot OK into Ubuntu without the dis_ucode_ldr option.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1829620
> Is there a BIOS update for your Dell?
At the time I was running the latest BIOS, but a few days later an
update appeared on Dell Support software (on Windows).
I updated the BIOS and then I let Ubuntu update the microcode normally.
It seems to work fine now with the latest microcode and no
@bellengc, you'd need to open up your Terminal to make a more permanent
edit to your grub bootfile. Once you have the terminal open, type in:
cd /etc/default
sudo vi grub
This will open up a text editor in your terminal. You're going to be
making edits to your bootfile so it's a good idea to
> I am super new to linux. I have read through the thread, and I am pretty sure
> that my ASUS ZenBook is having the same problem. I re-installed Ubuntu and
> have just not upgraded, but I not happy with that workaround. So, will this
> be something that will be fixed with a future update? Or,
I have an Asus UX533FD with the same booting problems. I use Ubuntu
18.04 with kernel v5.1.10. I can confirm adding dis_ucode_ldr works.
Thank you @Mark for reporting this bug and the workarounds! I am also
following the issue on Intel's Github repository. I haven't seen a patch
from them.
--
Is there a BIOS update for your Dell? I updated my Asus' BIOS and it fixed
the issue.
Though, now the NVIDIA driver does not work for me. I haven't had a chance
to dig in on yet. Perhaps a reinstall of the driver would fix it.
On Mon, 15 Jul 2019 at 05:30, Bert M Snider
I am super new to linux. I have read through the thread, and I am pretty sure
that my ASUS ZenBook is having the same problem. I re-installed Ubuntu and have
just not upgraded, but I not happy with that workaround. So, will this be
something that will be fixed with a future update? Or, will I
I'm affected by this too. I have a Dell Inspiron 5480 with an i7-8565U
CPU.
The problem happens after the first batch of updates on a fresh install
of Ubuntu Budgie 18.04.2 or Mint 19.1.
Thankfully, adding dis_ucode_ldr works, but finding this workaround on
the web was not easy!
--
You
Nice idea!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1829620
Title:
intel-microcode on ASUS makes kernel stuck during loading initramfs on
bionic-updates, bionic-security
Status
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
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
I can confirm all said before. In my case my laptop is an ASUS VivoBook
S14 S430FA. I bought it 2 days ago 'cause it was a cheep nice laptop
with just what I needed, and did came with a preinstalled linux
(Endless), so I could guess that it had to work properly in another
Linux like Xubuntu (I'm
Added WORKAROUND 3: BIOS upgrade
Please note this workaround is permanent and cannot be reverted, unlike 1,2. So
I will not be able to test this bug anymore.
** Description changed:
Description:
- my system gets stuck at "Booting, Loading initramfs" (the first 2 lines of
booting, after
> Per the above, are we safe to grab the latest kernel upgrades now and
do away with the dis_ucode_ldr workaround in grub at this point?
Hi, no, or at least problematic.
I don't know if/why it seemed to work for me at that time. Now I was NOT able
to boot ubuntu 5.0/4.18 kernels without the
Per the above, are we safe to grab the latest kernel upgrades now and do
away with the dis_ucode_ldr workaround in grub at this point?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
is it because of this? (is the file new?)
intel-microcode-blacklist.conf :
# The microcode module attempts to apply a microcode update when
# it autoloads. This is not always safe, so we block it by default.
blacklist microcode
--
You received this bug notification because you are a member of
Hey, I'm the OP,
I can confirm @felix-ticona 's finding, after the kernel upgrade
(atleast HWE to the -21 revision and the issue is "magically" done).
# uname -a
Linux xxx 4.18.0-21-generic #22~18.04.1-Ubuntu SMP Thu May 16 15:07:19 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
# dmesg | grep
Can someone pin-point what the change is in HWE kernel rebuilds -20 and
-21?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1829620
Title:
intel-microcode on ASUS makes kernel stuck
In our case downgrade the microcode don't work, instead of that we noticed that
our kernel was outdated:
uname -r
4.15.0-51-generic
so we upgrade the kernel to the recent version with:
sudo apt-get install --install-recommends linux-generic-hwe-18.04
xserver-xorg-hwe-18.04
with that the
Eric: This issue should only affect Ubuntu running bare metal on Intel
systems, so not Ubuntu running in a VM. Put differently: if you do not
run Ubuntu as the primary operating system on this MacBook Pro then
please file a separate bug report, or (ideally beforehand) see if you
can get this
Hello,
I have the same issue on VirtualBox with MacBook Pro as host. After the recent
update, the boot stops on all purple screen. However SSH login still works.
The WORKAROUND 1 % 2 don't work. Any more Workarounds?
Thanks
--
You received this bug notification because you are a member of
Hi,
I think the discussions already confirm this. Just wanted to reiterate:
I have ASUS-FX533FD Zenbook laptop with i7-8565U CPU. I also faced the
same problem as mentioned in the bug description. I can confirm that it
was fixed with "WORKAROUND 2: downgrade (and hold) intel-microcode to
older
Hi.
I'm using a Ubuntu 19.04 on a Samsung NP300E5C. I noticed I couldn't sudo
update and I was getting a "can't write to /tmp" error. I rebooted my PC, and
now it won't go past the purple screen. I've tried the add "dis_ucode_ldr" fix
but nothing happened. Please I'm fairly new at Linux, can
@TJ,
we got a new employee these days who had a slightly different model of
our laptop, and he got the purple screen hangup you're describing and
the workaround of pinning the intel-microcode version fixed the issue.
--
You received this bug notification because you are a member of Kernel
Steve: Another possible system affected where disabling microcode
loading appears to have fixed it. I'll leave it to you to decide whether
that is a duplicate of this issue though:
LP: #1829402 "Purple screen hangup during boot"
Tom and myself have spent some considerable time with the affected
for cosmic it's the very same package
sudo apt install intel-microcode=3.20180312.0~ubuntu18.04.1
and so far it seems to fix the issue, thanks a lot for the easy to
implement workaround.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
just heads up that the recent update to intel-microcode
(3.20190514.0ubuntu0.18.04.3) does not resolve the issue (probably
wasn't even expected to)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Chris, thanks for confirming which processor is in use.
To force downgrade the microcode package on bionic, do:
sudo apt install intel-microcode=3.20180312.0~ubuntu18.04.1
For other releases, you will need to replace the version with what
version(s) are available for your release; you can use
^^^ sorry this cpuinfo was off a ux433fn booted on an affected kernel
with dis_ucode_ldr
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1829620
Title:
intel-microcode on ASUS makes
Steve, Mark, I've had bios version 302 installed since the 5th of April
and was booting fine until the apt-get upgrade run on the 21st of May
note in my proc/cpuinfo the microcode version is listed as 0x98
also how do you force a downgrade of the microcode package?
** Attachment added:
Intel microcode update definitely created same issue for me on Asus
Zenbook 14 (UX433F) on 18.04.2 LTS.
Can also confirm the instructions above "add dis_ucode_ldr to the kernel
command line (from GRUB if you cannot boot)" worked perfectly for
temporary workaround.
This is my fourth Asus, and
Also, I'm still able to boot any kernel (with no extra boot params) when
I force-downgrade the intel-microcode to 2018 version (from bionic/main)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0.17/
so I have tested with a kernel from this PPA and it did not help.
Tyler,
there's one strange thing I'd like to ask: the boot process behaves
stateful(?!), ie. I can get into a previous "clean"/"dirty" state (and at least
liquorix)
> or you've recently installed a BIOS update which contains the latest microcode
revision and the kernel microcode loader didn't do anything.
Asus published BIOS version 302 for your laptop on 2019-04-02
(https://www.asus.com/Laptops/ASUS-ZenBook-14-UX433FN/HelpDesk_BIOS/).
I really have
On 2019-05-22 17:13:02, Mark wrote:
> > This may be a bug in how the kernel is loading the microcode
>
> can you review the liquorix patches? Their kernel boots with said
> microcode.
I compared the arch/x86/ source code directories in the liquorix and
Ubuntu kernels. While there are a large
> To avoid confusion, we need to be clear that the i7-8565U is a Whiskey
Lake processor (*not* a Kaby Lake)
yep, sorry, I got confused in the intel naming scheme, it's whiskey I'm
having problems with ;)
> This may be a bug in how the kernel is loading the microcode
can you review the
I was able to speak with folks at Intel about this and got some good
info from them:
* To avoid confusion, we need to be clear that the i7-8565U is a Whiskey
Lake processor (*not* a Kaby Lake)
-
Here's my /proc/cpuinfo
** Attachment added: "cpuinfo.txt"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829620/+attachment/5265773/+files/cpuinfo.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Thanks Mark & Chris! Appreciate your help in diagnosing and finding this
temporary workaround. Will keep my eyes on this thread for when there's
a more permanent fix.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
>>For anyone having a similar problem, try booting with microcode updates off:
add dis_ucode_ldr to the kernel command line (from GRUB if you cannot boot)
>>> can confirm this allows for boot.
>>> have put outputs of dmesg, uname -a, lscpu, iucode-tools files
here
For anyone having a similar problem, try booting with microcode updates off:
add dis_ucode_ldr to the kernel command line (from GRUB if you cannot boot)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
> Anyone here think that this:
https://bugs.launchpad.net/ubuntu/+bug/1829735 could be either a dupe of
this bug or related?
Hi Lei, thanks for reaching here! Very likely duplicate, as we have the
same HW and the people describe similar symptoms.
Duplicates:
Anyone here think that this:
https://bugs.launchpad.net/ubuntu/+bug/1829735 could be either a dupe of
this bug or related?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1829620
Title:
> We'll speak with Intel about this
thank you! Hope they manage to fix it soon.
Let me know if you need some more testing.
Cheers,
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
On 2019-05-21 07:14:52, Mark wrote:
> Is this two separate bugs?
> One that mds=on mitigation fails with the new microcode on any kernel,
> the other that microcode in my HW (ASUS, Kaby lake) fails to load on ubuntu
> kernels?
Possibly but a single bug is sufficient from Ubuntu's standpoint at
Is this two separate bugs?
One that mds=on mitigation fails with the new microcode on any kernel,
the other that microcode in my HW (ASUS, Kaby lake) fails to load on ubuntu
kernels?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
>From non-ubuntu kernel:
# uname -a
Linux mmm-U2442 5.0.0-17.1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix
5.0-17ubuntu1~bionic (2019-05-17) x86_64 x86_64 x86_64 GNU/Linux
# dmesg |grep microcode
#
# cat /proc/cmdline
audit=0 BOOT_IMAGE=/vmlinuz-5.0.0-17.1-liquorix-amd64
I'm very sorry, made a mistake
> > on the other hand, mitigations=off did cut it!
> > I guess now we're to find which of the mitigations is causing it? Do
> > you have a hint? Which are all the params for turning kernel
> > mitigations,please?
>
> Oh, that is interesting.
I was NOT able to boot
On 2019-05-21 05:37:09, Mark wrote:
> Actually, is the microcode loaded at all?
>
> # cat /sys/devices/system/cpu/cpu0/microcode/version
> cat: /sys/devices/system/cpu/cpu0/microcode/version: No such file or
> directory
That's odd. Try replacing cpu0 with cpu* to see if a version file exists
On 2019-05-21 05:28:18, Mark wrote:
> > If that doesn't work, can you try to boot with 'mitigations=off'
> > passed on the kernel command line?
>
> on the other hand, mitigations=off did cut it!
> I guess now we're to find which of the mitigations is causing it? Do
> you have a hint? Which are
PS,
#dmesg | grep microcode
#
returns nothing on the ubuntu hwe-edge kernel with mitigations=off
(=problematic ucode otherwise loaded)
Actually, is the microcode loaded at all?
# cat /sys/devices/system/cpu/cpu0/microcode/version
cat: /sys/devices/system/cpu/cpu0/microcode/version: No such
Tyler,
> Can you try to boot with the latest Ubuntu kernel, with the
problematic microcode, using 'mds=off' on the kernel command line? (Note
that it is 'off' instead of 'no')
I tried with mds=off, but no avail.
> If that doesn't work, can you try to boot with 'mitigations=off'
passed on the
Mark, one more request for now. You say that you can boot up a non-
Ubuntu kernel with the problematic microcode. Can you boot up one of
those kernels and then verify the microcode revision with the following
command:
$ sudo cat /sys/devices/system/cpu/cpu0/microcode/version
Please paste the
Simon, can you post the contents of /proc/cpuinfo as well? It'd help
with tracking down which processors might be affected by this. Thanks!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Mark, thanks for all the testing. Unfortunately, I asked Steve to have
you try the wrong 'mds=' option.
Can you try to boot with the latest Ubuntu kernel, with the problematic
microcode, using 'mds=off' on the kernel command line? (Note that it is
'off' instead of 'no')
If that doesn't work, can
> Also, do systems succesfully boot when 'mds=no' is passed on the
kernel command line with the problematic microcode in place?
no, this does not help
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Hi Steve,
no problem, thank you for digging into this!
> ith the affected processors report the output of:
iucode-tool -S
# iucode-tool -S
iucode-tool: system has processor(s) with signature 0x000806eb
> is it correct that you are *not* seeing this with 5.0 kernel from the
> linux-hwe-edge
TJ,
> An additional kernel command-line option that might reveal more would be
> remove "quiet splash" and add "debug early_print=XXX" where XXX is vga for
> BIOS-mode or efi for UEFI mode boots.
You may find "earlycon"
no info provided using these options, still stuck at the initrd line
Also, do systems succesfully boot when 'mds=no' is passed on the kernel
command line with the problematic microcode in place?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1829620
Title:
Hi, sorry the intel-microcode update is causing problems. Could one of
you with the affected processors report the output of:
iucode-tool -S
Mark, is it correct that you are *not* seeing this with 5.0 kernel from
the linux-hwe-edge kernel? Can you report the output of 'dmesg | grep
microcode'
Mark:
An additional kernel command-line option that might reveal more would be
remove "quiet splash" and add "debug early_print=XXX" where XXX is vga
for BIOS-mode or efi for UEFI mode boots.
You may find "earlycon" added into the mix may also add more early
messages.
See
Marking as an SRU regression and assigning to the Security Team uploader
for follow-up.
** Tags added: regression-security regression-update
** No longer affects: cryptsetup (Ubuntu)
** Changed in: intel-microcode (Ubuntu)
Assignee: (unassigned) => Steve Beattie (sbeattie)
--
You
73 matches
Mail list logo
