Graphical interface startup issue
up vote
0
down vote
favorite
The problem is with 18.10 cosmic desktop after a do-release-upgrade. Before the release upgrade I did not have this issue, or at least I did not notice it.
The issue is that when the OS starts, the graphical interface just won't start no matter how long I wait. I only see an empty black screen with a blinking cursor at the top left corner of the screen. GUI definitely worked before the release upgrade, althoug I had occassions where I needed to manually switch to the graphical terminal. This happened rarely, only a handful of times, so I didn't bother to hunt the problem down.
I found a strange workaround: pressing CTRL+ALT+F2 and then CTRL+ALT+F1 switches terminals, and shortly the GUI starts up properly.
Then I accidentally noticed that there are not one, but two GUIs are running, one on VT #1 (accessible with CTRL+ALT+1), and an other one on VT #3 (CTRL+ALT+3).
If I run the command ps fauxww
I can clearly see two xorg instances running on vt1 and vt3, forked by gdm-x-session worker processes, those were started by their respective gdm-session-worker processes, both of which are started by a single gdm3 process.
Is this normal? (Not likely...) I think there should only be a single GUI process. Could the multiple running GUI instances have anything to do with not being able to start up properly?
Thank you.
boot gdm virtual-console
add a comment |
up vote
0
down vote
favorite
The problem is with 18.10 cosmic desktop after a do-release-upgrade. Before the release upgrade I did not have this issue, or at least I did not notice it.
The issue is that when the OS starts, the graphical interface just won't start no matter how long I wait. I only see an empty black screen with a blinking cursor at the top left corner of the screen. GUI definitely worked before the release upgrade, althoug I had occassions where I needed to manually switch to the graphical terminal. This happened rarely, only a handful of times, so I didn't bother to hunt the problem down.
I found a strange workaround: pressing CTRL+ALT+F2 and then CTRL+ALT+F1 switches terminals, and shortly the GUI starts up properly.
Then I accidentally noticed that there are not one, but two GUIs are running, one on VT #1 (accessible with CTRL+ALT+1), and an other one on VT #3 (CTRL+ALT+3).
If I run the command ps fauxww
I can clearly see two xorg instances running on vt1 and vt3, forked by gdm-x-session worker processes, those were started by their respective gdm-session-worker processes, both of which are started by a single gdm3 process.
Is this normal? (Not likely...) I think there should only be a single GUI process. Could the multiple running GUI instances have anything to do with not being able to start up properly?
Thank you.
boot gdm virtual-console
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
The problem is with 18.10 cosmic desktop after a do-release-upgrade. Before the release upgrade I did not have this issue, or at least I did not notice it.
The issue is that when the OS starts, the graphical interface just won't start no matter how long I wait. I only see an empty black screen with a blinking cursor at the top left corner of the screen. GUI definitely worked before the release upgrade, althoug I had occassions where I needed to manually switch to the graphical terminal. This happened rarely, only a handful of times, so I didn't bother to hunt the problem down.
I found a strange workaround: pressing CTRL+ALT+F2 and then CTRL+ALT+F1 switches terminals, and shortly the GUI starts up properly.
Then I accidentally noticed that there are not one, but two GUIs are running, one on VT #1 (accessible with CTRL+ALT+1), and an other one on VT #3 (CTRL+ALT+3).
If I run the command ps fauxww
I can clearly see two xorg instances running on vt1 and vt3, forked by gdm-x-session worker processes, those were started by their respective gdm-session-worker processes, both of which are started by a single gdm3 process.
Is this normal? (Not likely...) I think there should only be a single GUI process. Could the multiple running GUI instances have anything to do with not being able to start up properly?
Thank you.
boot gdm virtual-console
The problem is with 18.10 cosmic desktop after a do-release-upgrade. Before the release upgrade I did not have this issue, or at least I did not notice it.
The issue is that when the OS starts, the graphical interface just won't start no matter how long I wait. I only see an empty black screen with a blinking cursor at the top left corner of the screen. GUI definitely worked before the release upgrade, althoug I had occassions where I needed to manually switch to the graphical terminal. This happened rarely, only a handful of times, so I didn't bother to hunt the problem down.
I found a strange workaround: pressing CTRL+ALT+F2 and then CTRL+ALT+F1 switches terminals, and shortly the GUI starts up properly.
Then I accidentally noticed that there are not one, but two GUIs are running, one on VT #1 (accessible with CTRL+ALT+1), and an other one on VT #3 (CTRL+ALT+3).
If I run the command ps fauxww
I can clearly see two xorg instances running on vt1 and vt3, forked by gdm-x-session worker processes, those were started by their respective gdm-session-worker processes, both of which are started by a single gdm3 process.
Is this normal? (Not likely...) I think there should only be a single GUI process. Could the multiple running GUI instances have anything to do with not being able to start up properly?
Thank you.
boot gdm virtual-console
boot gdm virtual-console
asked Nov 6 at 6:01
netom
27624
27624
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
We need to know if the bug is in the X11 configuration or the display manager (the login screen). Currently, in my system, I note that if I have any xorg.conf file--anything whatsoever--the nvidia driver will not start X itself. Moving xorg.conf allows nvidia-390 or nvidia-410 to start. Same problem does not seem to affect X when I turn off the nvidia drivers.
Putting X aside, consider the display manager. For me (and many others, if you check), there is a bug in gdm3, it won't start for either. I'm still digging into all of the reasons, but best suggestion now is to install the lightdm display manager. It will start. You can make sure which is selected if you run
dpkg-reconfigure lightdm
If the login display manager still fails to start, I suggest you turn off the graphical login and let the system boot up and come to a CLI login prompt. Here's how to turn off the graphical login:
systemctl set-default multi-user.target
I learned that at https://wiki.debian.org/GDM#Removing_autologin_in_gdm3_and_getting_more_verbose_output_in_GDM
From there, you have more freedom to test both the raw X session with
startx
The important there is to see if X itself starts.
And you can also you can test with display managers. Launch with these with systemctl
. For example, right now
sudo systemctl start lightdm
or if you want to see the black screen again, put gdm3 instead of lightdm.
When you ask more questions, please remember to tell us output from
uname -a
and the video part of the output from
lshw
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
We need to know if the bug is in the X11 configuration or the display manager (the login screen). Currently, in my system, I note that if I have any xorg.conf file--anything whatsoever--the nvidia driver will not start X itself. Moving xorg.conf allows nvidia-390 or nvidia-410 to start. Same problem does not seem to affect X when I turn off the nvidia drivers.
Putting X aside, consider the display manager. For me (and many others, if you check), there is a bug in gdm3, it won't start for either. I'm still digging into all of the reasons, but best suggestion now is to install the lightdm display manager. It will start. You can make sure which is selected if you run
dpkg-reconfigure lightdm
If the login display manager still fails to start, I suggest you turn off the graphical login and let the system boot up and come to a CLI login prompt. Here's how to turn off the graphical login:
systemctl set-default multi-user.target
I learned that at https://wiki.debian.org/GDM#Removing_autologin_in_gdm3_and_getting_more_verbose_output_in_GDM
From there, you have more freedom to test both the raw X session with
startx
The important there is to see if X itself starts.
And you can also you can test with display managers. Launch with these with systemctl
. For example, right now
sudo systemctl start lightdm
or if you want to see the black screen again, put gdm3 instead of lightdm.
When you ask more questions, please remember to tell us output from
uname -a
and the video part of the output from
lshw
add a comment |
up vote
1
down vote
We need to know if the bug is in the X11 configuration or the display manager (the login screen). Currently, in my system, I note that if I have any xorg.conf file--anything whatsoever--the nvidia driver will not start X itself. Moving xorg.conf allows nvidia-390 or nvidia-410 to start. Same problem does not seem to affect X when I turn off the nvidia drivers.
Putting X aside, consider the display manager. For me (and many others, if you check), there is a bug in gdm3, it won't start for either. I'm still digging into all of the reasons, but best suggestion now is to install the lightdm display manager. It will start. You can make sure which is selected if you run
dpkg-reconfigure lightdm
If the login display manager still fails to start, I suggest you turn off the graphical login and let the system boot up and come to a CLI login prompt. Here's how to turn off the graphical login:
systemctl set-default multi-user.target
I learned that at https://wiki.debian.org/GDM#Removing_autologin_in_gdm3_and_getting_more_verbose_output_in_GDM
From there, you have more freedom to test both the raw X session with
startx
The important there is to see if X itself starts.
And you can also you can test with display managers. Launch with these with systemctl
. For example, right now
sudo systemctl start lightdm
or if you want to see the black screen again, put gdm3 instead of lightdm.
When you ask more questions, please remember to tell us output from
uname -a
and the video part of the output from
lshw
add a comment |
up vote
1
down vote
up vote
1
down vote
We need to know if the bug is in the X11 configuration or the display manager (the login screen). Currently, in my system, I note that if I have any xorg.conf file--anything whatsoever--the nvidia driver will not start X itself. Moving xorg.conf allows nvidia-390 or nvidia-410 to start. Same problem does not seem to affect X when I turn off the nvidia drivers.
Putting X aside, consider the display manager. For me (and many others, if you check), there is a bug in gdm3, it won't start for either. I'm still digging into all of the reasons, but best suggestion now is to install the lightdm display manager. It will start. You can make sure which is selected if you run
dpkg-reconfigure lightdm
If the login display manager still fails to start, I suggest you turn off the graphical login and let the system boot up and come to a CLI login prompt. Here's how to turn off the graphical login:
systemctl set-default multi-user.target
I learned that at https://wiki.debian.org/GDM#Removing_autologin_in_gdm3_and_getting_more_verbose_output_in_GDM
From there, you have more freedom to test both the raw X session with
startx
The important there is to see if X itself starts.
And you can also you can test with display managers. Launch with these with systemctl
. For example, right now
sudo systemctl start lightdm
or if you want to see the black screen again, put gdm3 instead of lightdm.
When you ask more questions, please remember to tell us output from
uname -a
and the video part of the output from
lshw
We need to know if the bug is in the X11 configuration or the display manager (the login screen). Currently, in my system, I note that if I have any xorg.conf file--anything whatsoever--the nvidia driver will not start X itself. Moving xorg.conf allows nvidia-390 or nvidia-410 to start. Same problem does not seem to affect X when I turn off the nvidia drivers.
Putting X aside, consider the display manager. For me (and many others, if you check), there is a bug in gdm3, it won't start for either. I'm still digging into all of the reasons, but best suggestion now is to install the lightdm display manager. It will start. You can make sure which is selected if you run
dpkg-reconfigure lightdm
If the login display manager still fails to start, I suggest you turn off the graphical login and let the system boot up and come to a CLI login prompt. Here's how to turn off the graphical login:
systemctl set-default multi-user.target
I learned that at https://wiki.debian.org/GDM#Removing_autologin_in_gdm3_and_getting_more_verbose_output_in_GDM
From there, you have more freedom to test both the raw X session with
startx
The important there is to see if X itself starts.
And you can also you can test with display managers. Launch with these with systemctl
. For example, right now
sudo systemctl start lightdm
or if you want to see the black screen again, put gdm3 instead of lightdm.
When you ask more questions, please remember to tell us output from
uname -a
and the video part of the output from
lshw
edited Dec 1 at 5:11
answered Dec 1 at 5:05
pauljohn32
2,199822
2,199822
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1090400%2fgraphical-interface-startup-issue%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown