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!
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.
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.
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 email@example.com
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.
[[ -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.
2 posts were split to a new topic: No valid sudoers source
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.
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.