Asus ZenBook UX501VW frequently hangs during boot under Ubuntu 16.04

Bug #1575437 reported by Adric Norris on 2016-04-27
90
This bug affects 17 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Low
Unassigned

Bug Description

A fresh install of Ubuntu Gnome 16.04 on an Asus ZenBook UX501VW hangs during boot, approximately 80% to 90% of the time... occasionally it manages to complete the startup for no discernible reason, at which point the fan will run at full speed nonstop (very loud) until the machine is powered down. Due to the information from <https://marclewis.com/2016/04/25/installing-ubuntu-16-04-lts-on-asus-zenbook-ux501vw/>, I installed the wily 4.3.5 kernel (replacing 4.4.0) from <http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.3.5-wily/>, which appears to work perfectly... no bootup hangs or odd fan behavior.

The hang occurs shortly after providing the disk decryption key (I opted for full-disk encryption during installation). The issue occurs frequently when booting Ubuntu Gnome from a flash drive using "try before installation" mode, however, so I'm confident that it's not actually encryption related.

I am *not* using any proprietary drivers (no nvidia, etc.).

WORKAROUND: Use kernel parameter:
nouveau.modeset=0

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux-image-4.4.0-21-generic 4.4.0-21.37 [modified: boot/vmlinuz-4.4.0-21-generic]
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: adric 1574 F.... pulseaudio
CurrentDesktop: GNOME
Date: Tue Apr 26 19:19:26 2016
HibernationDevice: RESUME=UUID=74c52e77-74c8-49d1-843b-23584516bd07
InstallationDate: Installed on 2016-04-26 (0 days ago)
InstallationMedia: Ubuntu-GNOME 16.04 LTS "Xenial Xerus" - Release amd64 (20160421)
MachineType: ASUSTeK COMPUTER INC. N501VW
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-21-generic.efi.signed root=/dev/mapper/ubuntu--gnome--vg-root ro quiet splash
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-21-generic N/A
 linux-backports-modules-4.4.0-21-generic N/A
 linux-firmware 1.157
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 02/03/2016
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: N501VW.206
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: N501VW
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrN501VW.206:bd02/03/2016:svnASUSTeKCOMPUTERINC.:pnN501VW:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnN501VW:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.name: N501VW
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.

Adric Norris (landstander668) wrote :

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Adric Norris (landstander668) wrote :

For what it's worth, booting with "acpi=off" seems to reliably avoid the hang, although it comes with side effects an therefore isn't really a good workaround. None of the other acpi-related boot options mentioned at <https://01.org/linux-acpi/documentation/debug-how-isolate-linux-acpi-issues> seem to help.

So far, booting with the 4.3.5 wily kernel seems to be the most usable workaround..

Adric Norris (landstander668) wrote :

Just tried the 4.6-rc5-wily kernel image, which unfortunately still exhibits this problem. I'll keep trying updated kernels periodically, especially when ones tagged for xenial begin appearing.

When i hae tried 4.6-rc5-wily without nvidia, the bugs still present.

But when i tried to install nvidia driver, kernel mod does not compil, nouveau driver does not load and intel graphic work fine.

Changed in linux (Ubuntu):
importance: Undecided → Critical
Adric Norris (landstander668) wrote :

For what it's worth, the 4.6-rc6-wily kernel build still exhibits this issue.

tags: added: kernel-bug-exists-upstream needs-bisect
Changed in linux (Ubuntu):
status: Confirmed → Triaged
importance: Critical → High
tags: added: kernel-da-key
Tim (tim-cesnik) on 2016-05-06
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Adric Norris (landstander668) wrote :

I'm assuming that the current status of Incomplete means that additional data is needed. Can someone please elaborate on this? I'll happily do my best to supply any missing information.

Joseph Salisbury (jsalisbury) wrote :

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

Please follow the instructions on the wiki page[0]. The first step is to email the appropriate mailing list. If no response is received, then a bug may be opened on bugzilla.kernel.org.

Once this bug is reported upstream, please add the tag: 'kernel-bug-reported-upstream'.

