Autologin Issue
Closed this issue · 9 comments
I use ssh and remote desktop for communicating with my raspberry pi all sky imager.
Its not possible to set autologin for Consol AND Desktop.
Recently I had to add a new super user to connect again via remote desktop because the account is stucked.
Can you help?
Hi,
I don't think that you will like this answer so I apologise in advance.
In your screen shot from raspi-config, those options are actually talking about what happens when you connect a keyboard, mouse and screen to your Raspberry Pi, like this image from SparkFun:
If you set raspi-config to B1 then the HDMI screen will go into command-line mode (CLI - like a Terminal session) and you will get a login prompt. B2 is the same as B1 but it logs-in automatically.
If you set raspi-config to B3 then the HDMI screen will show the desktop (GUI) and there will be a floating panel asking you to login. B4 is the same as B3 but it logs-in automatically.
When you choose either B3 or B4, that has the side-effect of launching X11 at boot time. VNC needs X11 so you have to choose B3/B4 even if you're not connecting an HDMI screen.
If you use raspi-config to enable VNC and set a screen resolution, that has the effect of activating the vncserver-x11-serviced daemon.
If you run this command from a terminal very soon after a reboot:
$ sudo systemctl status vncserver-x11-serviced
you should get this output:
Apr 14 10:49:20 sec-dev vncserver-x11[554]: ServerManager: Server started
Apr 14 10:49:20 sec-dev vncserver-x11[554]: ConsoleDisplay: Cannot find a running X server on vt1
Apr 14 10:49:22 sec-dev vncserver-x11[554]: ConsoleDisplay: Found running X server (pid=933, binary=/usr/lib/xorg/Xorg)
The first line tells you that VNC has started. The second line appears to be the result of a timing issue where X11 hasn't started yet. The third line is VNC re-checking a couple of seconds later and finding X11.
As long as you get the first and third lines, VNC should be "working".
It is quite common to find that you only get the first two lines and not the third. The solution to that is to go back into raspi-config, change the mode to B1 then back to B3 or B4, and reboot.
Most of this stuff is covered in the PiBuilder VNC tutorial, along with the instructions on setting up a VNC password.
However, getting the Pi to respond to VNC is just the beginning of your problems. At least, that's what I've found. My experience with VNC-server on the Pi is that it is such a pain to use that I simply don't bother. This may be because I'm connecting to the Pi from macOS. I do use VNC all the time to connect Mac-to-Mac. Always just works. Never any trouble. It's Mac-to-Pi that causes endless trouble. It may be a Mac thing and you may have more luck if you're using Windows or another Linux host. I just don't know.
When I was running Buster, using macOS "Connect to server…" mostly just worked. Since Bullseye, I either get:
which usually means I forgot to set B3/B4 then, once I've fixed that, macOS says "can't connect" and the systemctl status command above reports:
Apr 14 10:50:33 sec-dev vncserver-x11[554]: Connections: connected: 192.168.132.70::52382 (TCP)
Apr 14 10:50:33 sec-dev vncserver-x11[554]: Connections: disconnected: 192.168.132.70::52382 (TCP) ([ConnFailed] No configured security type is supported by 3.3 VNC Viewer)
I've tried adjusting parameters in /etc/vnc/config.d/common.custom. No luck.
I've tried a bunch of macOS VNC apps and they either have exactly the same problem or connect but show one small portion of the desktop, massively zoomed-in, with no ability to zoom-out or re-scale. It's pretty much 99.9% of completely, absolutely and totally [your favourite four-letter-word here] useless!
Please don't suggest the RealVNC client for macOS. I've installed that several times, then done the digital equivalent of smashing it with a sledge-hammer in frustration. I have no idea why that app doesn't work properly on my Mac. It might be a "free" account but all the authentication hocus-pocus is an impenetrable barrier and I've given up. Anyone who is able to make a CAPTCHA work when the screen is the size of a postage stamp and the normally high-precision Apple mouse has been turned into an X11 mouse (imprecise and skittish) is a lot more patient than I will ever be!
And all this is before the basic problems with:
lxpaneloccasionally deciding to go into an infinite loop and turn the Pi into a non-responsive brick with a CPU temperature around 85°C; and- A huge increase in the Pi's propensity to hang during
sudo reboot.
Those two are the reasons why PiBuilder sets B1 and doesn't enable VNC. PiBuilder is about creating a rock-solid server platform for IOTstack. Behavioural hysterics by lxpanel and reboot hangs are not what you need in a server.
On the very very very rare occasions when headless SSH doesn't work and I need "direct access" to a Pi, I connect a small portable HDMI screen, USB keyboard and mouse. I've given up trying to use VNC on Raspberry Pis.
I hope something in all that helps you find a solution but I'm afraid I can't give you any magic formula which will guarantee a good result.
Further to what I wrote before, after a bit more Googling (and noticing a lot of people complaining about having trouble getting the VNC service built into the Pi to actually work properly), I stumbled across this tutorial.
on the Pi
I began by going back into raspi-config, disabling VNC, setting the boot mode back to B1, and rebooting.
Then I followed the tutorial:
$ sudo apt update
$ sudo apt install -y xfce4 xfce4-goodies
$ sudo apt install -y tightvncserver
$ sudo apt install -y dbus-x11
The first one installed a lot of stuff. I'm never particularly happy when something has crate-loads of dependencies but I was doing this on a test server so it didn't really matter. The tutorial continues:
$ vncserver
where you set a password to control access to VNC (not the user account on the Pi).
$ vncserver -kill :1
$ mv ~/.vnc/xstartup ~/.vnc/xstartup.bak
$ echo -e '#!/usr/bin/env bash\nxrdb $HOME/.Xresources\nstartxfce4 &\n' >~/.vnc/xstartup
$ chmod +x ~/.vnc/xstartup
$ vncserver
on the Mac/Linux box
Then, on the machine you want to connect from (this isn't immediately clear in the tutorial):
$ ssh -L «localPort»:127.0.0.1:«remotePort» -C -N «user»@«host»
where:
«localPort»can be anything but is usually 5901«remotePort»should be 5901 (unless you change the config)«user»would be the login name of the account on the Pi where you were runningvncserverabove«host»would be the IP address or hostname or fully-qualified domain name of the Pi:
Example:
$ ssh -L 5901:127.0.0.1:5901 -C -N pi@192.168.1.100
In words, -L listen on local port 5901 and securely forward to remote port 5901 on 192.168.1.100, connecting as the user "pi". -C enables compression and -N doesn't execute any commands (ie doesn't try to start bash).
Now, in my case, I have SSH certificates set up so I can just abbreviate that to:
$ ssh -L 5901:127.0.0.1:5901 -C -N sec-dev
where "sec-dev" is the hostname of the Pi. No password prompt or anything else. Just straight in. The pi@ is implied from the hostname and comes from my ~/.ssh/config file.
If you haven't set up either certificates or arranged key-exchange for passwordless login, you'll probably face the TOFU (trust on first use) challenge and a password challenge.
The command will then freeze.
Then, while that command is running, start your VNC client and connect to 127.0.0.1:5901 (or localhost:5901). It wanted the password set the first time I ran vncserver as above. Worked first time from the macOS "connect to server" command, no drama at all:
To exit, you quit the screen sharing window, and then CONTROL+C the SSH command.
As an alternative, you can run the SSH command in the background:
$ ssh -L 5901:127.0.0.1:5901 -C -N sec-dev &
When you're done, kill it with:
$ kill %1
but if it's Windows…
I don't know. The tutorial burbles on about putty which I have never used and don't understand but I guess it would make sense to a Windows user.
doing without SSH
Using SSH gives you secure transport. If you want to do without, you can just go straight to:
vnc://host-or-IP:5901/
That worked just fine from both macOS and a VNC app on my iPad.
Personally, I don't care about the SSH encryption for VNC traffic because:
- If I'm working locally, it's just my local home network; and
- If I'm working remotely, everything is already encrypted via ZeroTier or WireGuard.
other odds and ends
The Pi did not hang when I rebooted while VNC was running. That's only N=1 so not much of a test but it's promising.
After the reboot, VNC is not available until you (a) connect to the Pi and (b) run vncserver. If you wanted it to be always-on, you'd probably need something like an @reboot entry in your crontab.
Hi Paraphraser,
I was not expecting such a detailed analysis, your expertise isincredibly helpful.
First of all, I just use xrdp for a remote desktop session (Windows 10). Your suggestion for connection a monitor for resolving the issue wont be a longterm solution, since the problem could occur again and again.
On the left side, I logged in with my "pi" user, its connected but no screening, since I believe its stucked in a login phase or something like this. After creating via ssh a new super user "dlr", it works for now..,but I guess the same can happen here again. Iam looking for a solution to get the "pi" user back at my remote desktop screen.. I will try a bit around with autologgin options and report if something worked...
Some questions just become voyages of discovery. I get as much out of the research as I hope you do when I show what I have done.
Is "pi" still "stuck"? The most common reasons are something wrong with either .profile or .bashrc. If you can login as root then just go to /home/pi and rename those two files so they don't run at login time. Another possibility is a misbehaving cron job. That's stored at /var/spool/cron/crontabs/pi and can be moved out of the way too.
hey Paraphraser Iam still trying to resolve this issue:
I renamed .profile and .bashrc and rebootet, still not able to get a screen working with remote desktop using "pi" as user.
So many people already encountered this problem, but there seems still no solution for it, except by creating a new user..
The issue seems to be related to "video" and "render" groups..
https://forums.raspberrypi.com/viewtopic.php?t=323471&hilit=xrdp&sid=4b40dd5ac0f90de62c6055be41c841af&start=25 thanks for your help Paraphraser, I will go with the 2nd user I created.
if you create a new user and add it to the group video and render:
sudo usermod -a -G plugdev,adm,dialout,cdrom,sudo,audio,video,render,games,input,netdev,spi,i2c,gpio <new_username>
the same issue occur
Well, I've left the TightVNC installation running on my test machine and, so far, it has not misbehaved at all. I'm thinking of rewriting the VNC tutorial say something along the lines of "option 1 is to enabled the built-in option while option 2 is TightVNC. A lot of people report problems getting the built-in version working reliably so option 2 is recommended at this point".