Display manager not always starting

I need some help troubleshooting why my display manager refuses to start occasionally.
Yesterday I tried to setup prey-tracker, but decided to remove the packages after failing the setup (wasn’t able to find my device key…).
Since then 50% of my reboots end in the tty, I’m able to manually start it with Ctrl + Alt + F7.

╭ ➜ filip@laptop:~ ╰ ➤ ls -l /etc/systemd/system/display-manager.service lrwxrwxrwx 1 root root 36 19 sep 20:24 /etc/systemd/system/display-manager.service -> /usr/lib/systemd/system/sddm.service

╭ ➜ filip@laptop:~ ╰ ➤ ls -l /etc/systemd/system/default.target ls: kan geen toegang krijgen tot /etc/systemd/system/default.target: Bestand of map bestaat niet
^ no access to : File or map doesn’t exist

╭ ➜ filip@laptop:~ ╰ ➤ systemctl status sddm ● sddm.service - Simple Desktop Display Manager Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled) Active: active (running) since wo 2014-10-15 15:19:58 CEST; 1h 26min ago Main PID: 536 (sddm) CGroup: /system.slice/sddm.service └─578 /usr/bin/Xorg.bin :0 -auth /var/run/xauth//A:0-BPlKZK -nolisten tcp vt07 ‣ 536 /usr/bin/sddm

My:

systemctl list-units -t service --all

https://www.zerobin.net/?3023807d5175ed90#/cRBKn93hDSMl0ai+nusoRGXY3ghlBu46XSWs8fYdM0=

Shoot, if you need some more logging.

Is there maybe an error in the /var/log/sddm.log that might help ? Or maybe the Xserver has problems coming up. (so /var/log/Xorg.0.log)

And btw. if you want command output in english rather than your native language you can run the command also with

LC_ALL=C your_command_here

which produces a non localized (so english) output of the command.
It saves you from tanslating and helps us finding solutions to the problem if we have the exact english error/log/warning output.

[quote=“leszek, post:2, topic:2684”]
Is there maybe an error in the /var/log/sddm.log that might help ? Or maybe the Xserver has problems coming up. (so /var/log/Xorg.0.log) [/quote]
There is no sddm.log, I checked the Xorg.0.log, but it looks ok to me
https://www.zerobin.net/?28982b89e6857a00#byGkVud6EUJ7u2NenUzzBJH5Fqs8mbiZRt9/okEn0lI=

Maybe an easy disable/enable sddm does the trick? I’ll give that a try first, will be booting several times tonight trying to reproduce the failure.

That’s a really usefull command!

edit:
my first reboot was already a success, but that doesn’t tell anything

Booted a few minutes ago my laptop and it went to tty, yesterday night it booted into a special QDBus popup.

Maybe you guys see something special in the journal:

➤ journalctl --since="2014-10-17 19:00:00" -- Logs begin at vr 2014-10-03 20:40:29 CEST, end at vr 2014-10-17 19:30:18 CEST. -- okt 17 19:25:01 laptop systemd[571]: Starting Paths. okt 17 19:25:01 laptop systemd[571]: Reached target Paths. okt 17 19:25:01 laptop systemd[571]: Starting Timers. okt 17 19:25:01 laptop systemd[571]: Reached target Timers. okt 17 19:25:01 laptop systemd[571]: Starting Sockets. okt 17 19:25:01 laptop systemd[571]: Reached target Sockets. okt 17 19:25:01 laptop systemd[571]: Starting Basic System. okt 17 19:25:01 laptop systemd[571]: Reached target Basic System. okt 17 19:25:01 laptop systemd[571]: Starting Default. okt 17 19:25:01 laptop systemd[571]: Reached target Default. okt 17 19:25:01 laptop systemd[571]: Startup finished in 93ms. okt 17 19:29:10 laptop org.kde.kuiserver[607]: QDBusConnection: session D-Bus connection created before QCoreApplication. Application okt 17 19:29:10 laptop org.kde.kuiserver[607]: QDBusConnection: session D-Bus connection created before QCoreApplication. Application okt 17 19:29:12 laptop systemd[571]: Time has been changed okt 17 19:29:15 laptop pulseaudio[1427]: Daemon already running. okt 17 19:29:17 laptop org.a11y.Bus[607]: Activating service name='org.a11y.atspi.Registry' okt 17 19:29:17 laptop org.a11y.Bus[607]: Successfully activated service 'org.a11y.atspi.Registry' okt 17 19:29:17 laptop org.a11y.atspi.Registry[1447]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry okt 17 19:29:17 laptop org.a11y.atspi.Registry[1447]: ** (at-spi2-registryd:1456): WARNING **: Failed to register client: GDBus.Error: okt 17 19:29:17 laptop org.a11y.atspi.Registry[1447]: ** (at-spi2-registryd:1456): WARNING **: Unable to register client with session okt 17 19:30:18 laptop manjaro-settings-manager-daemon[1424]: Latest installed kernel: ""

