I'm happy to report that I got things working, after several days with
nothing working.
To get it to work I needed to create a little xorg.conf
Section "Device"
Identifier "Proprietary"
Driver "nvidia"
VendorName "NVIDIA Corporation"
EndSection
and to comment out the entire contents of (package: file)
xserver-xorg-video-nvidia: /etc/nvidia/current/nvidia-drm-outputclass.conf
to avoid failures from syntax errors.
This worked only after I removed my computer's battery and reset the
BIOS, which had been acting funny.
Ross
P.S. I tried with an xorg.conf that used the vesa driver, but that
didn't work. Key part of the log
[ 154.321] vesa: Ignoring device with a bound kernel driver
[ 154.321] (WW) Falling back to old probe method for vesa
[ 154.321] (II) UnloadModule: "vesa"
[ 154.321] (EE) Screen(s) found, but none have a usable configuration.
[ 154.321]
I guess the nvidia kernel module had claimed the device.
On Mon, Jan 4, 2016 at 8:59 AM, Ross Boylan
<rossboylan at stanfordalumni.org> wrote:
> After a brief flash of success I'm now pretty much unable to access
> the system, meaning both that the display is blank and that I can't
> ssh in, possibly because the system isn't coming up. I can't think of
> any good reason there should be any connection between video and
> networking, but there seems to be one.
>
> I've attached the log (mailing list permitting) from a graphical 8.2
> system trying to start up without the proprietary drivers. I created
> it from a Debian live system's installer on the same USB, and have
> been using it in a different computer. I stuck it in the system with
> the graphics card. X throws an exception at the end.
>
> Vanilla Debian 8.2 doesn't seem to like the system, although I was
> able to run the installer and put a fresh system in some spare space.
> The test system was text only; I am attaching to the 980Ti via DVI. I
> didn't see anything in the logs that looked like a showstopper for the
> system, but here are some highlights (copied by hand because of the
> previous problems):
> ACPI warning: SystemIO range nnn-nnn conflicts with OpRegion mmm-mmmm
> (\_SB_.PCI0.SBUS.SMBI) (20140424/utaddress - 258)
> #many messages similar to above
> If an ACPI driver is available for this device you should use it
> instead of the native driver
> # not clear what device is meant, but this was shortly after
> mentioning the video hardware
> [drm] replacing VGA console driver
> [drm] GMBUD [i915 gmus vga] timed out, falling back on bit banging on pin 2
> i915 no connections reported
> console switching to colour dummy device 80x25
> # if output is going to a dummy device I guess that would explain why
> # the monitor is blank
> log entries on sound have some mentions of the PCI card
>
> Those entries were from an 8.2 live USB boot in "failsafe" mode, which
> produced a useable text console (though for some reason I couldn't get
> networking going). The 8.2 live in regular mode, like the system I
> installed fresh, had a black screen and no ssh in (or signs of dhcp
> requests out).
>
> Having started this message with the end state, let me give the
> history from the beginning, just after my previous message. I took my
> primary wheezy system, purged all the nvidia stuff, installed the
> backported 3.16 kernel, and rebooted. The I installed nvidia via a
> mix a packages I backported from experimental and binaries from
> backports. (Hmm, though I backported the packages under the old
> kernel).
>
> At first this failed because the syntactically incorrect xorg fragment
> had been reinstalled; it's owned by something like
> xserver-xorg-nvidia-driver (??). When I commented it out I got a
> blank screen. Then, via ssh, I dropped in a small xorg.conf that had
> "nvidia" as the device driver. X started with the logs showing the
> nvidia driver in use.
>
> I shutdown, switched to a monitor connected via displayport, and
> restarted. The screen was blank. I switched back to the old monitor
> with DVI connection (only one video connector was attached to the
> system at one time; always powered off while switching). No joy. I
> suspected the initrd's might have been incorrect (e.g., some nvidia
> package installed after they were created) and eventually managed to
> chroot in (from an 8.2 installation CD in recovery mode, I
> think--seemed to be the right kernel version, though since it wasn't
> wheezy that could have caused trouble). I updated grub, regenerated
> the initrd, and installed grub to the boot sector of one disk. It
> didn't help; in fact it may have been around this point that I lost
> the ability to ssh in.
>
> Some other things I noticed at various points:
> Sometimes the intel video driver showed chatter in the log. There is
> onboard Intel video; is it possible it was active and using its output
> (also DVI)? Is there any way to use the onboard video while the
> nvidia card is installed?
>
> Sometimes other drivers reported they would not touch a device that
> was already bound (approximately). So maybe the nvidia driver
> prevented others from being used as a fallback?
>
> I had some luck specifying "vesa" as the driver.
>
> nouveau generally was tried and, I think, rejected, as expected.
>
> vesa seemed to work, but often fb related (fbdev? fbgw?) seemed to end
> up getting control. I wasn't ever able to see the screen in that
> case. The logs would show lots of errors as fb tried to get
> information (the attached log has examples).
>
> I tried specifying blacklist=nvidia on the kernel options line (the
> grub line starting with linux). No help.
>
> The card has a DVI-X connector; the cable is plain old DVI.
>
> Thanks for any help.
>
> Ross
>
> * Even when I can see the screen in text mode, the fact that I can't
> get ethernet to work means I can't transfer files I want to save via
> net and I can't get the tools to partition the USB stick so I can copy
> files there. I talso suspect the live system may be blocking all of
> my writes, even to my regular disks, because I though I had put a
> modified xorg.conf in place (on my disk, not the live system) but
> didn't see it on reboot.
>
>
>
> On Sat, Jan 2, 2016 at 3:21 AM, Luca Boccassi <luca.boccassi at gmail.com> wrote:
>> On 2 January 2016 at 06:38, Ross Boylan <rossboylan at stanfordalumni.org> wrote:
>>> My screen is now blank, even in the alternate, textual VT's. The
>>> problem with the text VT's was happening before I installed the nvidia
>>> drivers, and so may be separate.
>>>
>>> After building a bunch of packages and dpkg -i them, on reboot Xorg.log shows
>>> [ 126.926] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
>>> [ 127.031] Parse error on line 7 of section OutputClass in file
>>> /usr/share/X11/xorg.conf.d/nvidia\
>>> -drm-outputclass.conf
>>> "OutputClass" is not a valid section name.
>>> [ 127.031] (EE) Problem parsing the config file
>>> [ 127.031] (EE) Error parsing the config file
>>> [ 127.032]
>>> Fatal server error:
>>>
>>> The full text of that conf file is
>>> # This xorg.conf.d configuration snippet configures the X server to
>>> # automatically load the nvidia driver when it detects a device driven by the
>>> # nvidia.ko kernel module. Please note that this only works on Linux kernels
>>> # version 3.9 or higher with CONFIG_DRM enabled, and only if the nvidia.ko
>>> # kernel module is loaded before the X server is started.
>>>
>>> Section "OutputClass"
>>> Identifier "nvidia"
>>> MatchDriver "nvidia-drm"
>>> Driver "nvidia"
>>> EndSection
>>>
>>> So it needs a newer X (I guess) and a newer kernel than I'm running.
>>> I see 3.16 is available from backports, but that still wouldn't take
>>> care of the X.
>>>
>>> Ideas? Maybe if I took more of the packages from older versions,
>>> i.e., backports for wheezy, things would work better.
>>
>> I forgot 3.2 was the kernel version in Wheezy main, sorry. To get the
>> autoload to work you'll need 3.16 from wheezy-backports, yes.
>>
>> But it should not need on a newer version of the Xorg packages. Also
>> the newer version of the driver packages does not need a manually
>> written xorg.conf anymore, the packages will create a minimal one that
>> is needed to load the driver at boot automatically.
>>
>> "Should" being the keyword here - once again, haven't backported to
>> wheezy before :-)
>>
>>> Partly because the apt-get source from experimental wasn't working, I
>>> downloaded the packages directly, did dpkg-source -x to unpack, and
>>> dpkg-buildpackage to build them. Then I used dpkg -i to install, and
>>> iterated as I dicovered dependencies.
>>>
>>> I got sources for
>>> glx-alternatives_0.7.1.dsc nvidia-graphics-drivers_352.63-1.dsc
>>> nvidia-support_20151021+1.dsc
>>> libvdpau_1.1.1-3.dsc nvidia-settings_346.59-1.dsc
>>> though nvidia-settings had build dependencies that prevented me from building.
>>>
>>> I ended up with
>>> dpkg -i \
>>> nvidia-installer-cleanup_20151021+1_amd64.deb \
>>> glx-diversions_0.7.1_amd64.deb \
>>> glx-alternative-mesa_0.7.1_amd64.deb \
>>> update-glx_0.7.1_amd64.deb \
>>> glx-alternative-nvidia_0.7.1_amd64.deb \
>>> nvidia-kernel-common_20151021+1_amd64.deb \
>>> nvidia-support_20151021+1_amd64.deb \
>>> nvidia-kernel-support_352.63-1_amd64.deb \
>>> nvidia-kernel-dkms_352.63-1_amd64.deb \
>>> libnvidia-ml1_352.63-1_amd64.deb \
>>> libcuda1_352.63-1_amd64.deb \
>>> libegl1-nvidia_352.63-1_amd64.deb \
>>> libnvidia-eglcore_352.63-1_amd64.deb \
>>> libgl1-nvidia-glx_352.63-1_amd64.deb \
>>> nvidia-driver_352.63-1_amd64.deb \
>>> nvidia-driver-bin_352.63-1_amd64.deb \
>>> xserver-xorg-video-nvidia_352.63-1_amd64.deb \
>>> libvdpau1_1.1.1-3_amd64.deb \
>>> nvidia-vdpau-driver_352.63-1_amd64.deb \
>>> nvidia-alternative_352.63-1_amd64.deb \
>>> libgles1-nvidia_352.63-1_amd64.deb \
>>> libgles2-nvidia_352.63-1_amd64.deb \
>>> nvidia-detect_352.63-1_amd64.deb
>>>
>>> Plus a few packages installed via aptitude, generally from backports.
>>
>> That looks correct. Sorry I forgot about nvidia-support and libvdpau,
>> as I said I was writing from memory :-)
>>
>> You shouldn't need a newer nvidia-settings, the one in
>> wheezy-backports should suffice. If you want a newer one, you can
>> build the jessie version.
>>
>> Kind regards,
>> Luca Boccassi