This has started happening after the most recent massive upgrade failed: after selecting NRR 2018.01 from my GRUB listings I get “Failed to start Simple Desktop Display Manager”, with instructions to run ‘systemctl status sddm.service’. I Googled around and managed to boot to runlevel 3, where I ran that command and was told the service is “inactive (dead)”.
I’m concerned about the failure to perform an upgrade, but I’m more concerned that I’ve lost my desktop.
Any suggestions?
What application did you use to update with (discovery, octopi. or pacman)?
When booted into run level 3, conect to your network and upgrade manually.
sudo pacman -SyuTo conect via wifi use:
nmtuiThe first time my system tried to upgrade it was within Octopi, but it opened a separate terminal window to run the upgrade. The second time I tried from the command line was yesterday, after booting to run level 3.
I’m at run level 3 now and have confirmed my system is already connected.
In response to the pacman upgrade I’m getting a ton of “Replace X with Y?” queries, and each prompt defaults to “yes” if I merely hit enter. If I select all default answers and choose to proceed with the installation, it runs fine, then spews a several pages of npm error messages ("/usr/lib/node_modules/npm/… exists in filesystem") before reporting “Error occurred, no packages were upgraded.”
Any ideas?
Have you installed any AUR packages?
If not, than find out what package owns those files with sudo pacman -Qo {path to file}.
If it’s npm itself then run:
sudo pacman -S npm --forceAs to the original problem.
After getting that error mesage, are you able to use ctrl+alt+F2 or F3, etc. to land at another tty (login prompt)?
If so, then log into another tty and run the systemctl status sddm.service command again.
Systemd doesn’t technicaly have runlevels, these are replaced by targets.
Systemd default targets:
Run level 0 is matched by poweroff.target (and runlevel0.target is a symbolic link to poweroff.target).
Run level 1 is matched by rescue.target (and runlevel1.target is a symbolic link to rescue.target).
Run level 2 is emulated by multi-user.target (and runlevel2.target is a symbolic link to multi-user.target).
Run level 3 is emulated by multi-user.target (and runlevel3.target is a symbolic link to multi-user.target).
Run level 4 is emulated by multi-user.target (and runlevel4.target is a symbolic link to multi-user.target).
Run level 5 is emulated by graphical.target (and runlevel5.target is a symbolic link to graphical.target).
Run level 6 is emulated by reboot.target (and runlevel6.target is a symbolic link to reboot.target).
Emergency is matched by emergency.target.
Booting into runlevel3.target (multi-user.target) will not start the sddm.service since this is a non-graphical target.
Checking the sddm.service status at any runlevel besides 5 is basically going to be pointless since it’s not enabled.
Yes, I’ve installed google-chrome (& possibly a development version) from the AUR.
I’ve force-upgraded npm, and was then able to perform a full upgrade with no further issues.
Once that was done I was able to restart to my desktop.
Thanks for the pointers & assistance! Consider this problem SOLVED!