I am having similar problems. All of a sudden, when booting, I end up with a black screen… It looks like somwhere in between tty and x… Now, I have to manually startx from tty1 everytime I boot. It happened on both of my PCs, and I have no idea why :confused:

At the moment I disabled sddm and enabled kdm, maybe kdm isn’t affected. I have a feeling it has something to do with the october updates.

my system specs, running bumblebee:

[code]
System: Host: laptop Kernel: 3.16.4-1-MANJARO x86_64 (64 bit gcc: 4.9.1) Desktop: KDE 4.14.1 (Qt 4.8.6) Distro: Netrunner 2014.09 Rolling

Graphics: Card-1: Intel 2nd Generation Core Processor Family Integrated Graphics Controller bus-ID: 00:02.0 Card-2: NVIDIA GF106M [GeForce GT 555M] bus-ID: 01:00.0

Display Server: X.Org 1.16.1 driver: intel Resolution: 1920x1080@59.93hz
GLX Renderer: Mesa DRI Intel Sandybridge Mobile GLX Version: 3.0 Mesa 10.3.0 Direct Rendering: Yes

Info: Processes: 228 Uptime: 2:30 Memory: 1747.1/7895.8MB Init: systemd Gcc sys: 4.9.1
Client: Shell (zsh 5.0.6) inxi: 2.2.14 [/code]

This part of your inxi output is a bit of a concern to me:

Client: Shell (zsh 5.0.6) inxi: 2.2.14

Netrunner Rolling like it’s parent Manjaro uses bash not zsh, I’m wondering why that came up that way?
Here is my output:

inxi -F System: Host: James-Laptop Kernel: 3.14.20-1-MANJARO x86_64 (64 bit) Desktop: KDE 4.14.1 Distro: Netrunner 2014.04 Rolling Machine: System: Hewlett-Packard product: HP Pavilion g7 Notebook PC v: 0690130000204610000620100 Mobo: Hewlett-Packard model: 1671 v: 09.4C Bios: Insyde v: F.66 date: 01/24/2013 CPU: Dual core Intel Core i3-2350M (-HT-MCP-) cache: 3072 KB clock speeds: max: 2300 MHz 1: 1016 MHz 2: 895 MHz 3: 802 MHz 4: 802 MHz Graphics: Card: Intel 2nd Generation Core Processor Family Integrated Graphics Controller Display Server: X.Org 1.16.1 driver: intel Resolution: 1600x900@60.08hz GLX Renderer: Mesa DRI Intel Sandybridge Mobile GLX Version: 3.0 Mesa 10.3.0 Audio: Card Intel 6 Series/C200 Series Family High Definition Audio Controller driver: snd_hda_intel Sound: Advanced Linux Sound Architecture v: k3.14.20-1-MANJARO Network: Card-1: Broadcom BCM4313 802.11bgn Wireless Network Adapter driver: bcma-pci-bridge IF: wlp1s0 state: up mac: c0:18:85:07:77:7f Card-2: Realtek RTL8101E/RTL8102E PCI Express Fast Ethernet controller driver: r8169 IF: eno1 state: down mac: 80:c1:6e:40:3e:b1 Drives: HDD Total Size: 750.2GB (2.3% used) ID-1: /dev/sda model: Hitachi_HTS54757 size: 750.2GB Partition: ID-1: / size: 29G used: 6.8G (25%) fs: ext4 dev: /dev/sda1 ID-2: /home size: 654G used: 1.3G (1%) fs: ext4 dev: /dev/sda2 ID-3: swap-1 size: 6.21GB used: 0.00GB (0%) fs: swap dev: /dev/sda3 ID-4: swap-2 size: 0.78GB used: 0.00GB (1%) fs: swap dev: /dev/zram0 ID-5: swap-3 size: 0.78GB used: 0.00GB (1%) fs: swap dev: /dev/zram1 ID-6: swap-4 size: 0.78GB used: 0.00GB (1%) fs: swap dev: /dev/zram2 ID-7: swap-5 size: 0.78GB used: 0.00GB (1%) fs: swap dev: /dev/zram3 Sensors: System Temperatures: cpu: 48.0C mobo: N/A Fan Speeds (in rpm): cpu: N/A Info: Processes: 185 Uptime: 1 day Memory: 978.8/5920.8MB Client: Shell (bash) inxi: 2.2.1

