Nouveau - works in Stretch, not in Buster

Everything about X, Gnome, KDE, ... and everything running on it

Nouveau - works in Stretch, not in Buster

Postby dajames » 2019-08-24 16:54

I have an older PC that I use partly for testing. I have a Debian 9 (Stretch) system for that PC that works fine and that -- as far as I can recall -- required no special messing around to get it to work.

The machine has nVidia onboard graphics using the GeForce 6150 chipset (partnered with the nForce 430 CPU chipset). The monitor is a Dell U2410 whose native resolution is 1920x1200 at 60Hz. The monitor is connected via analogue VGA (through a 4-way switch box I don't want to replace, so switching to DVI isn't feasible). I'm using the Nouveau drivers.

inxi says this:

Code: Select all
daniel@welly-stretch:~$ inxi -G
Graphics:  Card: NVIDIA C51PV [GeForce 6150]
           Display Server: X.Org 1.19.2 drivers: nouveau (unloaded: modesetting,fbdev,vesa)
           Resolution: 1920x1200@59.95hz
           GLX Renderer: Gallium 0.4 on NV4E GLX Version: 2.1 Mesa 13.0.6


I've recently carried out a fresh installation of Debain 10 (Buster) on that machine (on a new hard drive, I still have the Stretch installation). That worked -- once I'd added "noapic" to the kernel commandline, which wasn't necessary under stretch (under Stretch I got an error message about it the sync'ing a timer every time I booted, under Buster it doesn't boot) -- but I've been have been having difficulties with the graphics.

At first, I was able to boot to a full-screen graphical login screen, but after logging in, when the screen attempted to diisplay the desktop, the monitor appeared to lose sync (?) and the image became garbled. The software appeared to be working but the screen wasn't readable (right-clicking produced a streak on the display that was probably an attempt to display a context menu, and hitting ESC made that go away again).

I overcame that problem by adding a nomodeset parameter to the kernel commandline. That gave me a 1280x1024 login screen (leaving the sides of the screen blank) and when I logged in I got a 1280x1024 desktop, which is usable but not full-screen, and not the native resolution of the monitor.

On Stretch, xrandr lists all the display modes I'd expect:
Code: Select all
daniel@welly-stretch:~$ xrandr -q
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 4096 x 4096
VGA-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200     59.95*+
   1600x1200     60.00 
   1280x1024     75.02    60.02 
   1152x864      75.00 
   1024x768      75.03    60.00 
   800x600       75.00    60.32 
   640x480       75.00    59.94 
   720x400       70.08 
DVI-D-1 disconnected (normal left inverted right x axis y axis)
TV-1 disconnected (normal left inverted right x axis y axis)


I've tried to use xrandr to set the modeline for the mode I want to use, as follows:

Code: Select all
daniel@welly-buster:~$ xrandr -q
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 320 x 400, current 1280 x 1024, maximum 1280 x 1024
default connected primary 1280x1024+0+0 0mm x 0mm
   1280x1024      0.00*
   1024x768       0.00 
   800x600        0.00 
   640x480        0.00 
   640x400        0.00 
   320x400        0.00 
daniel@welly-buster:~$ cvt 1920 1200
# 1920x1200 59.88 Hz (CVT 2.30MA) hsync: 74.56 kHz; pclk: 193.25 MHz
Modeline "1920x1200_60.00"  193.25  1920 2056 2256 2592  1200 1203 1209 1245 -hsync +vsync
daniel@welly-buster:~$ xrandr --newmode "1920x1200_60.00"  193.25  1920 2056 2256 2592  1200 1203 1209 1245 -hsync +vsync
xrandr: Failed to get size of gamma for output default
daniel@welly-buster:~$ xrandr -q
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 320 x 400, current 1280 x 1024, maximum 1280 x 1024
default connected primary 1280x1024+0+0 0mm x 0mm
   1280x1024      0.00*
   1024x768       0.00 
   800x600        0.00 
   640x480        0.00 
   640x400        0.00 
   320x400        0.00 
  1920x1200_60.00 (0x3ae) 193.250MHz -HSync +VSync
        h: width  1920 start 2056 end 2256 total 2592 skew    0 clock  74.56KHz
        v: height 1200 start 1203 end 1209 total 1245           clock  59.88Hz
