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/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)
└─578 /usr/bin/Xorg.bin :0 -auth /var/run/xauth//A:0-BPlKZK -nolisten tcp vt07
‣ 536 /usr/bin/sddm
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
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.
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.
Then I tried the Node.js client, but when running the ‘prey config gui’, nothing happened, and then I got tired of it
It’s possible therte is still something there, but thought I disabled and uninstalled all the prey stuff.
I just do Ctrl+Alt+Backspace everytime I boot now, and I get the login manager back :shy:
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.
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.
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.
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?
Just a quick FYI, Kamoso in the AUR has been patched for baloo and now works again.