As you can see mine say’s Client: Shell (bash) inxi.

My concern here is that the differences in the the way in which zsh works (commands and functionality) as compared to bash, these differences may be what is causing some if not all of the issues you have been seeing with your system.

I installed zsh with this tutorial https://forum.manjaro.org/index.php?topic=14494.0, I never thought it could harm my system. I certainly will go back to bash if it causes that behaviour. It would be interesting to see if jerik is also using zsh.

I’m not entirely sure that it is, and I do hope that I am wrong, but it is possible. Sometimes shell scripts written and/or designed with one shell in mind will need to be modified to work on another, this is just the nature of things. My thought process on this is that you can’t just put a small cup into a cup holder designed to fit a larger cup without one or the other being modified in someway to fit properly, but like I said this is just a thought.

Nope, not using zsh

@ jerik

Yours sounds like more of a start up configuration issue.
Have you opened a thread on your issue yet?
[hr]
flipper

What method did you use to try and install prey tracker?

Depending on how it was installed, there could be something you missed that got left behind causing your issue as well.

If you do still want to use prey tracker here is a link to get you started:
https://wiki.archlinux.org/index.php/Prey

Tried with that link and first installed prey-tracker, but couldn’t find a device key in my control panel, only the API-key was there. Used the prey-config script, but never saw a new device on Preys website. Before I had it running in combination with dualboot Windows/Manjaro, and that was easy because there was already a device with key set up in Windows, I deleted the device because i wanted to start from scratch. That was stupid, because now I couldn’t add my device anymore. If I would have left the device and used that key, it was already up and running. :frowning:
Then I tried the Node.js client, but when running the ‘prey config gui’, nothing happened, and then I got tired of it :slight_smile:

It’s possible therte is still something there, but thought I disabled and uninstalled all the prey stuff.

Where do I do that?

I just do Ctrl+Alt+Backspace everytime I boot now, and I get the login manager back :shy:
[hr]
Oh,wait - did you mean just a new forum thread, or did you mean a bug tracker issue? I thought the latter to begin with, but now I wonder if you meant the first :huh:

Yes, I did mean a new forum thread. but first could you open octopi and either manually upgrade SDDM to the newer version in the Manjaro community repository or go into Tools > Repository Editor and move the blueshell repository down to the bottom of the list right before custom and save, now refresh the repositories and there should be a few packages listed to be updated.

Note: I think the issue your experiencing is being caused by the version of sddm in the blueshell repository having been compiled against older versions of upower, qt and libxcb. Moving the blueshell repository down the list gives the signed packages in the Manjaro repositories priority over the ones in it, instead of the other way around.

It wasn’t directed to me but this seems to have solved my sddm issue. Nice brainstorming AJSlye!
Is there any downside of moving the blueshell almost at the bottom?

No not really, anything that is provided by the blueshell repository that is not in the Manjaro repositories will still get installed and updated from there. The only time there would be an issue is if Netrunner was to upload something that is newer, or that need a special patch added to it specific to them into their repositories than what is available in Manjaro’s, but I don’t really see that happening as Manjaro updates their stable repositories way more often the Netrunner updates the blueshell repository, and even if Netrunner needed to patch something just for their distribution all they would need to do is slightly modify the new packages name and add a replaces tag to it so that it will replace the one from Manjaro, so this is still not a problem actually.

If this issue is really related to sddm we will of course update sddm in the blueshell repo aswell.

Why duplicate effort, all that needs to be done is to remove the one from the blueshell repository and it will update automatically to the newer one, not to mention Manjaro already has sddm-0.9.0+git20141003.ef14018-2 in testing and sddm-0.10.0-2 in unstable, so one or the other will be in their next update pack.

Yeah we could also remove it. We initially packaged for having a working sddm with 2014.04 as back then it wasn’t working and we had to patch it.

Well if it still needs to be patched then you should replace it.
However, and not to seem critical, but why not patch it and submit it back upstream to Manjaro?
I’m sure that Phil and the rest of the Manjaro team would appreciate it.

One quick question, are there similar situations for the other packages that are older?
ca-certificates
libkgapi
and
transmission-qt

Just a quick FYI, Kamoso in the AUR has been patched for baloo and now works again.