daniel@welly-buster:~$ xrandr --addmode default "1920x1200_60.00"
xrandr: Failed to get size of gamma for output default
daniel@welly-buster:~$ xrandr --output default --mode "1920x1200_60.00"
xrandr: Failed to get size of gamma for output default
xrandr: Configure crtc 0 failed
daniel@welly-buster:~$


The display flickers on the last call to xrandr, but stays in 1280x1024 mode.

There are a number of issues, here:
  • Screen 0 is called "Default" rather than "VGA-1", which suggests that it hasn't been recognized correctly.
  • Each invocation of xrandr produces an error about getting the gamma for the output device.
  • The final call to xrandr produces the "Configure crtc 0 failed" error message. I've been unable to learn exactly what that means or what causes it.

Nevertheless, xrandr seems to accept the --addmode call, but fails to set the resolution using the new modeline (I can use xrandr to switch to a lower resolution and back again).

Comparing the Xorg.0.log files from the two machines I see very few differences until, on Buster, I see this:

Code: Select all
[    40.151] (EE) NOUVEAU(0): Error creating GPU channel: -19
[    40.151] (EE) NOUVEAU(0): Error initialising acceleration.  Falling back to NoAccel
[    40.151] (**) NOUVEAU(0): [COPY] acceleration disabled


I've been unable to learn what might cause an error creating a GPU channel, or what error -19 means.

I'm avoiding posting the whole of either Xorg.0.log as they're pretty big, but I can if necessary. In particular I do see, on both systems, that the monitor is recognized and that its EDID code is reported, along with all the modes (including 1920x1200) that I expect to see.

Neither machine has any xorg.conf file, nor any files in /usr/share/X11/xorg/conf.d beyond those that are installed by default.

As I said, I'm using the Nouveau drivers. I'm happy with those if they work. I don't use 3D or require more video acceleration than I'm getting. I did look at the possibility of using proprietary drivers. but nvidia-detect says that I need the 304 legacy drivers, and that they are not supported under Buster?

Code: Select all
daniel@welly-buster:~$ nvidia-detect
Detected NVIDIA GPUs:
00:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51PV [GeForce 6150] [10de:0240] (rev a2)

Checking card:  NVIDIA Corporation C51PV [GeForce 6150] (rev a2)
Your card is only supported by the 304 legacy drivers series, which is only available up to stretch.


What else can I try?
dajames
 
Posts: 5
Joined: 2012-10-01 07:47

Re: Nouveau - works in Stretch, not in Buster

Postby stevepusser » 2019-08-24 17:45

Some Nvidia cards require firmware-misc-nonfree, even with the nouveau driver. You could install that to see if it makes any difference after a reboot, and remove it if it doesn't.
The MX Linux repositories: Backports galore! If we don't have something, just ask and we'll try--we like challenges. New packages: Calibre 3.48.0, QMPlay2 19.09.03, wine-staging 4.16, Telegram-desktop 1.8.8, Pale Moon 28.7.1, Waterfox 56.2.14
User avatar
stevepusser
 
Posts: 11097
Joined: 2009-10-06 05:53

Re: Nouveau - works in Stretch, not in Buster

Postby phenest » 2019-08-24 18:15

Would you need firmware for such an old card?

I have an nVidia 6600 and 7600 with similar problems.
ASRock H77 Pro4-M i7 3770K - 32GB RAM - Pioneer BDR-209D
User avatar
phenest
 
Posts: 1703
Joined: 2010-03-09 09:38
Location: The Matrix

Re: Nouveau - works in Stretch, not in Buster

Postby dajames » 2019-08-24 22:13

stevepusser wrote:Some Nvidia cards require firmware-misc-nonfree, even with the nouveau driver.


Ah, yes, sorry.

I should have remembered to say that I have already installed the firmware-misc-nonfree package in the Buster installation, and it made no difference.
dajames
 
Posts: 5
Joined: 2012-10-01 07:47

Re: Nouveau - works in Stretch, not in Buster

Postby neodeb » 2019-09-07 17:38

