Interface stuck in non-Graphic mode

Recently I tried to log out from Leap 15.1 while using KDE, but seemingly had problems; the logout was taking way too long. I used the Ctrl-Alt combo to try text based tty1 ( via key F1 ), etc. It took quite long, but finally got there. I was not able to get back to the standard graphical interface using F7. I used top and ps to try to see what was happening; I wasn’t really able to determine what the problem was. I had the system reboot. But the system plopped me into a text tty after boot. No Graphical interface. I’m aware that choices of different graphical environments can be made before logging in, when the graphical interface is available, but I must admit I’m not aware of a choice of text only environment. So even if something somehow got stuck, I’m not aware of what that could be. On the same machine, I’m presently using Leap 15.0 KDE, graphically, with no problem. I’d greatly appreciate it if someone could give me a hint of some sort of switch/mode/etc. that might be the crux of the problem, even if just a starting point for investigation.

What is the output from:

ls -l /etc/alternatives/default-displaymanager

Actually, there is such a choice. If you use “update-alternatives” to set default-displaymanager to “console” you will get a command line session.

If you go into Yast –> Services Manager

then the top line should show the default system target. Here, it is “Graphical Interface”, but you can change that to something else.

It’s hard to know what you changed.

Because you forced a dirty shutdown, consider that when you reboot the system might just be trying to verify the integrity of files so take much longer to boot completely… So your system might just be paused at the point your system has boot to text mode but still trying to continue to boot to graphical mode.

So, maybe wait at least a few minutes, and although not a real indication of anything periodically check that your disk activity light blinks from time to time.

If that doesn’t work and you’re installed on BTRFS, you probably should be able to use snapper to roll back to before your dirty shutdown to return your system to working order… It’ll at least return your basic system settings although if there were any changes to your Desktop settings, those would not be rolled back.


Thanks to everyone who tried to help!!

I attempted to make things clear; I’m sorry if I didn’t.

Back in “the day” I was a Unix Kernel Engineer, so I try to avoid dirty shutdowns. I tried to get across the idea that I was able to log into a text mode tty, and use commands to try to assure a clean shutdown. I suppose I should have made that more explicit.

Sorry, it’s been a very strange day; also had other types of problems with Leap 15.2 and other things; I was multi-tasking solving those issues too.

WRT Leap 15.1, sddm was the default-displaymanager. I didn’t really change anything.

I was able to investigate the state of things related to Leap 15.1 from other Linux versions, distros, etc., that I have installed.

Somehow baloo had some problem, generated 10’s of GigaBytes of entries into both the messages and warn logs. It had seemingly crashed and wasn’t visible to top or ps, or related commands. But it managed to come close to filling the root file system. So naturally things degenerated from there.

I checked and saw some issues that have been reported with baloo, which from the messages, sound as if they might be related. So no more baloo use for the time being.

Thanks again!

Problem solved.

Did you consider the contents of ~/.cache/ ?

Unfortunately, sometimes KDE gets itself into an unresolvable situation and, begins to misbehave – unfortunately …

  • My personal solution is to kill the KDE user’s session by whatever means and then login into a VT – clear ~/.cache/ – also clear other suspect areas such as /tmp/, /var/tmp/ and ~/.kde4/.

Whether or not parts of ~/.config/ have to be cleaned up, is also needed, sometimes – look for outdated configuration files – ~/.config/pulse/ only really needs to be inspected if sound issues arise but, occasionally it is a contributing factor for the case of “crash at login” …
An inspection of ~/.local/share/ is rarely needed …

Yes, baloo …

  • Up until February 2019, I had to run the following at login:

# Clean Baloo …
if  -f ~/.local/share/baloo/dateLastCleaned ]]
  declare -i BalooLastDate
  BalooLastDate="$(/usr/bin/cat ~/.local/share/baloo/dateLastCleaned)"
  declare -i TwoDaysAgo
  TwoDaysAgo="$(/usr/bin/date --date='2 days ago' +%Y%m%d)"
  if (( $BalooLastDate < $TwoDaysAgo ))
    /usr/bin/balooctl stop
    /usr/bin/rm ~/.local/share/baloo/dateLastCleaned
    /usr/bin/find ~/.local/share/baloo/ -iname '*index*' -execdir /usr/bin/rm '{}' \;
    /usr/bin/date +%Y%m%d > ~/.local/share/baloo/dateLastCleaned
  /usr/bin/balooctl stop
  /usr/bin/find ~/.local/share/baloo/ -iname '*index*' -execdir /usr/bin/rm '{}' \;
  /usr/bin/date +%Y%m%d > ~/.local/share/baloo/dateLastCleaned

  • At some stage during the Leap 15.x life cycle, Baloo got a repair which alleviated the need clean the Stygian stables every couple of days …
  • With Leap 15.2, Baloo seems to behave itself …


Thanks for the additional information on baloo.