DE switch failed, Tumblewees now wont booy

I have the latest version of Tumbleweed GNOME installed, and I tried to switch to LXDE by using the config editor in YaST. However, I didn’t have LXDE installed, and now Tumbleweed is stuck at “boot job running for Halt until startup is finished (xx/xx)”.

Can anyone help me reconfigure my config file/ install LXDE please?

And what exactly did you change in YaST?

Btw, you can just choose a different desktop on the login screen, no need to change anything in YaST (you may have to install the other desktop first though, of course).

However, I didn’t have LXDE installed, and now Tumbleweed is stuck at “boot job running for Halt until startup is finished (xx/xx)”.

That rather sounds like you changed the default boot target, and the system is trying to boot to “Halt” now (which means shutdown without powering off) instead of the graphical.target.

Press ‘e’ at the boot menu and append ‘5’ to the line starting with “linux” or “linuxefi”.
Does the system boot correctly then?

Sorry, still not booting. I used the /etc/YaST/config option in the YaST client.

Same error?

I used the /etc/YaST/config option in the YaST client.

But what did you change exactly?

The DEFAULT_WM option (that specifies the desktop that’s used by default) should not cause this at all.

Does it boot to a text mode login prompt if you add ‘3’ or ‘1’ (as before)?
And just to avoid a possible misunderstanding: you need to append a space before the number as well.

Yep, DEFAULT_WM. Same error too

Nothing else?
Well, revert your change by modifying /etc/sysconfig/windowmanager with a text editor.

Either use a LiveCD, or add “init=/bin/sh” to the boot options to get to a minimal text mode system.

But as I said, IMHO that change cannot really cause your problem so reverting it probably won’t help either.

Maybe post a screenshot/photograph of your error, there might be some other clue on the screen…
There normally shouldn’t be a boot job for Halt running at all IMHO.

Boot now stuck at "Reached target Local File Systems (Pre).

And what did you change?

Can you get to a text mode login by pressing Ctrl+Alt+F1?

Nope, just shows “Failed to start Setup Virtual Console. See ‘systemctl status systemd-vconsole-setup.service’ for details. Starting Show Plymoth Boot Screen…” . Added 5 to the end of linuxefi line as you said

Try adding “plymouth.enable=0” then.
Does that help?

Questions (to wolfi as well),
Wouldn’t a “DEFAULT_DE” or something like that be required to display a graphical login screen unless you specify the IceWM WM?

If the system is functional in a non-graphical console,
Would it make sense to simply install the LXDE or LXQt (or other Desktop) patterns? I would expect that should address whatever mistake was made.

BTW
Although LXDE is still supported by openSUSE, its development and maintenance were frozen a couple years ago, and the entire support community is now dedicated to LXDE’s successor, LXQt. So, I recommend installing LXQt instead of LXDE, and on top of a gnome type base subsystem which can be either regular GNOME or XFCE(ie not KDE or non-graphical system).

TSU

No.

First, it is called “DEFAULT_WM”.
And that only specifies the default. If that isn’t found, it will fallback to something else (IceWM, which is always installed), and meanwhile Tumbleweed uses update-alternatives for the default “windowmanager” (actually the default desktop session) as well.

In any case, you should get a login screen and/or a graphical session.

If the system is functional in a non-graphical console,

But the problem is that the system is apparently NOT functional in a non-graphical console now either. (as I wrote already, I don’t see how this could be related to the DEFAULT_WM change at all)

Please read the thread before responding.

For the Windows Manager, there is a DEFAULT_WM parameter, and it looks like it can have a default value of “default”
For the Display Manager, there is a DISPLAYMANAGER parameter, and it looks like it can have a null default value which is what I was asking about.

Whatever the @OP has done, he seems to have broken the login screen, and possibly the reason may be related to Plymouth not loading (or at least the problem may be happening about then).

I guess I’d ask a few questions before concluding that the machine is not functional at all in its current state…
If the machine has progressed to loading Plymouth, then it has to have successfully passed the point where multi-user.target successfully loaded which is a working text-only, non-graphical system.

So, I guess I’d ask whether the User can see a blinking cursor or similar…
Boot may be stuck, but is the system interactive or not?
And, if necessary what happens if the system is booted only to multi-user.target? -This is accomplished by editing the grub entry to point to multi-user.target instead of graphical.target

TSU

This is my suggestion…

If you don’t have an interactive session, then the following procedure should enable that, from which you would have many different possible ways to go thereafter.

SUSE documentation describing various “targets” but only describes configuring when you have a working interactive session.
https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_grub2_commands.html

Cannot find any SUSE documentation for modifying GRUB2 to change the boot target, but to my eye the following RHEL/CentOS documentation(with screenshots) is no different than what you’ll find on SUSE/openSUSE.
https://www.thegeekdiary.com/centos-rhel-7-how-to-boot-into-emergency-or-multi-user-mode-from-grub2/

Once you’ve booted and logged into an interactive prompt, you can troubleshoot your system, so for instance if you can remember what you did, you can undo. Maybe run snapper and roll back to before your mistake. Maybe install the LXQt patterns and see if that automatically fixes whatever you did.

In other words, you should now have a fully functioning text-only system to do whatever you wish, and there are probably many possible approaches to fixing your system, and if you determine first that snapper is working then anything you do could be tried and if doesn’t have the desired result, can be rolled back.

Some suggestions for what to try
snapper - first of all to ensure you can try anything within reason with ability to roll back, and maybe just roll back immediately to undo whatever you did.

journalctl - inspect your logs, in particular system logs from previous boots or by date/time.

systemctl - view status of anything that should be running, but in this text mode you may not be able to read anything related to the graphical systems

HTH,
TSU

Yes, as I wrote.
But it doesn’t matter.

Any value should at least bring a graphical session, because IceWM is used as fallback.
And that value is only relevant when you run startx, though it is used as default by most display managers.

But again, Tumbleweed uses update-alternatives now, DEFAULT_WM is not respected anymore.

For the Display Manager, there is a DISPLAYMANAGER parameter, and it looks like it can have a null default value which is what I was asking about.

This is ignored in Tumbleweed since months.

The only way to set the display manager is update-alternatives.

Whatever the @OP has done, he seems to have broken the login screen, and possibly the reason may be related to Plymouth not loading (or at least the problem may be happening about then).

The real problem is not at all clear IMHO, but changing DEFAULT_WM alone definitely cannot cause it.

I guess I’d ask a few questions before concluding that the machine is not functional at all in its current state…

Sure, but it also brings in noise…

If the machine has progressed to loading Plymouth, then it has to have successfully passed the point where multi-user.target successfully loaded which is a working text-only, non-graphical system.

Not at all.

plymouth is started very early, even before the / partition is mounted.

So, I guess I’d ask whether the User can see a blinking cursor or similar…
Boot may be stuck, but is the system interactive or not?
And, if necessary what happens if the system is booted only to multi-user.target? -This is accomplished by editing the grub entry to point to multi-user.target instead of graphical.target

I already asked/suggested similar things.
Again, please read the thread before replying and suggesting the same again.

did plymouth.enable=0 in boot options, got into gome from there and reset config. my system is now ok, thanks 4 your help