Hi, i am experiencing issue with remotely starting lxde. the situation is as follows
i am remotely running an rpi3b+ with dietpi on it
it is not physically accessible
does regular hard reboots, to revert if a session goes wrong
ssh access
teamviewer access using the rpi host
what i am trying to do:
the graphical ui should only run when needed, therefor it is turned off. usually it run without the ui.
the procedure looks like this:
connect via teamviewer
fire up lxde
do stuff
the problem:
connecting via teamviewer works really well. it will start on a shell where you can login, same as using ssh. i installed lxde after installing teamviewer.
i can start lxde using startx, but in that case i have no mouse or keyboard control, but the cpu-load icon on the bottom right is working fine and updating. so i checked the libxtst which is installed and looks fine. no complains.
interestingly, when i fire up lightdm via systemctl start lightdm, i get prompemted the login screen with mouse and keyboard support. also the session is selectable. after logging in, i land on empty black desktop where the mouse is still mouving but nothing happens. i also can switch to a terminal using strg+alt+f4 or so.
so i tried to change LXDE.desktop and replace Exec=/…/startlxde with Exce=startx, but had no luck there. i am having hard times with the .desktop and lightdm.conf.
it seems all the pieces are there but i am missing something out.
If you start X from a CUI TeamViewer is not able to grab the screen. That’s why you’re having this issue.
We recommend if you like to use the GUI to start Raspbian with autologin GUI. Switching from CUI to GUI, vice-versa is not supported by TeamViewer.
You can config auto login to GUI with dietpi-autostart.
i came across this, but it is very risky to start the gui by default - also because of the other scripts.
also it is a waste of computing power.
but because of that blog i found out that using
systemctl start lightdm
will present the gtk greeter with keyboard and mouse support inside teamviewer. as i said after, logging in the screen remains black, but the mouse is mouveable. Therefore i suspect some xsession or LXDE.desktop setting to be incomplete or wrong.
If it help i will later update the post with the default xsession and LXDE.desktop entries.
Hi,
just a quick update, i took the risk and switched to GUI Autologin → setting 2. Sadly, neither my fallback
(vpn) nor my teamviewer where accessible after the reboot. The system stall inbetween.
Luckily i had a person with a win machine (hard to no ext4 support) to take out the sdcard. I tried as suggested elsewhere the hdmi flags which ignore if hdmi is plugged, since i am running headless.
but no luck, system showed the same behavior.
so i reverted back to autostart cumstom script in bg option 14, which worked out and got me back vpn and teamviewer.
so my current state is again:
lightdm with mouse and keyboard, but black screen after login
or
we are running a remote location where there is no landline. connection is either via mobile or some shared wifi which likely behaves like nested nats like mobile networks. so no public ips and no vpn server. i have no to very limited access to router hardware.
to access via vpn, i need a public tap server. due to the networking i was not able to route all the traffic througb the gateway client, which is not the router. therefor once the client is in the vpn, i have no to very limited lan access.
teamviewer solved that all, but now a request is graphical access, not just command line.
this path seems easier, since we missed to install something like a wifi dongle to have dualnetwork.
This is incredible. The magic here is to expose the subnet on the target node and use it as in exit-node.
Also the documentation is very clear about that
Back to the first issue: How did you install LXDE?
Via dietpi-software or “by hand”?
In the latter case, maybe a dietpi-software reinstall 6
might help.
@StephanStS since i got full network access with tailscale i had no need to run the gui, so lxde and lightdm are disabled but installed. this would only be a workaround for the teamviewer approach. I did not follow further, since, due my last experience without booting or staling i was very afraid to go any further.