Page MenuHomeSolus

black screen after every boot ,but works perfectly after forced restart
Closed, ResolvedPublic

Description

whenever i start the system(desktop) in the morning ,i almost always get a black screen(without any cursor or dash on screen). i can access cntrl+alt+f2 though.

when i force restart the system(by long pressing the power button ) it works amazingly well for the rest of day.
here is my desktop configuration
AMD FX 6300
nvidia GTX 960
8gb memory
dual boot with windows 10

Event Timeline

waqar created this task.Jan 27 2018, 10:29 AM
JoshStrobl edited projects, added Software; removed Lacks Project.Jan 27 2018, 5:33 PM

Is this still an issue?

Peter-Kot added a subscriber: Peter-Kot.EditedAug 28 2018, 1:41 PM

Hi,
I am having the same issue.
Seems like similar to T4964 but I just get black screen. After forced restart 'by clicking power button' boots fine.

Will try to remove directory /var/log/journal as advised in T4964

Edit: Removing above mentioned directory didn't solved the issue.
Edit: Seems like adding directory back solved the issue. At least for last 2 boots.
Edit: Issue is back. :(

JoshStrobl triaged this task as Needs More Info priority.Oct 16 2018, 11:48 PM
JoshStrobl added a subscriber: JoshStrobl.

What desktop environment / edition are you using?

I'm using Budgie. Let me know how to give you more details.

inxi -G
Graphics:
  Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics 
  driver: i915 v: kernel 
  Display: x11 server: X.Org 1.20.2 driver: intel 
  unloaded: fbdev,modesetting,vesa resolution: 1920x1080~60Hz 
  OpenGL: renderer: Mesa DRI Intel Haswell Desktop v: 4.5 Mesa 18.2.2

More info since last update:
I have reinstalled Solus from new ISO.
All was fine I had no issues when booting on following kernels:

  • 4.18.11-93-current (4 fine boots)
  • 4.18.12-94-current(4 fine boots)

Then when there was update to
4.18.12-95-current & some xorg packages updates and I got boot to black screen again.

I changed kernel to linux-lts. So far 3 boots were fine.

Maybe issue is was with latest intel drivers updates?

mrgyb added a subscriber: mrgyb.Oct 28 2018, 2:55 PM
mrgyb added a comment.Oct 28 2018, 3:50 PM

Hey,
I have a Dell XPS 9370 and after installing 3.9999 i have the same Problem. I tried everthing i could think of, but it just doesnt boot anymore. Black screen thats it.
I used solus for one year now... i think it has something to do with the kernel... but im not sure

any ideas? thanks

I'm in the same boat as mrgyb with an xps 9370. The laptop won't reliably boot with kernel versions >4.18 (maybe boots 1 out of 20 forced restarts if I'm lucky). The last linux-current version that worked for me is 4.17.17-87, which is the only package I've held back during updates. Linux-lts also boots fine, however kernel 4.9 doesn't detect my external ssd (samsung t5).

Hi @mrgyb, Hi @onepunchdan

maybe naive but did you tried any of those steps at https://getsol.us/articles/troubleshooting/general-troubleshooting/en/#display-manager-won-t-start ?

As it comes to me, since I am on lts kernel all works fine. So far I got 11 boots with no issues and 2 with strange resolution on login screen but no black screen.

@Peter-Kot, in my case, I cannot ctrl-alt-f[0-9] into any virtual console when I get a black screen, which prevents me from running "uname -r" and comparing that to the eopkg-installed version. As far as running out of space on the boot partition, I allocated ~500MB to the ESP when I first installed Solus and "df" shows only 82/500MB used.

One detail that might be useful to mention: when I first ran into this issue with kernel 4.18, I was able to get the system to boot successfully every time using the "nolapic" kernel parameter. Having only one logical cpu core made for an unpleasant user experience so I reverted to 4.17.

bwat47 added a subscriber: bwat47.EditedNov 1 2018, 11:19 AM

@Peter-Kot, in my case, I cannot ctrl-alt-f[0-9] into any virtual console when I get a black screen, which prevents me from running "uname -r" and comparing that to the eopkg-installed version. As far as running out of space on the boot partition, I allocated ~500MB to the ESP when I first installed Solus and "df" shows only 82/500MB used.
One detail that might be useful to mention: when I first ran into this issue with kernel 4.18, I was able to get the system to boot successfully every time using the "nolapic" kernel parameter. Having only one logical cpu core made for an unpleasant user experience so I reverted to 4.17.

Yeah this is what happens to me on my xps 13 9360, randomly boot results in a black screen and I can't switch tty's or anything, only thing I can do is hold the power button and try again. When this happens journalctl doesn't save any logs of that boot either

bwat47 added a comment.Nov 7 2018, 3:33 PM

seems like this happens on nearly every boot for me now, in some cases I have to try like 5 times in a row to boot without getting stuck on a black screen. I'm at a loss as to what this could be... no other distro has ever given me this problem (including other distros using kernel 4.18).

Since journalctl doesn't save any logs when this happens, I tried to disable all of the 'silent' boot stuff to see if I could get any clue as to where it's hanging up, but alas this didn't give me anything useful. The boot starts with all the various systemd messages, but it boots so fast on this system that you can't make out any of it, and when it hangs it's still on a blank/black screen.

It almost seems like its booting so quickly it's just hitting some kind of race condition. That might also explain why the kernel option to limit to 1 cpu core helped in onepunchdan's case

I seem to have a reliably booting system after configuring my system to delay the start of lightdm by several seconds:

copy /usr/lib/systemd/system/lightdm.service to /etc/systemd/system/lightdm.service

edit /etc/systemd/system/lightdm.service to add:

ExecStartPre=sleep 3

under the [Service] section

Save the file

systemctl daemon-reload

reboot

I seem to have a reliably booting system after configuring my system to delay the start of lightdm by several seconds:
copy /usr/lib/systemd/system/lightdm.service to /etc/systemd/system/lightdm.service
edit /etc/systemd/system/lightdm.service to add:
ExecStartPre=sleep 3
under the [Service] section
Save the file
systemctl daemon-reload
reboot

@bwat47 Great find! I've rebooted 3 times and can confirm this workaround is working for me with the latest kernel 4.18.16-97.current.

I think this could be solved with an

After=${command}

instead of putting the lightdm.service to sleep, the question is just which one is needed.

Would be interesting to see the systemd-analyze blame output without the sleep to see if there is an issue with the booting order on your notebooks

I think this could be solved with an

After=${command}

instead of putting the lightdm.service to sleep, the question is just which one is needed.
Would be interesting to see the systemd-analyze blame output without the sleep to see if there is an issue with the booting order on your notebooks

1.112s systemd-backlight@backlight:intel_backlight.service
           160ms NetworkManager.service
           151ms org.cups.cupsd.service
           149ms initrd-switch-root.service
            65ms lightdm.service
            64ms udisks2.service
            63ms initrd-parse-etc.service
            58ms upower.service
            55ms systemd-resolved.service
            54ms systemd-journal-flush.service
            53ms systemd-udev-trigger.service
            52ms systemd-rfkill.service
            48ms auditd.service
            45ms accounts-daemon.service
            44ms systemd-udevd.service
            43ms systemd-fsck-root.service
            38ms user@1000.service
            37ms avahi-daemon.service
            35ms systemd-logind.service
            28ms clr-boot-manager-booted.service
            23ms colord.service
            20ms systemd-tmpfiles-setup-dev.service
            17ms systemd-sysctl.service
            15ms polkit.service
            14ms systemd-journald.service
            14ms sys-kernel-debug.mount
            14ms systemd-modules-load.service
            13ms bluetooth.service
            13ms systemd-backlight@leds:dell::kbd_backlight.service
            12ms aa-lsm-hook.service
            12ms systemd-tmpfiles-setup.service
             9ms dev-mqueue.mount
             9ms systemd-remount-fs.service
             8ms wpa_supplicant.service
             8ms systemd-update-utmp.service
             7ms initrd-cleanup.service
             7ms dev-hugepages.mount
             7ms systemd-update-utmp-runlevel.service
             6ms dev-nvme0n1p3.swap
             5ms sys-fs-fuse-connections.mount
             5ms systemd-random-seed.service
             4ms kmod-static-nodes.service
             4ms tmp.mount
             4ms systemd-user-sessions.service
             2ms initrd-udevadm-cleanup-db.service
             1ms snapd.socket

1.112s systemd-backlight@backlight:intel_backlight.service, shoudn't this start earlier? does lightdm start after it with the sleep function?

bwat47 added a comment.EditedNov 10 2018, 10:53 PM

1.112s systemd-backlight@backlight:intel_backlight.service, shoudn't this start earlier? does lightdm start after it with the sleep function?

here it is with the sleep, in this case it starts before lightdm:

3.027s lightdm.service
167ms NetworkManager.service
151ms org.cups.cupsd.service
136ms initrd-switch-root.service
 74ms systemd-rfkill.service
 66ms udisks2.service
 65ms initrd-parse-etc.service
 64ms upower.service
 59ms systemd-journal-flush.service
 54ms systemd-udevd.service
 51ms systemd-udev-trigger.service
 49ms systemd-resolved.service
 42ms auditd.service
 39ms systemd-backlight@leds:dell::kbd_backlight.service
 35ms user@1000.service
 33ms avahi-daemon.service
 29ms systemd-logind.service
 21ms colord.service
 19ms polkit.service
 18ms systemd-fsck-root.service
 17ms systemd-sysctl.service
 17ms accounts-daemon.service
 15ms systemd-journald.service
 15ms dev-mqueue.mount
 14ms systemd-modules-load.service
 14ms systemd-remount-fs.service
 13ms aa-lsm-hook.service
 13ms systemd-tmpfiles-setup.service
 12ms systemd-tmpfiles-setup-dev.service
 12ms initrd-cleanup.service
 12ms bluetooth.service
 11ms dev-nvme0n1p3.swap
 11ms clr-boot-manager-booted.service
 10ms wpa_supplicant.service
  7ms systemd-random-seed.service
  6ms kmod-static-nodes.service
  6ms systemd-update-utmp.service
  6ms sys-kernel-debug.mount
  6ms systemd-backlight@backlight:intel_backlight.service
  5ms systemd-update-utmp-runlevel.service
  4ms sys-fs-fuse-connections.mount
  4ms systemd-user-sessions.service
  3ms tmp.mount
  3ms dev-hugepages.mount
  2ms initrd-udevadm-cleanup-db.service
764us snapd.socket

Can you try to edit lightdm.service to

[Unit]
Description=Display Manager
Conflicts=xdm.service gdm.service kdm.service lxdm.service slim.service
After=systemd-backlight@.service

[Service]
ExecStart=/usr/sbin/lightdm
Restart=always
IgnoreSIGPIPE=no
BusName=org.freedesktop.DisplayManager

[Install]
Alias=displaymanager.service
WantedBy=graphical.target

this should force lightdm.service starter after systemd-backlight is started

Can you try to edit lightdm.service to

[Unit]
Description=Display Manager
Conflicts=xdm.service gdm.service kdm.service lxdm.service slim.service
After=systemd-backlight@.service
[Service]
ExecStart=/usr/sbin/lightdm
Restart=always
IgnoreSIGPIPE=no
BusName=org.freedesktop.DisplayManager
[Install]
Alias=displaymanager.service
WantedBy=graphical.target

this should force lightdm.service starter after systemd-backlight is started

With this I still get he random boot hang

What if you change it to this https://dev.getsol.us/T7098#134111

It will bring it in line with the other DM's

Would be surprised if it get fixed this way, but I could already add this non-less to my open diff regarding updating lightdm D4299 @sunnyflunk.

What's so weird is that the intel_backlight takes sometimes a lot of time to start the other time it's extremely fast, @bwat47 did you do a reboot or a complete shutdown and new start for testing the changes?

What if you change it to this https://dev.getsol.us/T7098#134111
It will bring it in line with the other DM's

With this change, it seems to boot consistently to a black screen. I couldn't get a single successful boot, so I had to adjust my lightdmconf from a liveusb to back out the change

Would be surprised if it get fixed this way, but I could already add this non-less to my open diff regarding updating lightdm D4299 @sunnyflunk.
What's so weird is that the intel_backlight takes sometimes a lot of time to start the other time it's extremely fast, @bwat47 did you do a reboot or a complete shutdown and new start for testing the changes?

Mostly reboots, but it's been a combination because when I get the black screen I have to hold the power button to power off the machine and try again. It typically takes me several tries at that point to get a successful boot

Could you please tell me if the workaround is still needed? With the last lightdm updated your service file should have been over written and you should use again the version from the solus repo again

bwat47 added a comment.EditedNov 27 2018, 3:41 PM

I removed my custom /etc/systemd/system/lightdm.service file, and with the latest updates it does seem to boot reliably without the workaround on my xps 13 9360

EDIT: One month later and still 100% reliable boots, seems like I can confirm this is fixed at least in my case

Hangman added a subscriber: Hangman.EditedDec 26 2018, 11:24 AM

Hi,

I've got this problem with my ssd, lightdm start too quickly, before graphics.
In my case solution was to create /etc/lightdm/lightdm.conf and put in it :

[LightDM]
logind-check-graphical=true

Like said on this wiki : https://wiki.archlinux.org/index.php/LightDM#LightDM_does_not_appear_or_monitor_only_displays_TTY_output

Don't know if it's possible to put this option by default to avoid any other troubles ?

Could you please tell me if the workaround is still needed? With the last lightdm updated your service file should have been over written and you should use again the version from the solus repo again

Still an issue for me. Reverted back to lts kernel.

Hi,
I've got this problem with my ssd, lightdm start too quickly, before graphics.
In my case solution was to create /etc/lightdm/lightdm.conf and put in it :

[LightDM]
logind-check-graphical=true

Like said on this wiki : https://wiki.archlinux.org/index.php/LightDM#LightDM_does_not_appear_or_monitor_only_displays_TTY_output
Don't know if it's possible to put this option by default to avoid any other troubles ?

This works very well for me, thanks