Here it is again, but its in a prior post somewhere.

As a user of Xubuntu for the past seven years I'll barge in here to try to clear up a bit of seeming fog about using "root" in the *buntu packages. First, a default installation of any flavor of *buntu has no password at all for UID==0. The only way to get a "root password" is to manually add one after installing the system. That's a major difference from the older distributions' requests to create such a password during installation.

The other point that appears foggy to me is the distinction between using su, sudo, gksu, and gksudo (there may be still another pair of similar commands for KDE; I've not used KDE at all since 1998 or so and then only briefly while visiting my youngest son). Each of those four sets up the home directory and environment differently! In particular, using sudo changes the user's environment to that of "root" which can give rise to all sorts of subsequent problems. There's a whole section of the Ubuntu wiki that spells out all of this stuff; it's one of the major departures that Canonical made when basing *buntu on Debian.

Absence of /etc/X11/xorg.conf isn't due to it being "moved elsewhere" at all. Canonical quit providing the file several LTS versions back (I don't remember whether it was 2008 or 2010), but if you create such a file and put it into /etc/X11, owned by root with permissions of 644, the system will use it instead of the built-in replacement. I've had to do just that because my favorite monitor's EDID response is faulty and I have to force the proper settings at boot.

Although back up the thread someone mentioned that the change from upstart to systemd was not scheduled until 2015, I've been getting almost daily updates for the past few months, including four files this morning, to replace stuff with systemd versions. However I don't think this is likely to be a major factor in gkasica's problem. I need to go back to the start of the thread and review his hardware listing there before offering any comment in that area other than to say such black-screen situations are possibly one of the most frequent areas discussed over on the official Ubuntu forums, and almost all of them turn out to be unique.

EDIT: After going back to post #1 and comparing the working and non-working logs, I see a flock of errors starting at line 128 of the non-working log that indicate part of the Digital Rendering Module (DRM) could not be found. That unfortunate abbreviation originally led me to wonder, earlier today when four DRM updates appeared on my system, why Digital Rights Management had any place in a Linux kernel -- but then I found its alternate meaning, and I suspect that this is indeed the root of this problem. At least, it's a clue to follow. The working log has no such errors. The question I see now is why one box needs it and the other does not...

Ok thanks jim. So how or what do I install to get them? Sure appreciate the help.

Unfortunately, that's something I can't answer. As I said, I haven't used KDE (which is the DE for Kubuntu) for years so am not at all familiar with the utility packages it provides. Unfortunately, each *buntu flavor is pretty much unique when it comes to the included utilities.

The others taking part here, though, may be able to assist in following up this clue. There are ways to search for package names from the command line that may help; I'd try "apropros DRM" first, myself, on both the working and non-working systems. That should give you a list of "man" pages dealing with that obnoxious (to me, anyway) abbreviation (if any exist either place; if not, I would Google for the phrase), and that in turn may give you leads to the actual package names. If "DRM" comes up empty, I would try using the actual file name, as shown in your original non-working log near line 128, as a search term.

EDIT--In case you're not aware of the syntax of xorg logs, the "(EE)" prefix on a line indicates an error condition. Other notations include "--" for routine, "II" for informational, and "WW" for warnings. Warnings can safely be ignored, but any EE line should be studied. Sometimes, the error it reports is automatically corrected within a few more lines; other times, such as here, it's fatal and causes the entire xorg server to disconnect itself (as shown in the last dozen lines or so of the log). -- END EDIT

Once I had a reasonable-looking package name, I would use "apt-get" or "aptitude" from the command line to download and install it -- after making certain I had all critical material safely backed up, of course.

I would also install "synaptic package manager" to use in place of the Software Center utility, once things were working. Software Center has been simplified to the degree that I find it plain unusable for trouble-shooting. Too many things get hidden behind the scenes. Synaptic is a GUI utility also, but makes many more details available to me. It's in the repositories. However, I wouldn't make any changes of this sort until the immediate problem is fixed. The fewer changes made, the less confusion gets poured into the mix -- and it's always confusing enough right from the start!

DRM is Direct Rendering
http://wiki.gentoo.org/wiki/Xorg/Har...leration_guide

Right; I discovered that earlier today. It's unfortunate, though, that the same abbreviation was already known to mean Digital Rights Management also known as "you-never-own-what-you-bought" in many other places such as SlashDot... That's what makes it obnoxious to me!

Thanks for the help here. What's the next step I take to get this working?

After a little bit of research a couple of things to try:

add the following line to the module section of your /etc/X11/xorg.conf
Another option is to use the vesa driver.

On second thought use the original xorg.conf that was created by xorg -configure as /etc/X11/xorg.confand then add to the module section. If That doesn't work, then either change the driver in the driver section to vesa or copy /etc/X11/org.conf.failsafe to /etc/X11/xorg.conf. In order for the vesa driver to work nomodeset may have to be boot option

Ok will give it a try but may be tomorrow morning before I have a chance.

WE have a winning combination!!

Adding the

Section "Module"
Disable "dri"
EndSection

And setting

Section "Device"
Identifier "Card0"
Driver "vesa"
EndSection

Has it up and running..

It's VERY slow in refreshing the screen, but its working.

Great job colorpurple21859
Congrats gkasica!

Glad you got it working. I was hoping there was a better solution, but from what I found that card isn't supported very well in linux, and there has been several bug reports filed for the same problem.

Any thoughts on speed up of the display at all otherwise I'm willing to call this closed.