[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel

Changed in linux (Ubuntu):
status: Incomplete → Triaged
Tim (tim-cesnik) wrote :

The culprit who changed the status from Triaged to Incomplete was me. It was a complete rookie, noob, mistake for wich I do apologise and hope that I did not cause a too big of a confusion and/or unnecessary work.

Also a big thank you goes to the developers who are working on and diagnosing this bug. Keep up the good work, you guys are awesome.

Adric Norris (landstander668) wrote :

I probably won't be able to followup with an upstream kernel report until next week, due to various offline commitments. Will certainly look into it at that point, however.

Adric Norris (landstander668) wrote :

For what it's worth, the 4.6.0 kernel from <http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-yakkety/> appears to work perfectly in conjunction with the "nouveau.modeset=0" boot parameter. I haven't encountered any bootup hangs with this combination, no issues with the fan, nor any apparent loss of functionality. [NOTE: I have not re-tested any of the previous kernels with this parameter]

For the time being I've simply added the setting to /etc/default/grub (see below), followed by running "sudo update-grub".

$ grep nouveau /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="nouveau.modeset=0 quiet splash"

I'll let you know if any side effects arise, but I've rebooted about 6-8 times so far and everything appears to be rock solid. :)

Adric Norris, to clarify, could you please advise the results of testing the latest mainline kernel (4.7-rc1) without any WORKAROUNDs (ex. nouveau.modeset=0)?

tags: added: bios-outdated-300
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Adric Norris (landstander668) wrote :

The 4.7-rc1 kernel fails to boot entirely, which occurs very early in the process. There were a number of messages concerning "address family not supported" shown, although I didn't pay a great deal of attention since 4.7-rc2 is already available.

As far as I can see, the 4.7-rc2 kernel behaves exactly the same as 4.6.0... hanging during boot, just after providing the disk decryption password. Adding the nouveau.modeset=0 parameter via grub seems to reliably avoid the issue.

Adric Norris, to clarify, does using the WORKAROUND nouveau.modeset=0 also work in the default Ubuntu repository kernel?

Andrew Carlson (andrewc0101) wrote :

I just tried an install with the 16.04.01 image and I'm seeing the same issue.

I tried adding the nouveau.modset=0 parameter without much luck, but it's possible I'm just setting it in the wrong way. Here is what I tried.

1) When the install grub menu appears the default "try ubuntu..." option is selected.
2) I select 'e' to edit this option.
3) I add the "nouveau.modset=0" parameter on the linux line right before "quiet splash".
4) I then press escape and select the "try ubuntu" option.

Am I setting this incorrectly?

Also I can report that some of the time it gets all the way to the desktop UI with or without the parameter change. When it gets all the way to the desktop screen the fan suddenly turns up to full blast. Most of the time I just get stuck on the ubuntu loading screen.

Nazaal (nazaal) wrote :

I too encountered many problems with Ubuntu on my ASUS UX501VW,
During installation, it got stuck in the Ubuntu splash screen maybe 4 times, each time I had to manually shut down using the power button. This issue was solved by using a USB 3.0 (I used a USB 2 pen drive before).

However, after installation, the fan went on to full blast, I updated to kernel to version 4.6 as described here -> http://askubuntu.com/questions/765394/ubuntu-16-04-fan-problem-on-my-asus-ux501vw , but this didn't change a thing

My current problem (aside from the noisy fan) is I get a black screen with a blinking underscore when I shutdown. I did get various messages like "/dev/nvme0n1p5: recovering journal" which last a long time and "[576.981129]nouveau: 0000:01:00.0: pci: failed to adjust lnkctl speed and [600.291447] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [plymouthd:2112]'.

I had to manually shutdown using the power button, but this restarts the laptop so I boot into Windows and shutdown from there.

tiJoe (josephbergevin) wrote :

I have just started using the ASUS UX501VW as my development laptop. I am running 16.04.1 on the 4.3.5-040305-generic kernel. I haven't tried anything more than what I've read in these comments.
Laptop is running fine - with just a few little quirks (white noise on headphones, numlock doesn't work, brightness buttons don't work).

I want to move over to an upstream kernel (4.6x probably) so we can get more support in getting the little things working, but I don't know what the next step should be. I tried installing kernel 4.6.0 and adding the grub command, but no luck - still hangs after logging in. 4.3.5 is the newest kernel I've been able to get working.

I also see that this issue was marked back to "incomplete" rather than "confirmed". I'm not super able with Ubuntu, but I can follow instructions just fine. What needs to happen to get a newer kernel booting on this laptop?

tiJoe (josephbergevin), so your hardware is tracked, it will help immensely if you filed a new report with the Ubuntu repository kernel (not mainline/upstream) via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.

tiJoe (josephbergevin) wrote :

Thanks penalvch! I tried that and got the following error:

```Problem in linux-image-4.3.5-040305-generic

The problem cannot be reported:

This is not an official Ubuntu package. Please remove any third party package and try again.```

Is there some way to figure out which package is causing this issue?

Adric Norris (landstander668) wrote :

