Set Tumbleweed VM to Load LXQt on Start, not Plasma

[jdo09280]

Surely there is a way to get my Tumbleweed VM in VirtualBox to load the LXQt desktop environment instead of launching (with no login) into Plasma? Currently I am having to Start the VM, wait, then it automatically loads into Plasma without any logging in and with no log in screen, so I have no option to choose LXQt. I then have to Logout to get to the login screen to access the menu to select LXQt. It's time consuming and not very secure when it's completely skipping the login step on starting the VM. I'm not sure how to fix it. I am brand new to Linux in general but I do know how to use commands in shell prompt. I just have no idea what to type in it to fix this. Or maybe it's in YaST somewhere? Any suggestions?

It's a new VM in the current version of VirtualBox, built with a fairly new iso download (openSUSE-Tumbleweed-NET-x86_64-Snapshot20190205-Media.iso) on which I've run apt update and apt upgrade but which is in need of "software updates" (but last two times I approved all those en-masse it broke and would just not boot so I've been picking them off one at a time, updating, and rebooting, snapshotting, doing one more, updating, rebooting, snapshotting - which is why this extended logging in process is so frustrating). I've googled and googled trying to find this magic setting, and I even used this forum's search function to no avail. Does OpenSuse just always default to Plasma with no login screen if Plasma is on it? I don't want to remove Plasma because I had to add it to get some theming options I want. It's looking really pretty (once I switch to LXQt) and I don't want to lose my now perfect visual environment, but I also really don't want to have to logout and log back in every single time I reboot or start the machine. Is it possible to solve this or am I stuck on choosing between removing Plasma altogether or living with it just assuming command of the DE and not offering me a login screen? Is there perhaps one essential software update in the list of 113 package updater package updates I need that I should get done first that might solve this?

[OrsoBruno]

Hi, welcome to openSUSE (and to Linux in general). Not using LXQt here, but unless there is a bug somewhere the login manager should remember the last desktop you used.
Try to disable autologin for your current user, choose LXQt at the login prompt, then logout an login back: if you are not getting LXQt there is a problem somewhere.
Or you can open a terminal and type:

su -
<root password here>
update-alternatives --config default-xsession.desktop

You should see a "LXQt" or similar option available, type in the corresponding number and <Enter>.
If not so, there is a problem somewhere and you should wait for a LXQt user to jump in and help you.

By the way, there is no "apt update" in the openSUSE world, to upgrade a tumbleweed installation the only way is the "zypper dup" command (see "man zypper" for details or ask in the Forums). That is likely the reason for your update failing.
Please note that on Tumbleweed the "updater applet" is just a reminder and should not be used for actually upgrading your system.

[mrmazda]

https://wiki.archlinux.org/index.php...ling_autologin ought to get you covered for /etc/lightdm/lightdm.conf

[OrsoBruno]

Out of curiosity I did a fresh install of Tumbleweed on VBox, default Plasma desktop plus the LXQt desktop.
Apparently LXQt doesn't like the SDDM display manager (or the other way round) so to have the system autologin to LXQt I had to issue (as superuser, su - ):

update-alternatives --config default-displaymanager
<choose the # pointing to lightdm, was # 2 on my install>
update-alternatives --config default-xsession.desktop
<choose the # pointing to lxqt.desktop, was # 2 on my install>

Then reboot and happily land automagically on the LXQt desktop.

If you are not getting that, maybe upgrade your system ("zypper dup") or better still do a fresh NET install if you have nothing important yet on that VM.

[tsu2]

My general impression is that SDDM should be used only with KDE.

That's something for someone to ask the SDDM developers, we've seen that they have tried to build a radically different DM and released before some very important common functionality was supported, but you'd think that any new creation should attempt to to be as universally compatible with related technologies as possible... The APIs DMs have to support to be compatible with numerous Desktops have to be be very well known.

TSU