I have been using Mycroft on a Raspberry Pi 3B+ for a while now and I seem to not be able to set it to auto login on boot/restart. The device runs headless 24/7 and it mostly works great. I do encounter glitches at times after updates, in the form of the audio input not working anymore, and the easy fix is a restart. I do connect to it via SSH to give the reboot/shutdown command, but when it boots up to CLI, I need to use a keyboard connected directly to it in order to be able to type in the password for the pi user to continue loading the venv (the default password has been changed). I have tried to SSH into it upon restart, without using the directly connected keyboard, and it does work in the sense that it loads the venv on my remote session but the device does not react to vocal commands, audio output does not work and the audio input meter is non-existent (even though it is showing messages in text). If I put the the pi user password into the directly connected keyboard, while the SSH session is still active, Mycroft venv loads up once again and everything works perfectly (audio input/output).
Now I have tried to set it in different ways to auto login on boot. I have installed raspi-config and set it to auto login on CLI, I have tried to set up a systemd getty autologin service, but had no success. So I am thinking that this login prompt is maybe needed for the Mycroft venv, is there any way to set this to auto login? Your help is much appreciated, thanks in advance and keep up the good work!
Mycroft does not work with SSH
Am I correct in understanding that this happens intermittently meaning that sometimes it boots fine, other times you need to enter the password? Or after every reboot you have to connect a keyboard to enter the password?
When your Picroft boots, how far does it get before you have to enter a password? Do you get the “Mycroft Picroft” ASCII art before you enter your password or after?
I’m imagining it just looks like a mostly black screen with:
picroft login: pi password:
Is that right?
I’m assuming there’s nothing useful in
/var/log/mycroft/enclosure.log as it sounds like the system doesn’t get far enough to log anything.
This isn’t resolving the login problem, but for starting services via SSH:
When you login via SSH you create a new shell and it attempts to connect to the existing processes that are meant to have been started already. So the CLI would display but as you’ve experienced there would be no sound or response. If you hit Ctrl+C to exit the CLI and run
mycroft-start all this will start all the necessary services in the background. You can then run
mycroft-cli-client or just wait until it’s had time to load all the skills etc. You can then exit this shell and the services will continue to run.
Thank you very much for your swift answer!
I have to clarify that after every boot I have to connect a keyboard and put in the password. The password is asked immediately after showing the Mycroft Picroft ASCII. and the first thing that happens after the password is accepted is that the alsa devices are listed and then the rest of the process.
Just triggered a reboot now and checked the enclosure.log file and indeed nothing was logged.
But I have to thank you because even though the auto login issue did not disappear, I was able to make all the systems start just by running the two suggested commands in an SSH shell and it also remained on after exiting the shell. All without me having to connect the keyboard to it and type the password.
I would also like to mention that I was thinking that maybe I have set something during the first time I ran the mycroft setup, and I remembered that at some point it was asking me if I want to set up a password for the user, and I chose to set one. I am wondering that maybe this the password I am being asked.
But I can say that besides the interest in solving the mystery, the matter is kind of solved to me because I usually reboot from an SSH shell usually because of glitches or whatnot, so being able to make it boot completely from over SSH does the job.
Well I’m glad that solves your main problem.
I just did a fresh install of Picroft and found that it’s the requirement of a password to run sudo that you would have selected during setup. When Picroft boots the
audio_setup.sh script requires sudo, so this is where it’s getting stuck.
It’s not clear during Picroft setup that this will be required at each boot, so something we should probably look at.