[SOLVED] GRUB is loading but the DM shows black screen
DebianThis forum is for the discussion of Debian 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.
I. I tried 2 scenarios - one with Gnome and one with KDE (respectively with GDM and KDM).
1. In both cases everything works BUT after GRUB2 menu and successful OS loading both KDM and GDM shows black screen.
2. I pass through it by entering the laptop in sleep mode and then resuming it - then it shows the login screen or lock screen I'm not sure and everything works.
3. In some cases both GDM and KDM were loading successfully.
II. So my question is how to stop this black screen before GDM or KDM from appearing?
The used laptop is Lenovo ThinkPad X61. I'm almost sure that all drivers are already installed.
I. I tried 2 scenarios - one with Gnome and one with KDE (respectively with GDM and KDM).
1. In both cases everything works BUT after GRUB2 menu and successful OS loading both KDM and GDM shows black screen.
2. I pass through it by entering the laptop in sleep mode and then resuming it - then it shows the login screen or lock screen I'm not sure and everything works.
3. In some cases both GDM and KDM were loading successfully.
II. So my question is how to stop this black screen before GDM or KDM from appearing?
The used laptop is Lenovo ThinkPad X61. I'm almost sure that all drivers are already installed.
Thanks in advance!
I am not sure (I have only ever had ONE Lenovo Laptop to play with, and NONE at the current time) but that does not sound like a DE issue. That reads like an XWindows (X.org) issue to me.
I would like to see the video related lines from your dmesg report, and perhaps any relevant log entries for x.org, system (system messages log), and perhaps kdm/gdm log lines. Even if I can make nothing of that, providing such information may help someone else here recognize the issue.
Do you know how to record and present this information?
I am not sure (I have only ever had ONE Lenovo Laptop to play with, and NONE at the current time) but that does not sound like a DE issue. That reads like an XWindows (X.org) issue to me.
I would like to see the video related lines from your dmesg report, and perhaps any relevant log entries for x.org, system (system messages log), and perhaps kdm/gdm log lines. Even if I can make nothing of that, providing such information may help someone else here recognize the issue.
Do you know how to record and present this information?
I'm afraid I don't know, sir... Please, tell me what to do and maybe tomorrow I will be able to do that.
Hmmm. Ok, well see if you can capture the output of these commands as a start:
Code:
dmesg | grep -i "consol
video
nvid"
this helps tell what it thought it should load, and what modules for video it decided to unload. This will most likely NOT show the problem, but may have useful information. Run without the grep lists a LOT of useful information that we may not want to read today.
Code:
lsmod
will show every loaded module.
Code:
grep "EE
WW" /var/log/Xorg.0.log
This will show every X.org ERROR and WARNING message from the most recent xwindows run. Dumped (using cat perhaps) without the grep, it can be a LOT of information, most of which will probably not apply to the problem.
If you have, or can install lshw you might try
Code:
lshw -class display
and we will see if that information helps.
I did research some old complaints, but they seem BACKWARDS to yours. Some users booted and all worked, then after sleep/suspend mode had to jump through hoops to get normal display on wakeup. I have not found one that was bad on boot but fixed itself on wakeup from suspend. Interesting!
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 21.770] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 21.770] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[ 21.770] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[ 21.770] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist.
[ 21.770] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[ 21.770] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[ 22.431] (WW) Falling back to old probe method for modesetting
[ 22.431] (WW) Falling back to old probe method for fbdev
[ 22.444] (WW) Falling back to old probe method for vesa
OK, first I see nothing there that should be fatal. That makes sense, as something fatal would have stopped the display from working and we see it working after a wakeup from suspend. We need someone smarter, or more information as there is no clearly smoking gun here (to my eyes).
The one thing I have found that related to that i915 module on Lenovo hardware was that the firmware needed to be updated. While this may not be the same issue, it would not hurt to apply all available updates to include the linux-firmware packages to see if that has any impact on the symptoms. The firmware level cannot be far back or we would be seeing more messages in the logs, but any improvement in the firmware code might be just what we need to nail this.
OK, first I see nothing there that should be fatal. That makes sense, as something fatal would have stopped the display from working and we see it working after a wakeup from suspend. We need someone smarter, or more information as there is no clearly smoking gun here (to my eyes).
The one thing I have found that related to that i915 module on Lenovo hardware was that the firmware needed to be updated. While this may not be the same issue, it would not hurt to apply all available updates to include the linux-firmware packages to see if that has any impact on the symptoms. The firmware level cannot be far back or we would be seeing more messages in the logs, but any improvement in the firmware code might be just what we need to nail this.
EDIT: For the moment, it looks like updating the firmware video drivers works!
And also I would like to know how to fix the problem which appeared on the third log file.
EDIT: For the moment, it looks like updating the firmware video drivers works!
And also I would like to know how to fix the problem which appeared on the third log file.
Thanks in advance.
There was no problem in the third log file. There were (normal) warnings that suggest that the init process for Xwindows went through several autodetect steps before settling on a detected configuration. This is normal behavior for modern X.org.
Old versions did this ONCE and wrote out a config file, then used that and never did detection again until forced. Today the hardware environment is assumed to be a lot more mobile, and it does autodetect on every start and caches a LOT fewer settings for the next start.
I would wait for several normal boots to verify that the firmware upgrade does resolve the issue. If it appears stable, please mark this thread "SOLVED" at that point.
Driver and firmware updates and resulting resolution of issues is a part of the technical environment. Everything from Firewalls to Smart Watches (and certainly including computers and all components) are subject to fixes. Even your car, if it is less than ten years old, gets a software and firmware upgrade when the vendor determines that is needful.
I am jsut glad that we appear to have made progress! Luck!
There was no problem in the third log file. There were (normal) warnings that suggest that the init process for Xwindows went through several autodetect steps before settling on a detected configuration. This is normal behavior for modern X.org.
Old versions did this ONCE and wrote out a config file, then used that and never did detection again until forced. Today the hardware environment is assumed to be a lot more mobile, and it does autodetect on every start and caches a LOT fewer settings for the next start.
I would wait for several normal boots to verify that the firmware upgrade does resolve the issue. If it appears stable, please mark this thread "SOLVED" at that point.
Driver and firmware updates and resulting resolution of issues is a part of the technical environment. Everything from Firewalls to Smart Watches (and certainly including computers and all components) are subject to fixes. Even your car, if it is less than ten years old, gets a software and firmware upgrade when the vendor determines that is needful.
I am jsut glad that we appear to have made progress! Luck!
I can confirm that this problem is solved. Already 3 times the laptop is booting as it should.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.