I have AUTO_SETUP_AUTOMATED=1, and this works well, however, I must login in order for the setup to start, then I usually login again after auto-restart, then usually it restarts a second time and I log in a third time, then it’s settled in. I’m actually aiming to setup my services where I insert the prepped SD card and supply power and then it should boot up install setup and go. Is there any configuration option, kind of like the GUI auto-login option, that lets the machine boot through the setup script, change hostname, run any install ids, then the post setup script without needing to login? If there’s errors of any kind of whatever, it can blow up, but I’d like if it worked without login where I will eventually see my service online and the hostname for the IP is renamed from DietPi to the name set in dietpi.txt.
I hope that made sense.
Thank you very much, I’m glad this image exists it simplifies a lot.
If this feature is unavailable, what would be needed in order to be able to do such a thing?
Hi again! I just got a chance to work on this a bit more, and right now I’m tempted to make a script from a host machine that just automatically ssh’s in… but I wonder why an active login is needed at all? I’ll keep digging into it, I know automated setup isn’t the normal use case, just hoping to make this work.
I was already thinking the same. But for sure dietpi-update and dietpi-software need some deeper rework to be able to run them without login. Currently they e.g. call the $HOME variable and other things that are only available after login. Those would need to be changed, e.g. to /root, so the default home dir of the root user. Actually no big deal, but there might be other things like that.
Another approach would be to enable autologin, as we do when user chooses console autologin via dietpi-autostart.
I find that interesting and opened an issue on GitHub: https://github.com/Fourdee/DietPi/issues/2520
Thanks so much for your reply! I wondered if there might be some possibilities with the method from the autologin option, but then I figured one is usually logged in by then, so I wasn’t sure. I’ve subscribed to the issue and might try to locally implement one of those bullet options as either sounds better than my original thought.
I may try to offer a pull request, but I’ll need to look into your structure a bit more first.
Would the $HOME substitution method be better as a script which some ‘autoinstall’ /boot/dietpi.txt option enables, or could the substitution just be made in general and the option just enables auto-starting the install?
Can migrate to the issue if it gets much more technical than this.
Theoretically the $HOME and ~/ substitution can be anyway safely done, since the script assures to run as root user anyway. However it breaks support for moving the root users home dir. But across various scripts (not only DietPi) it is expected to be /root anyway. It is even defined in the FHS: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
So definitely okay to expect it and do the above substitution.
But it might be not sufficient for running dietpi-software outside a login shell. Needs testing, theoretically ging through all software installs that can run non-interactively.
So indeed I think, the autologin approach is easier to achieve without too much failsafe testing. Here is how we do this in dietpi-autostart: https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-autostart#L109-L114
Only issue with that:
- To activate the change, systemd needs to be reloaded via: systemctl daemon-reload
- I am not 100% sure about possible issues, when doing this during systemd walking through the enabled systemd units.
- Needs testing on Jessie, Stretch and Buster, if the boot order is resumed as if nothing has happened, only with the above drop-in in place.
Or course a PR would be highly appreciated .