DO NOT UPGRADE to Debian 10 Buster stable on your main systems; If you want the proprietary Nvidia 304 driver. Not compatible xorg etc..
(Where were the NVIDIA GPU warnings or 'time shift', Deb 9 restore abilities? Now, I have to migrate, many years, out of my fully upgraded Debian 10 non-working system.)
(And the complicated, separate /home folder debate for changing distros continues, as well)

I'm reporting: I can NOT get Nouveau to work in Buster stable Debian 10 either. I have a 304 nvidia GPU device built in. firmware-misc-nonfree installed

I spent days trying workarounds for some method of the faster nvidia 304 (foolishly not open sourced by EVIL nvidia and now stopped updating the Linux driver.)

I have seen Nouveau work on other systems ALMOST as good playing videos; but still stutters full screen 1080p. Great if Nouveau comes along but it's worse and they are saying newer Nvidia cards are locked out due to signing issues. Also I have seen Nvidia GPU chips fail a lot (unsolder etc and re-baked in my oven to prove it); far worse than other manufactures.

Plus; you need to keep the thermal paste fresh after several years (5 to 8?); which I do. if you start having overheat issues. Also you can add a fan to the GPU's without a fan.

Commentary:

So the thing is i have seen the darn thing work well without stuttering at 1080p and also play mid level 3D games. Last noted on stretch and older Linux Mint w/Mate. This required using the right software player for the popular compressed formats, their updated codex, and all planets aligned. Meaning some upgraded for Debian 9 started video stuttering; that no player setting (buffer etc.) could fix.

Politics: I'm well aware nvidia is an pain and no one should ever buy any product containing them. Countless hours wasted when the proprietary driver COULD be hacked to work well. And I know Debian (devs) is not responsible for Nvidia monopolistic Microsoft promoting lack of openness. So I spent days researching the following...

