1: I installed the Liquoriz kernel. I then installed the AMD microcode because it seemed to be asking for it. Everything seemed fine so I went ahead to use sgfxi to install the graphics driver.

2: sgfxi fails to shut down the Mate display manager, so terminates X. Then while the driver is installing the display manager seems to respawn automatically. If I press ctrl-alt-F1 I come back to the sgfxi terminal output. Even so, the driver is reported to have installed successfully. When it asks to exit or start the display manager and I select display manager, it gives me something like "ignoring: appending to nohup.log".

The drivers and display work fine after this, but the themes no longer display correctly and it causes the following error.

I noticed that the first time installing that sgfxi said there was no xorg.conf file before it created one. However this computer has been running full graphics for some time now. I wondered if it was something like X pulling a GRUB2.

3: Whenever I try launching mate-settings-daemon the screen flashes and I get this:



I am not really sure who's bug this is, possibly both, but I thought it was appropriate to report it here.

I have several sgfxi logs from trying various things:

pastebin.com/8g5pKYML
pastebin.com/aWCE7ZmJ
pastebin.com/p73FJk4u
pastebin.com/0MtWhHrJ
pastebin.com/jgBPJqXR
pastebin.com/AiGwW139

At one point I purged and reinstalled X. After rebooting, Mint told me X could not run and needed configured, so had been disabled. This time I ran sgfxi and it worked without interruptions. The problem still was not solved. Booting into the standard kernel does not fix it either.

I would be very grateful to know how to fix this.
Back to top

sgfxi found this.

dmanCommand: stop mdm

in the logs. This means that sgfxi queried the default dm from xorg file, and got that.

So verify the following:

cat /etc/X11/default-display-manager

show me that output.

I'll add that to the logging, for some reason a flood of new dms are appearing, used to just be the same ones.

If that has any path other than /usr/bin that is the problem.

next verify that: /etc/init.d/mdm
exists.

Next, if both of the above are as expected, ie, /usr/bin/mdm exists and /etc/init.d/mdm exists, then type in this command:
/etc/init.d/mdm stop and see if the dm shuts down.

If it shuts down, then wait to see if it respawns itself. If it does, that is totally out of sgfxi's hands, that's a bug or problem with mdm, and I can't do anything about that.

If, on the other hand, mdm has a different path than /usr/bin/mdm, then I may have to redo that part of the detection in sgfxi and smxi, there's another one that appeared that doesn't follow the standard paths, kdm-trinity.
Back to top

It appears you were right about the different path.

Thanks for the help.
Back to top

that path would matter in smxi, but not in sgfxi.

That's not the problem, that's in $PATH.

The problem is what you said, mdm appears to be respawning itself for some weird reason.

GLX Renderer: N/A GLX Version: N/A Direct Rendering: N/A

means the nvidia driver while loaded is not actually working.

If you are in X, and you get that, it's somewhat odd, because usually that means the system reverted to the xorg driver, but inxi clearly shows that nvidia is the loaded driver.

So it's possible the respawning screwed up something, specifically, if it started after the nvidia driver tested for xorg or nvidia being loaded, then the nvidia install started, probably what happened is that xorg was in use and could not be overwritten by nvidia, or something like that, forcing a failure of the glx stuff.

If mint didn't use that absurd debian default of runlevel 2 for the desktop you could work around this easily by simply booting to runlevel 2, out of x, then starting the x runlevel, 3 or 5.

smxi has an option to switch that runlevel easily, but smxi does not support ubuntu, nor will it ever do so.
Back to top

Well is there another way I can revert or fix this issue? Reinstall the dkms drivers?
Back to top

you have to remember when using a frozen pool distro of any type, everything matches, when you move from say the kernel, then the non free video driver blob has to match, ie, it has to be the nvidia driver that supports that kernel.

There's a reason people use true rolling release stuff like debian testing and sid, and this is the reason.

So basically, roll back the kernel, install dkms nvidia and it should all work, make sure to of course uninstall the nvidia driver first if it's installed.

Other things you can do is:

go to the console, kill mdm manually, by: /etc/init.d/mdm stop
wait a while, see if anything restarts. Give it 5 minutes. If nothing restarts, the respawning may be triggered by something in the xorg things that the nvidia driver installer does, but I really can't tell you anything for sure, I'm seeing nothing but problems with the current ubuntu stuff, it's got a bunch of garbage running re the video drivers that I have zero interest in figuring out because it's all totally non standard. I'm keeping ubuntu support active in sgfxi for those users who want it, but I am not really going to spend a lot of time running after their constantly changing methods. But I did get reports a while ago about something really nasty in the way ubuntu is handling the non free video drivers now, far beyond dkms, and that's almost certainly what is causing the issues I'd guess.

