Hello,
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!
Hi atlach,
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.
Hi,
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.
Yes I confirm the same issue, I also confirm the SSH solution.
I would like to understand which are security risks if I disable sudo password. Maybe it is worth not to set it.
Thank You
I’m not sure how picroft is different then say mycroft installed on raspbian and with that said, you can setup autologin by: sudo raspi-config > boot options > desktop/cli > console auto login
If for some reason you don’t have a raspi-config or aren’t on raspbian you can set autologin by doing the follow steps:
sudo systemctl edit getty@tty1
Add the following:
[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin pi --noclear %I 38400 linux
Save and enable the service.
sudo systemctl enable getty@tty1.service
Now when you reboot you will autologin to the user pi.
If you would like to execute commands after login, you can do the following.
nano ~/.bash_profile
[[ -z $DISPLAY && $XDG_VTNR -eq 1 ]] && /usr/local/bin/start-ai
This executes a bash script I created that triggers mycorft to start.
My script looks as such:
#!/bin/bash
sleep 10s
/home/tri/mycroft-core/start-mycroft.sh all
sleep 3s
/usr/local/bin/reset-mic
sleep 12s
/usr/local/bin/connect-speaker
Your script I’m sure would need to be different, but the above should at least give you a gist of what you can do.
As for running sudo without the need of a password, you can do the following:
sudo nano /etc/sudoers.d/010_pi-nopasswd
pi ALL=(ALL) NOPASSWD: ALL
Save the file and that’s it.
I found a simple solution without granting root privilege to to the “pi” user for all sudo commands.
I run picroft on my pi 4 which is headless machine so I only access via SSH. The problem with picroft is upon bootup it runs the script /home/pi/audio_setup.sh which runs the amixer command using sudo. The tty will hang at this point requesting password and wont get any further.
A workaround and a more secure approach is to only allow the amixer program (/usr/bin/amixer) to be run as root by pi and and all other sudo commands, to require password. This is possible by modifying /etc/sudoers. To accomplish this:
- rerun thru mycroft-setup-wizard and REQUIRE that pi prompts for sudo password (lets make it secure)
- without rebooting, exit to picroft cli and run sudo visudo from command line
- add the following line to the bottom: pi ALL = NOPASSWD: /usr/bin/amixer
- save the file and reboot
The config on step 3 basically tells sudo that pi can run /usr/bin/amixer without a password prompt. All other sudo commands will prompt for password. Now Picroft will automatically load without requiring ssh login after a reboot.
Possibly a better solution can be found in the future of picroft - perhaps skipping the amixer setup during login or lowering the process privilege after that command is run in the script.
Edit: Grammer/Spelling
This could be based on how the users speaker is set up perhaps. I have my rpi4 connected to a Jabra 410 so in my case its USB audio as opposed to HDMI audio.
Still figuring out picroft as I just got started with it about 3 days ago. Loving this project so far. Thank you.
those should ensure that it jumps back to the setup state if someone accidentally falls onto the keyboard 
The second problem ist that this script is sourced
source audio_setup.sh # (not explicitly needing the environment; if you bash it, it dies alone)
But this makes me believe almost noone (using picroft) is setting up a password in raspi-config
Good to cover all bases i guess.
I would tend to agree. But would be a good practice to help prevent rogue/bad acting skills or unsanitized data streams from wrecking havoc on the system. Especially as the skill sets grow in numbers and complexity.
Yeah the intention is to switch everything over to pulse. I started doing some of this but there’s a fair bit of work to be done and the internal team are staying very focused on the Mark II for now.
Newbie here. I just got my Picroft set up. I initially set it up while connected to a monitor and keyboard, just because it’s easy; I don’t have to re-establish a connection while rebooting.
It was fairly difficult to persuade the Pi to use my analog speaker and USB mic instead of HDMI while I was connected to the monitor, but I got it working.
Then I thought to myself that I’d like it to be able to come back without intervention after a power failure, or if I move it, and I don’t want to have to keep it connected to a monitor all the time. I rebooted, and—no audio unless I connected to a monitor! So I had to figure that out, and SSH in, and undo everything I did to get it working while it was connected to the monitor.
I know it’s not the primary focus of the team, but it would be nice to have a reference setup on a disk image that just works. Connect and select approved hardware, test the mic and speaker, pair the device.
But I do know that’s a big ask, and that there are plenty of other things to focus on. I also know how complicated audio is on Linux, especially on the Pi, and bravo for getting a Pi version out there at all, actually! And now that it’s working, it seems pretty great!
Hi Peter I’ve had a similar issue but found this guide to be useful particularly the step to edit the mycroft.conf file. Audio Troubleshooting - Mycroft AI
However, this is not my main problem now.
Hi I know this thread is some years old but it doesn’t seem to have a satisfactory or definitive resolution or been overcome in subsequent releases for Picroft.
@gez-mycroft , I’m not sure if you’re able to shed light on this.
I’ve installed and like @Peter_Conrad once I disconnected my Keyboard and HDMI monitor to run the unit headless I ran into issues, principlally no audio which were overcome by using the audio troubleshooting guide, thanks.
But the issue is the Pi 3A unit doesn’t respond at all, UNLESS and ONLY while connected via SSH, and having run the mycroft-start debug command. It works perfectly, but the second I disconnect that’s it the device doesn’t function.
I have another unit running headless and that works fine, but I sent that up so long ago I can’t remember if I had to do anything special to get it work headless. I’m sure once I configured it for USB Speaker & Mic I just disconneted the monitor and keyboard.
Any suggestions would be appreciated, as I’m at a loss at the moment.
Cheers
Through various messing around, my Picroft is working. When I disconnected HDMI, I had to SSH in and change all the audio settings to use card 0, because when you disconnect HDMI (0) then the headphones (1) become card 0. I was also able to re-run setup and get Mycroft the permissions it needed to start up automatically. In the end, lots of Googling and trying random things has helped a lot. It would still be nice to have a reference setup that knows how to switch the audio, knows how to auto-restart, and all that stuff, given that you buy the right hardware (I’m using Blue Ice with great success).
Hi Peter
I’ve re-run the set up several times but not seen an option for Auto-restart, did I miss something? Am I mis-reading/interpreting the messaging?
As I my hardware works. The device responds to the wake word, and I am hearing all messages.
Cheers
Russell
So basically it totally works, but only if you’re connected via ssh?
I have to remind you that my “messing around” was not methodical, and I’m not sure I learned enough to give you a useful answer, BUT
If I had to guess, I would guess that when your PiCroft starts up, it doesn’t have permission to do all the stuff it needs to do (with sudo I think) but when you ssh in, you do have permission. So when you ssh in and the command-line Mycroft application starts, everything works.
IF that guess is right (which, you know, just a guess) then you have to mess around until you see the “let me have sudo permissions” question in the setup. I remember it seemed like I had to do that a couple times for it to believe me, but again I was messing around and didn’t take notes.
That’s the only thing I can think of.