@tiJoe You'll get that error if the kernel package came from kernel-ppa mainline (or was custom built, etc.), rather than an official ubuntu kernel package. I'm guessing yours came from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.3.5-wily/, which would explain the message.

I had to uninstall and boot from the official kernel (which took quite a few attempts, as the boot process usually hung), in order to submit the original bugreport.

tiJoe (josephbergevin) wrote :

Is there an official 4.3.5 kernel that I can load?

Adric Norris (landstander668) wrote :

I can't find one in the repository... only 4.4.0 builds. So I don't believe so. :(

tiJoe (josephbergevin) wrote :

Dang. Ok, then I'll load my 4.2.0-42 official kernal that came with my 14.04 installation and report the bug that way I guess. The 4.4 official version that came with 16.04 wouldn't load at all, so that's not even an option... Sheesh.

Adric Norris (landstander668) wrote :

The stock linux-image-4.4.0-38-generic image seems to boot and work fine here, *provided* that the "nouveau.modeset=0" boot parameter is used. The easiest way to do this is via the GRUB_CMDLINE_LINUX setting in /etc/default/grub.

$ grep ^GRUB_CMDLINE_LINUX= /etc/default/grub
GRUB_CMDLINE_LINUX="nouveau.modeset=0"

Please note that you'll need to run "sudo update-grub" after making the change, or the parameter won't actually be passed at boot time.

tiJoe (josephbergevin) wrote :

ok, can you point me to where to download the stock linux-image-4.4.0-38-generic kernel? I removed mine when I thought it was useless to me...noob...

Adric Norris (landstander668) wrote :

It's in the normal Ubuntu repositories for xenial. Assuming that you haven't explicitly disabled them, You should be able to run "sudo apt-get update" followed by "sudo apt-get install linux-image-4.4.0-38-generic" to reinstall the beastie.

tiJoe (josephbergevin) wrote :

ok I got my computer to load up on the 4.4 kernel. But the screen res is locked in at 800x600. I have no trackpad (also tried a usb mouse and touchscreen with no luck), and no wifi. Nonetheless, I persevered and opened up my terminal to start a bug report, but I could only see the first couple of dropdowns on my screen - couldn't scroll. Also tried to run "xrandr -s 3840x2160" to manually set the screen res, but it said something like "setting not recognized". Kind of felt like I was missing a ton of drivers.

On the plus side, the 4.6.0-040600-generic kernel is working very well for me now, due to the magical grub line mentioned above.

At this point, should I move forward with reporting bugs "upstream" or should I mess with some things to try to get 4.4 working so I can report my bugs there?

What I really want at this point is to help make it so when others go to install Ubuntu 16.04 on an Asus Zenbook Pro UX501VW, it just works out of the gate. Just trying to be the best Ubuntu citizen I can be :)

chris (windybasket) wrote :

Hello all,
I have been working on this for two days now, and it seems that i slowly have made things worse as time has gone on. I had all of the problems stated (boot hang, blaring fan, white noise), but have found solutions to a few of them, and have information that could help pinpoint the others.

1. go to advance boot
2. linux 4.4 recovery works and does not have blaring fan.
2.5 linux 4.4 regular and upstart do not work
3. I have followed the instructions for archlinux which has solved the problem of the white noise in the earphones.
https://wiki.archlinux.org/index.php/ASUS_Zenbook_Pro_UX501

boot/fan:
After trying everything from reinstalling to boot-repair to fsck and all of the bios options (except flashing the bios, which I am possibly going to do a reinstall and flash the bios).

anyone have any more information, would be greatly obliged!

chris (windybasket) wrote :

noveau modset and apci=! didn't work, and my trackpad didn't work at regular boots (the 10% of the time I got it). recovery mode I have full use.
It may also be because I have two boot devices after boot-repair, ubuntu and windows, but I am not sure right now.

chris (windybasket) wrote :

More info,
Fixed boot problem, you need to go to recovery and go to software and updates/use nvidia video and intel cpu driver. Basically similar vein to noveaumodset=0. I have also removed the archlinux sound codes because I had worse audio whitenoise at regular bootup and when I did try to listen to something it didn't work. Hopes this helps someone. Cheers

chris (windybasket) wrote :

Hello, final solution is as follows:

In short, nouveau is making ubuntu freeze, so we're booting around it and choosing nvidia drivers to run after full install.

boot from usb
try ubuntu
install ubuntu from desktop, choose erase disk
restart
if at ubuntu 14.04,
sudo apt-get update
sudo apt-get upgrade
sudo do-release-upgrade
restart when needed