In theory I should just dump ubuntu support, but there are some ubuntu users who run it without problems, I assume they have cleaned up that native ubuntu non free driver stuff or something so it works, but you'll have to figure that out for yourself if you want to go that way, if you find a simple fix that I can add to sgfxi as a check then fix if present, I can do that, but only if I'm told precisely what the issue is and how to resolve it, ie, code that works, or steps with commands, etc.

If it's just a matter of needing to remove an ubuntu nvidia package, then that's easy to add, but sgfxi already tests for and removes all packages detected with nvidia in the name, except for a list of whitelisted packages. Possible that ubuntu is using one of those names now for something that shouldn't be used. But I can't say.
Back to top

Okay, I did /etc/init.d/mdm stop and I got to a blank screen with a blinking cursor in the upper left. I had to do ctrl+F1 to get back to the terminal login.

I uninstalled the nvidia driver and all graphics related drivers, rebooted, and then reinstalled the dkms stuff from the terminal. That didn't work. I was looking through logs and found this:

pastebin.com/VmeQP0Xc

Here is the jockey-gtk log:

pastebin.com/cbxqfkPT

The dkms stuff still doesn't work when going back to the old kernel, but it looks like this may be a problem with Liquorix.

I found this:

forums.linuxmint.com/viewtopic.php?f=59&t=105485

So it seems the proper way to stop MDM is to ctrl-alt-F1 out of X and then service mdm stop.

It seems that MDM may be restarting in response to something sgfxi does, I will try to ascertain this.

When running sgfxi, when it begins installing the driver, it spits out a large portion of the jockey.log. I thought I had uninstalled jockey but maybe not. Perhaps jockey started in response to sgfxi doing something and then started mdm?
Back to top

jockey is a good guess for sure, that's almost certainly the cause, because ubuntu did something really ugly, not sure what, to attempt to make the non free video driver install work in x, and to be one click, as well as some other hacks, I haven't looked at it, but just looking at your debugger from jockey I am wincing, it's not even auto detecting card before looking for the fglrx package for example, painful.

If it's doing what dkms used to do, it's creating a bunch of auto trigger files that are NOT removed when the driver is removed, which then clutter up the system and cause subsequent issues and dm reloads and who knows what else. Sometimes it really does not pay to try to be too smart, that's been the driving point behind sgfxi since it was created. Sgfxi uses either strict standard direct install of nvidia driver, or build kernel module/rebuild, or, I think, if I remember right, install dkms sgfxi -d in ubuntu I want to say, I'd have to check.

Very painful stuff, let me know if you find out how to clear out the jockey junk, ideally you should be able to leave jockey and remove the driver. Maybe you have to use jockey to install it, then remove it. Who knows, it's almost certain the app is poorly written, in my opinion, failing to do clean uninstalls is a dead giveaway, that plagued debian's dkms for years, until it was finally fixed and made usable, for the first time, a few years ago.

This is by the way the second attempt made in ubuntu, the last one, I can't remember the name, envy maybe, was also a total mess, but that was someone's project.

It really works much better over time to just install the real drivers, or to use the regular now reasonably well working dkms stuff.

Or to build the module using some older techniques in debian, I think sgfxi still uses those, can't remember, haven't tested the stuff in a while.
Back to top

I just did some experimenting:

"stop mdm" does not work.
"mdm stop" causes mdm to "abort" something.
If I do it again afterwards, MDM restarts.
"service mdm stop" appears to work like sgfxi works on an ordinary
Ubuntu.

However if I do "stop mdm" after that, it just switches to a different display manager! Not sure which. I don't understand what this behavior is for, no one wants the X server starting in the middle of trying to get things done.
Back to top

Okay, I forgot to purge dkms. So I did. This time things appear to be working, though the installation still was interrupted.

First, I did ctrl-alt-F1, logged in as root, then



Then I ran sgfxi. As soon as the window manager respawned I did ctrl-alt-F1 again, and the installation succeeded, confirmed by the sgfxi log.



However the original problem with mate-settings-manager is still going on.
Back to top