10

Ok, so, like many others I'm having a lot of trouble with NVidia drivers, in this case, the new 340.32 ones downloaded from here (http://www.nvidia.com/object/unix.html), but I've had these problems across the board with pretty much all versions.

So, this is currently where I'm at, as far as I can tell, the driver is installed fine, but if I let Ubuntu try to boot normally, I end up at a blank screen and nothing ends up getting displayed. No run level changes work, it's completely locked up, yadda yadda.

If I boot into recovery mode and then resume the boot (with no other changes, I literally just hit "resume boot"), everything seems to work fine.

So I'm assuming that something is starting up with a regular boot that doesn't start up with a recovery boot (there is, obviously, a warning for such when resuming the boot), but I have no idea what or how to diagnose it.

Here's the other major symptom, nvidia-settings launches fine & I can save the xorg.conf file in /etc/X11 with no problem (without merging). However, when I perform a recovery boot, the system has lost any of the changes I made to the configuration, so I'm guessing something isn't reading the xorg file or something like that.

Ubuntu 14.04, kernel 36.
NVidia drivers 340.32 (but happens with all versions that I've tried, even back to 3.04)
2x EVGA NVidia 780 GTX (connected with an SLI bridge) with 2 WQHD Monitors both driven from Card 0, plus an Oculus Rift DK2 that I keep disabling from NVidia Settings but which keeps showing up as active every time I reboot (the problem predates the Rift, so I suspect this is a symptom and not a cause).

Any ideas? How do I even begin to figure out what's tripping the damned thing up on boot?

Thanks.

VFXGordon
  • 141
  • Ok, it appears to be tied to this error in the Xorg.0.log file

    "EVO Push buffer channel allocation failed"

    Looks like it's related to systems starting up too quickly, so I guess I have to delay something or other to give X a chance to catch up.

    This explains why recovery boot is working fine, it's not getting away from itself.

     – VFXGordon Sep 24 '14 at 03:34

5 Answers5

9

This could be fixed by adding the nomodeset value to the grub boot options. To do so open the file:

gksudo gedit /etc/default/grub

then look for the line GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

The quiet splash options may or may not be there, and there may be additional options, don't touch those and add to the end of it nomodeset

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

Save the file and exit gedit, then update grub's configuration in the following way:

sudo update-grub

Source: happened to me

Erdorath
  • 429
  • 2
  • 6
  • 1
    No dice, I tried adding nomodeset, but I get the same behavior, system just locks up when it should display the desktop. Thanks for the suggestion though, I hadn't tried that yet. – VFXGordon Sep 24 '14 at 02:48
  • 1
    ok, the only thing I can think of apart of that is to do the same thing and remove the quiet splash line. That way you will see all the console output while it boots and hopefully it will give a usefull error that can help narrow down the search. – Erdorath Sep 24 '14 at 05:22
  • Yeah, I finally got the damned thing working with an ugly fix, but thanks for the help, I was about 20 minutes away from sacrificing a live chicken. – VFXGordon Sep 24 '14 at 06:17
  • This worked for me with Linux Mint 17.3, a Geforce GTX-750Ti, and an SSD boot drive. Thanks! – procrastinate_later Jan 24 '16 at 23:15
  • Note that you can type 'e' when you are at a grub boot menu, and edit the line that starts with "linux" to add nomodeset. This will let you try the change once without making it permanent. – procrastinate_later Jan 24 '16 at 23:21
4

Ok, so it seems this is actually less to do with the NVidia cards and more to do with the fact that I'm using an SSD as a system drive.

As I understand it, the problem is that it's trying to start lightdm before the video card has finished initializing or some such nonsense.

It's a big problem on Macs; https://devtalk.nvidia.com/default/topic/573252/linux/evo-push-buffer-channel-allocation-failed-is-back-as-usedplib-false-no-more-supported-with-325-15/4/

I've tried a LOT of fixes related to the EVO Buffer problem, but it seems that most of them don't work with Ubuntu.

Seems the only thing that works is to deliberately give the system time to catch up before trying to launch lightdm.

So, in /etc/init.d/lightdm.conf, locate the line that says:

exec lightdm

.. and simply change it to:

sleep 2
exec lightdm

It's an ugly, kludgy fix, but I have no idea how to go about telling lightdm to wait for the cards.

Incidentally, not sure what the fix for the xorg.conf file was, I'd read that copying it to /usr/lib/X11/xorg.conf.d was more reliable and that setting the screens using the Ubuntu display manager was more reliable.

I did both, one of them worked, but I couldn't tell you which one.

VFXGordon
  • 141
  • wow, ok, that will be helpfull for me too when I finally switch to an SSD. Ugly indeed, but hay, if it works :) (remember that you can mark your own answer as solution so that the question is closed) – Erdorath Sep 24 '14 at 07:00
  • Yep, will do, apparently it's making me wait until tomorrow before I can do that :) – VFXGordon Sep 24 '14 at 07:26
  • I have Linux Mint 17.3, an SSD boot drive, and a GTX 750Ti, so I was going to try this. However, I tried adding nomodeset first (erdorath's answer) and it worked for me. – procrastinate_later Jan 24 '16 at 23:18
  • Finally! A looked forever for a solution for this. I reinstalled almost every version of Nvidia drivers there is and tried many kernel configurations. But this simple hack saved my life. Anyway, this answer is a bit old so you might want to add an update for the latest Ubuntu version as suggested in my answer below. – Liran Funaro Jun 25 '20 at 19:30
1

Assuming you have a Grub bootloader:

Boot into Ubuntu Recovery mode.

Open Grub Customizer:

sudo grub-customizer
  1. Create a copy of your normal boot (just to be safe) and call it Ubuntu-NVidia.
  2. Edit the Ubuntu-NVidia boot: remove the line containing: gfxmode $linux_gfx_mode
  3. Save your Grub Config
  4. Reboot
  5. Select the Ubuntu-NVidia boot
  6. Your NVidia drivers should be loaded and your desktop should be showing now.

This worked for me on the following configuration:

  • Dell XPS17 (L702X 2011 model)
  • SATA SSD
  • GeForce GT 555M using NVidia driver 390.132
  • Ubuntu 20.04 (LTS) Linux 5.4.0-37-generic
  • GRUB 2.04
Scott Stensland
  • 15,575
Vorster Swanepoel
  • 11
1

VFXGordon answer solved the issue for me, but it is a little outdated due to filename and command changes that happened since Ubuntu 14.04.

For Ubuntu 20.04 the solution is as follows:

  1. In /etc/init.d/lightdm, locate the line: 
       start-stop-daemon --start --quiet $SSD_START_ARGS
  2. And change it to: 
       sleep 2
   start-stop-daemon --start --quiet $SSD_START_ARGS

The explanation for this solution can be found in VFXGordon answer.

Liran Funaro
  • 111
1

I had similar problems with the NVIDIA driver initially in my machine. I switched to NVIDIA's legacy driver version 173.1439. It seems a lot more stable in two weeks of use. I found it as the second choice in Software & Updates – Additional drivers. This option replaces your driver but you can roll it back if need be.

onedaveolder
  • 25
  • I tried going with the 304 legacy driver, and it would boot to a low res login screen, but wouldn't let me go any further than that. I checked the kern.log file and found it complaining that the NVidia card wasn't supported by the 304 driver, so the 173 driver (which is earlier) isn't likely to work either. Thanks for the suggestion though. – VFXGordon Sep 24 '14 at 04:04