press esc at startup to get bios
move over to the far right tab and choose override boot to ubuntu
go to advanced options
go to recovery mode
go to search your computer, software and updates > additional drivers
choose nvidia and intel

After these steps the only thing not working for me was my earphones, which was detected but not outputting based on me plugging it in and out and watching my computer detect type of output in sound settings. Also had sound from the laptop speakers.

installed checkbox-qt via
sudo apt-get install checkbox-qt
ran checkbox from gui
restart and enjoy

chris (windybasket), to advise, WORKAROUNDs (i.e. having to boot into recovery mode to install drivers) isn't considered a fix, solution, etc.

Despite this, it will help immensely if you filed a new report with the Ubuntu repository kernel (not mainline/upstream) via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.

DAG (daarong) wrote :

My understanding is that this bug will soon expire because it's still marked incomplete and appears abandoned.

Are we taking this route because there is a workaround and in any case it should be filed differently than it has?

I do hope the workaround works - but cannot test it until another maybe couple weeks when I get the Asus laptop in question.

Andrew Carlson (andrewc0101) wrote :

This is really just a derivative of what has already been posted here, but I just completed a fresh install of 16.04 from flash drive and I thought that the exact steps I used would be useful to some people.

When you boot from the usb drive for a fresh install highlight the "Install Ubuntu" option and press the "e" key to edit this configuration.

Add the "nouveau.modeset=0" option on the linux line right before the "quiet" option so that it looks like the following.

linux /casper/vmlinuz.efi file=/cdrom/pressed/ubuntu.seed boot=casper only-ubiquity nouveau.modeset=0 quiet splash ---

Press F10 to boot and start the install.

Complete the install as normal.

When the installation is complete and it boots highlight the Ubuntu option in the grub menu and press the "e" key again.

Edit the linux line to add the "nouveau.modeset=0" parameter again.

After this boot succeeds edit the /etc/default/grub file and edit the following line.

GRUB_CMDLINE_LINUX_DEFAULT="nouveau.modeset=0 quiet splash"

Run sudo update-grub once this is complete.

Now this parameter should be set every time you boot.

I agree that this is just a workaround and not a true fix. Hopefully the fix isn't too far away.

Adric Norris, to keep this relevant to upstream, one would want to periodically check for, and test the latest mainline kernel (now 4.9) as it is released.

Could you please advise?

description: updated
tags: added: bios-outdated-304
removed: bios-outdated-300
tags: added: kernel-bug-exists-upstream-4.7-rc2 needs-upstream-testing
removed: kernel-bug-exists-upstream
Adric Norris (landstander668) wrote :

I can confirm that the "nouveau.modeset=0" workaround is still required with the 4.9 mainline kernel.

Adric Norris (landstander668) wrote :

As an addendum to my previous update, my ZenBook UX501VW has been upgraded to 16.10 (Yakkety).

tags: added: kernel-bug-exists-upstream-4.9
removed: kernel-bug-exists-upstream-4.7-rc2
Changed in linux (Ubuntu):
importance: High → Low
tags: added: yakkety
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
Adric Norris (landstander668) wrote :

.This is definitely still an issue

Adric Norris (landstander668) wrote :

For what it's worth, the "nouveau.modeset=0" workaround is still required for the 4.10.1 kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10.1/

Adric Norris, could you please advise to 4.11-rc1?

tags: added: kernel-bug-exists-upstream-4.10.1
removed: kernel-bug-exists-upstream-4.9
Adric Norris (landstander668) wrote :

The situation seems to be somewhat improved in 4.11-rc1, but still far from completely reliable. Out of 3 boot attempts with the workaround removed, 1 was successful... the other 2 hung (seemingly) just as before. While this is certainly encouraging, it appears that "nouveau.modeset=0" is still required for the machine to consistently boot successfully.

Adric Norris, the next step is to fully commit bisect from kernel 4.3.5 to 4.4 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

Please note, finding adjacent kernel versions, or providing a commit from a kernel version bisect is not fully commit bisecting.

Also, the kernel release names are irrelevant for the purposes of bisecting.

It is most helpful that after the fix commit (not kernel version) has been identified, you then mark this report Status Confirmed.

Thank you for your help.

tags: added: kernel-bug-exists-upstream-4.11-rc1
removed: kernel-bug-exists-upstream-4.10.1 needs-upstream-testing
Adric Norris (landstander668) wrote :

I'll look into it. But honestly, this sounds like something outside the realm of what I'm currently able to do.

baximus (baksbigboy) wrote :

the bug reproduced on ubuntu 18.04

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers