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
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. :(
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:
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?
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.
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
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
@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
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.socket1.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
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?
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
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
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
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 ?