18.10: lubuntu sddm crashes with openbox session

I'm a little confused. You say "logging in with that option" does not allow you to "select a user," which implies a log in step... but you're already logged in.

I can select the Openbox session, after which all sddm functions work fine. Logging in presents me to the characteristically black screen of the Openbox session.

@walter:

> "which implies a log in step... "
Yes. The freeze occurs once one presses enter after correctly entering one's password

> "but you're already logged in."
No, or probably not, or unknown. The 'sddm' window is frozen at that point, and though the mouse continues to navigate the screen, the screen remains stuck displaying the 'sddm' window.

> "Logging in presents me to the characteristically black screen of the Openbox session."
That is where our experiences differ, and where you aren't reproducing my bug. My environment is a fresh install of lubuntu 18.10 on a real machine, not a virtual environment. Hmmm, one additional detail that maybe is worth mentioning is that I do have TWO users defined. That shouldn't make a difference, but its the only variance from a default install.

I've added another user and no difference. Can easily toggle between them.

I'm using a fresh install, as well. I am on a virtual machine, but that shouldn't matter, unless there's some problem with the physical hardware, such as some sort of graphics driver. If you do have such a problem, I would expect you to have the same issue if you booted the installation media, logged out, select the Openbox session and tried to log in again (the password is blank, so just go to the password area and hit enter).

You might want to look in /var/log. Certainly, start with sddm.log. Failing that, you can look in syslog or dmesg. It's also possible to look at Xorg.0.log but I think that's unlikely given that X is already started.

@walter: The old-style log at /var/log was empty, but using the new-fangled systemd command 'journalctl -u sddm.service' gave me a pretty detailed, but ultimately useless play-back. It claims that the openbox session was successfully opened...

I question how the issue could be related to a graphics driver, specific to openbox but not lxwt; FWIW, I've successfully used openbox on that hardware in other distros, and the hardware is common generic.

I'm having this bug too! I can login into Lubuntu or LXQt Desktop, but when I choose Openbox in the menu the screen freezes and I have to restart the system pushing the on/off button. Btw, I'm new to Linux and I just installed Lubuntu 18.10 in an old Dell Inspiron 14 laptop.

@Lucas: Welcome to the world of Linux... When I originally reported this bug, here[1], I also reported how to recover from it without needing to disconnect the power. For any operating system, disconnecting the power is undesirable; one of the advantages of Linux is that there is often a way to recover gracefully without losing your work and possibly damaging your file system. Unfortunately, learning all the techniques isn't easy.

In this case, I found that for me it was possible to gracefully recover the system by "switching to another linux virtual terminal" (eg. press Ctrl+Alt+F2), logging into to a text session, and restarting the sddm service ('systemctl restart sddm.service'). Since you're a new user to linux, you may want to consider giving it a try. For the long term, the thing to remember is that one option for you to try to recover a system is the basic technique: switch to another virtual terminal, log in, and start examining / fixing things.

[1] https://bugs.launchpad.net/lubuntu-tweaks/+bug/1804544

[Expired for lxqt-session (Ubuntu) because there has been no activity for 60 days.]

Logged into my dx6120 (x86) qa-test machine

My machine would NOT be considered clean (I'd re-used my 18.10 lubuntu installs, this was I believe a xubuntu qa-test with lubuntu-desktop added to it).

On login (details entered) I got a system.program.problem.detected question and it appeared to freeze. I just waited

Those mouse responded, eventually I right-clicked and noticed an openbox-dialog appear. I clicked the background expecting it to disappear alas no (why you can see multiple menu options from right clicks visible). I tried a menu option (terminal-emulator) which then opened correctly. I dragged it down to where I normally have it (you can see this easily).

To me it just appeared as if the screen background was not being updated (except for mouse movements, or opened windows), which is why `sddm` wasn't responding (it had moved to an openbox session), so clicks of change-session (top left), or reboot,off icons (top right) were just background and did nothing on left click. If I right-clicked there I'd get the openbox menu appear drawn over the 'sddm' background.

(sorry my text disappeared in last comment)

Well, it's confirmed, it seems. The problem is not entirely clear. It is still bizarre it's not happening in a VM.

Anyways, Lubuntu's goal is certainly not to support a pure Openbox session but we can't remove the session without affecting others who might be running pure Openbox systems so it's just there. That said, this will certainly have a very low priority.

Also, to be clear, it seems the problem isn't that merely selecting the Openbox session causes a problem. The problem begins when starting to log in. You end up in the Openbox session, but the SDDM screen isn't repainted and there's all sorts of weird graphics behavior.

I can also confirm that this happens on both an 18.10 live system and an installed system on physical hardware. I also tested a 19.04 installed system on physical hardware and it too was affected. My 18.10 install on KVM was not affected. The openbox session started as I would expect, a black background and the right click menu performed as I would expect.
I did find that on the installs that did not paint the screen correctly starting compton from the right-click menu caused the screen to begin to refresh properly.

On Lubuntu 19.04 settings a wallpaper with `feh --bg-scale ~/wallpapers/foo.png` in ~/.config/openbox/autostart resolved the problem without the need to run compton.

Also it's enough to set bg color in the autostart with: `xsetroot -solid black`.

The bug happens on a machine with:
* Driver: nouveau
* BIOS mode (not UEFI)

Thanks Ilya, for the feedback and work-around!

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0

I've same issue with fresh Lubuntu 19.10.

So the user story issue is that the background can't be displayed correctly. the screen appear frozen in SDDM screen but using Ilya trick would just display the background in black without resolving the issue.

on right-click menu :
"terminal emulator" works
"web browser" works
"Applications >" is not working and you get 'invalid output from pipe-menu "/usr/bin/obamenu"'
"ObConf" is not working and you get 'Failed to execute child process "obconf" (No such file or directory)
"Reconfigure" seems not working. Nothing happening
"Restart" seems not working. Nothing happening
"Exit" working as expected. :-D

test

I had the same issue as described when installing fresh 20.04.

I fixed it by adding `~/.config/openbox/autostart` and adding the line:
`feh --bg-scale "path/to/image"`

After that I could login to the openbox session as normal.

Since this is about Lubuntu, no currently supported release has been mentioned. That said, is this still an issue in Jammy or Mantic?

[Expired for lxqt-session (Ubuntu) because there has been no activity for 60 days.]