[SOLVED] Ubuntu 14.04.1 LTS No GUI On Boot worked in 12.04
UbuntuThis forum is for the discussion of Ubuntu Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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!
Last edited by JimKyle; 12-21-2014 at 02:44 PM.
Reason: To add information.
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!
On second thought use the original xorg.conf that was created by xorg -configure as /etc/X11/xorg.confand then add
Code:
Disable "dri
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
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.