Debian 10 does conflict with Xorg 1.20 and ABI libraries; so nvidia 304 CAN NOT WORK WITH DEBIAN 10. Downgrading xorg is to complicated/unfeasible and Debian 9 (sadly) is the answer with a 304 nvidia GPU! I even tried the manual patched Nvidia 304 manual install (no PPA worked) that only partly worked in Mint 19.2! Though mint 19.2 has xorg 1.29 and matched; it has other problems and does not play video files. It only works with you-tube. So while I thought mint 19 was the answer it is also too new (due to the ABI's it says and this somehow kills playing vids. I have not determined if mint 18, 17 or 16 is best for 304 nvidia (if anyone knows). We have the problem of one of them working and then not working and then working again. So when matters.

So I hope you can see how this Nvidia driver issue is taking me away from my beloved Debian. Maybe a few more years for this GPU in Mint of some version. It just feels like Debian 9 is going back. Because it is. A Mint release (18? 17?) is like a MORE upgraded Debian 9 at this point. But it's a choice.

Of course a donated, under $30 used, or $50 sale AMD GPU is the answer if you have a slot. And don't play heavy games. Or Intel open GPU; but slower. Because these fine working old computers (including built in Nvidia devices) are not worth spending even that much or even any amount; when those funds can go into a new matched system. This is why we just need them to do the best they can and live-on UNTIL they are really obsoleted. Because now you get Nvidia refusal; and now the latest distro releases moving on.

While no distro should be held back and eliminating Nvidia is my goal (and should be yours); we should still have a way for the newest upgraded distro releases to WORK, as best they did; and we know they can.

Sadly, with a 304 card you have to use an older release distros. Old stable gets old. After 2019 (about 3 more months to this date) the next newer legacy Nvidia GPU has the same problem. You know those are even more capable GPU's. Which for now, some OLDER distro releases are kept up; but soon (a year?) they will be garnering to little attention. Thus more instability.

My question is why does the lack of highest end gaming mean xorg can't have a diversion for old cards that work perfectly fine. I have recently seen the thing play 1080 just fine; why digress and let nvidia win? This is fixed for other old proprietary devices. Because stuff just has to work; even though it's not fair what nvidia does. I'm concerned we are helping Nvidia obsolete devices; because we know they should not fail to release the development to open coders; if they will not do it. I do not think xorg locking (or whatever) locking older legacy cards out with the new Debian 10 is the way to go. We can retain our principles and FORK IT. So as not to lose all the work put into Debian 10. AND this will of course will filter-out badly otherwise, to Ubuntu/mint in time.

Because Debian just got harder. That's not a good principle we're protecting. Old Nvidia card are out there and smart people are not buying ANY more Nvidia. We need to support what is. Not what we hope is. I don't think we are helping Nvidia by forking Deb 10 to work with legacy cards. Too many people still use. The definition of planned obsolescence.

So if we don't make a work around are we partners in crime? I think so. We then help obsolescence before its time! And if we make it automatic have we helped nvidia get away with anything? I think not.

But should we tell all; that Nvidia has had there chance and never to buy from them. Heck yes! It's to late for Nvidia! It's ridicules. 1. poor support. 2. Not open. 3. Obsolete drivers. 4. Failing chips and build quality. 5. Close hardware/OS bias.

But why also through the baby out with the pixelated GPU bathwater? They are not unable. That's what's most egregious. Like a car, that mandates premium fuel; but then stop selling premium fuel and pretend it's obsolete, so you will buy a new model. Not going to happen! Hacks aplenty. It's what we do!
Open is freedom.
neodeb
 
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

Postby neodeb » 2019-09-07 20:49

TESTING BELOW INSTRUCTIONS:

The damn thing will not boot to GUI. Just tried 6 times. Didn't change anything. Ugly graphics and now waiting long periods of time often does nothing, or just shows a cursor. The two times I did get it to boot it ran video well. But then EVERYTHING but the cursor movement locks-up. What the hell is going on with nouveau?

Update: Put an old 6000 series AMD card and Mint 19.2 just works(fixes the patched manual Nvidia driver that play web vids yet not video for the hard drive(missing abi's?). Debian (Dual booted) will not even boot to recovery console and allow Internet to change drivers. I've seen this problem off and on. I had every intention of staying with Debian 10 on that Nvidia box. Oh well. Actually; I have Debian 10 upgraded on another that worked with a older AMD built in GPU.

======================================================================
I'm just getting Nouveau to work with Debian 10 Buster and video is NOT stuttering! There was an apt upgrade that might have helped. I used smxi and sgfxi helper scripts. Google them and click to install them on your system if you wish. Note these require Internet to run and self upgrade. I do not know which made the difference; but here's what I finally did.

[Edit your grub line with "e" and remove splash, and add BOTH: nomodeset single (then press F10 to boot text and....]

[For wired network]:
Code: Select all
dhclient

[For wireless] Example: nmcli c up wifishare
Code: Select all
nmcli c up <YOUR_ssid>


Code: Select all
apt update && apt upgrade

For just sgfxi:
Code: Select all
cd /usr/local/bin
wget -O sgfxi smxi.org/sgfxi
chmod +x sgfxi

Probe for devices and write an xorg.conf file:
Code: Select all
X -configure

This will fall back low graphics, then reboot, test it or edit your grub line again for booting to login/recovery:
Code: Select all
sgfxi -N vesa

This says it cleans up and leaves Nouveau.
Code: Select all
sgfxi -!32

Reboot without editing your grub line this time *and*....
It may go funky video lines for a minute; WAIT FOR IT. Bam! Nouveau works. (but didn't stay working)

At least this will help you will a saner way to test different drivers, GPU,s and releases; via sgfxi.
Last edited by neodeb on 2019-09-08 02:38, edited 17 times in total.
Open is freedom.
neodeb
 
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

Postby CwF » 2019-09-07 21:13

Just the other day I decided to make a backup image of my recently cleaned main hypervisor, a stretch with 2 nvidia gpu's. I used a competing hypervisor image that I just backed up after finishing working on it in another machine, an amd 3x gpu buster. It has booted the nvidia box before, has the info to configure to it, and a user tailored for it, and it stalled....
Before the luks passphrase it returned 4-5 lines of nouveau gooblygook so I gave it a minute. It did figure whatever out and finally gave me a luks prompt after a few minutes. From there, all seemed normal. I had other things to do so I didn't investigate the new errors, I'll look for that once it's back in it's machine. About 6 months ago I did the same procedure and the hybrid stretch/buster of that moment didn't have the issue. I suppose this was before the last xorg update. Now, as I type out the issue I realize the nouveau complaint occurs before xorg enters, so I don't know? It was an iomem region error of some kind, oh well...

Overall, my recent experience does favor AMD again, for linux. Another vote is I run (ran) quadros for windows vm's, but on that competing amd box I use firepro sky gpu's and finally those drivers work for XP, so I'm set. So, with the new OS settled and bigger builds to come, I'll have a batch of nvidia's for sale...

I'll note the real first vote, over the last 2 years that stretch hypervisor has locked about 5 times, XFCE lost the host keyboard, sometimes the mouse too. Each time fully recoverable with mostly to totally clean shutdowns. Each time traceable to nouveau freaking out.

There is news that nvidia has released some helpful info recently and nouveau may improve soon? Or are we now at the point progress will be divided into wayland OR xorg?
CwF
 
Posts: 443
Joined: 2018-06-20 15:16

Re: Nouveau - works in Stretch, not in Buster

Postby neodeb » 2019-09-07 23:22

Thanks. So low mem error and freaky? Who know what's going on and how to fix it?
Open is freedom.
neodeb
 
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

Postby neodeb » 2019-09-08 05:22

I've followed this out to Debian dropped the 304 driver now at Debian 10; meaning it will never work (nvidia non-free) in Debian 10 Buster, due to xorg 1.20 leaving it behind.

Thoughts of switching to OLDER Mint or it's pattern OLDER Ubuntu (after their Debian sid derived past) is actually having the same problem.

Meaning LinuxMint 17.something (now all LTS versions) release would be the newest (yet to old for Mint to offer any more), to try for the Nvidia.304 class driver as it puts that in the Debian 9 originally derived class.

Also; the Ubuntu LTS version to try would be all the way back to 14.04 LTS.
https://askubuntu.com/questions/1164849 ... -04-failed
As folks are having the 304 proprietary driver issue/fail with 16.04 LTS and newer 18.04 LTS.

So Mint 17 or Ubuntu 14.04 is too old. You'd be better backing up and reinstalling Debian 9. So don't update past that with a 304 card.

The darn Nouveau driver is a great try; but it ALWAYS sucks. I thought it works, like for a second. I've just tired of it. Best wishes. It does not work.

All this ALSO starts going wrong for the next level (340?), less old Nvidia "legacy" GPU's by 2019's end! Nvidia 8000 model series I think.

1. Get a card (or system) that's not Nvidia. Beg, bargain or trade?
2. With 304 then you're stuck with Debian oldstable, 9 stretch, for stability. Which is fine now; but soon left out.
3. Good luck with Mint 19.2. I recommend Mate.
4. See if Mint makes it possible with their click to install driver manager.

Going back or waiting on Nouveau doesn't work well. But thank you for trying.

Conclusion is Debian 9 for the 304 driver to work. Where sgfxi helps get you there with relative ease. It's all about total system stability.

Of course I will NEVER buy a closed GPU. But we get stuff in trade and the darn thing CAN work. So you can say it's old and you can say Nvidia stopped; but that doesn't matter. Because it has NOT really become obsoleted just because new cards have improved. It's being cut down early, against owners choice, from poor support, closed hardware locking you and development out, and the newest OS's with xorg writing it off.

Now there's one possible, yet probably buggy solution I discovered; but did not finish:

I installed (in spare HD space, made into a new partition via gparted) Mint 19.2 (19.1 USB then upgraded to 19.2); like 5 days old Mint (Mate) 19.2. And it has xorg 1.19 yet; so that isn't the problem with 304. I think ABI's still are. The only PPA I found did not work on installing it. Is Mint working on a new one for their convenient hardware manager? In Debian that's sgfxi, for me. I don't know but it's blank in Mint 19.2 (all Mint is now LTS) now. Word on the street is the Nouveau driver in Mint 19.2 is still unreliable too. Try it. Perhaps it's least bad in mint. But anyway; I found a patch for the manual nvidia driver and installed all that. It WORKED, and felt like 304 did in Debian 9 Stretch(now old stable). But it would not play videos on your hard drive! Low end gaming was the same poor resolution(for speed); but for older, non demanding games only. NOW, I read there's a package you just need to reinstall; that the Nvidia installer messes up and then the video players should work. So you might try that; and so still be moving forward (cutting edge) and never back. I suspect that's not a perfect solution. It's going to be interesting to see; if Ubuntu and Mint come up with a NEW 304 solution, ongoing.

Mint versions vs. Debian's chart: https://askubuntu.com/questions/445487/ ... s-based-on

Mint to Ubuntu numbers here: https://en.wikipedia.org/wiki/Linux_Min ... on_history

And then there trying newer than 304 Nvidia drivers on 304 GPU's. I haven't tried that lately. I'm not sure that can work. Anyone?

NOTE:
Code: Select all
sudo apt --reinstall install libvdpau1
...Is the command after doing the patched Nvidia manual 304 install on Mint 19.2, for everything to work.
See: https://ubuntu-mate.community/t/nvidia- ... 4/16787/43

I PAINSTAKINGLY tried that patch on Debian (so you don't have to) and it definitely does not work. Xorg 1.20 locks out Nvidia 304 in Debian 10. Probably forever.

My replacing nvidia with an old AMD just worked automatically (I uninstalled nvidia drivers before switching cards) on Mint 19.2. I can't even get back to the working recovery console in Debian 10. Recovery only works sometimes??? When ever I get in; I'll try sgfxi for the AMD GPU. Preferring the open drivers.

This is what happens when AMD works with open devs and Nvidia is a monopolistic, closed off, asinine bunch of robbers. Justice is bigger than all suffering, ever.
Open is freedom.
neodeb
 
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

Postby phenest » 2019-09-08 16:43

@dajames:
Is your video card an nVidia GeForce 6150. Is that AGP based or PCI-Express? It sounds old to me, so I'm guessing AGP.
AGP based cards are no longer supported by nVidia nor ATI/AMD.
ASRock H77 Pro4-M i7 3770K - 32GB RAM - Pioneer BDR-209D
User avatar
phenest
 
Posts: 1703
Joined: 2010-03-09 09:38
Location: The Matrix

Re: Nouveau - works in Stretch, not in Buster

Postby sunrat » 2019-09-08 22:48

phenest wrote:@dajames:
Is your video card an nVidia GeForce 6150. Is that AGP based or PCI-Express? It sounds old to me, so I'm guessing AGP.
AGP based cards are no longer supported by nVidia nor ATI/AMD.

It's 15 years old and built in to the motherboard from what I can ascertain. I would recommend an older distro or a newer motherboard. If the mobo has a PCIe slot you could try a new graphics card.
As you say it works in Stretch, use Stretch.
“ computer users can be divided into 2 categories:
Those who have lost data
...and those who have not lost data YET ”
Remember to BACKUP!
User avatar
sunrat
 
Posts: 2796
Joined: 2006-08-29 09:12
Location: Melbourne, Australia

Re: Nouveau - works in Stretch, not in Buster

Postby neodeb » 2019-09-09 19:34

My main system had a Nividia built-in (used for years) and I had a similar "304" class PCI-E Nvidia used instead in the slot, for it's DVI out adapted to TV with only HDMI.

Now I find an old AMD HD6670 (TURKS XT) with HDMI, and is not bad after-all; automagically in only Mint 19.2. (I made a 15GB partition in my Deb system HD space to test/compare it, installed). Both Buster based.

I thought my spare AMD GPU card was bad, as it would not (recent past, Deb 9) do anything; but black text flickering screen. Still doesn't in Debian 10.

So, it's fabulous on Mint 19.2 and I have done every trick in the book(via nomodeset in GRUB; to repair) to make it also work in Debian. It does not.

HD6670 (replacement) Debian 10:
1. Blacklisted Nouveau. Several ways and rechecked it.
2. Removed all drivers and installed AMD packages required.
3. Tweaked all configs and nothing but a boot to black (after initial text) as lightdm loops; and requires power switch off, without nomodeset.

What could be the reason?

And I do have the BIOS set for PCI-E only.
Last edited by neodeb on 2019-09-09 20:39, edited 1 time in total.
Open is freedom.
neodeb
 
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

Postby phenest » 2019-09-09 19:54

What driver is Mint using? Can you be sure it's the correct one? It might be using VESA.
ASRock H77 Pro4-M i7 3770K - 32GB RAM - Pioneer BDR-209D
User avatar
phenest
 
Posts: 1703
Joined: 2010-03-09 09:38
Location: The Matrix

Re: Nouveau - works in Stretch, not in Buster

Postby neodeb » 2019-09-09 20:51

Thanks; but oh no. I compare heavily; but to be sure then what is the best way to verify it's not trying VESA (because VESA worked at low res, fallback).

It (Mint 19.2) does not have a xorg.conf file.

It has radeonfb blacklisted, and I tried (deb 10) as not blacklisted.

I also tried the normally allowed vesafb blacklisted. Framebuffer isn't the issue. Just checked it; in case.

Mint uses the Radeon open driver (and parts) and was automatic.

I compared all blacklisted and loaded drivers and tried them in Deb 10; to no Lightdm starting solution.

Yes; I made sure the ati and radeon open drivers were installed and reconfigured. I even broke my system completely removing the video driver as it removed half my system without asking/showing me first.
READ THIS if you delete half your system tryng to fix it...
I fixed that well, from deep geek methods of finding what got deleted in /var/log/apt/history.log

Code: Select all
awk '!/^Start|^Commandl|^End|^Upgrade:|^Error:/ { gsub( /\([^()]*\)/ ,"" );gsub(/ ,/," ");sub(/^Install:/,""); print}' /var/log/apt/history.log

...Is the diddy that saved me. I devised and way to reinstall the numerous deleted packages; made from 3 different ways found online (THANK YOU).

You still have to edit the resulting file to pick out the session/packages that caused the deletions. And you want to get this file on a GUI system for easily doing that. Start after the Removed: section, in your session at or near the end of the packages extracted to the file. Name the edited/reduced file "packs" Then I came up with...

Code: Select all
apt install (cat packs)

Your files of just removed (and edited) packages "packs"; being in the director path. I just used /root folder.
And it WORKS; after you run it, go back and edit it a few more times, for any packages no longer available. Even in the console
Code: Select all
nano packs
and then using Ctrl+W to find each outdated pack to remove, can be done fast. (remember I still have no GUI with Debian 10 + AMD card). Then with your Internet up it reinstalls everything apt deleted. I still don't know how I missed a wall of packages to be removed. I tell you; it didn't show me. SO this is not relevant unless you delete half your system; but if you do then it's REALLY relevant.


Commandline: apt-get purge firmware-linux-nonfree libgl1-mesa-dri xserver-xorg-video-ati

...Did it. (Don't do that)

Commandline: apt-get install firmware-linux-nonfree libgl1-mesa-dri xserver-xorg-video-at

...Did NOT fix it.
So yes I made sure all the related firmware files are also installed. Mesa utilities also.

My solution here was to use a AMD card in place of Nvidia-304. It only works in Mint though.

Tally:
Nouveau does not work.
Nvidia-304 is not supported by Debian 10.
AMD HD6670 (open drivers!) in my Debian 10 does not work. (Mint does)

Why not the AMD open drivers Debian 10?
Last edited by neodeb on 2019-09-10 03:35, edited 2 times in total.
Open is freedom.
neodeb
 
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

Postby sunrat » 2019-09-09 22:28

neodeb wrote:what is the best way to verify it's not trying VESA (because VESA worked at low res, fallback).

To check what driver your GPU is using:
Code: Select all
$ lspci -k |grep -A 3 VGA


or if you have inxi:
Code: Select all
$ inxi -G
“ computer users can be divided into 2 categories:
Those who have lost data
...and those who have not lost data YET ”
Remember to BACKUP!
User avatar
sunrat
 
Posts: 2796
Joined: 2006-08-29 09:12
Location: Melbourne, Australia

Next

Return to Desktop & Multimedia

Who is online

Users browsing this forum: No registered users and 9 guests

fashionable