Reboot After Install Inconsistent Behavior

Troubleshooting
1

I’m working towards a truly handsfree/headless setup process (and then documenting it as a tutorial). This is the first in a series of questions I’ll post here; the conclusion will hopefully be a streamlined, hands-free flash-/initialize-board process. Happy to share what I end up with.

Where would the cleanest “reboot-after-install” point be? In order to cleanly register a custom-hostname board on a network, I’d like to reboot it after the first-boot setup succeeds. Is there a good place to do that?

Adding a reboot at the end of Automation_Custom_Script.sh works well for the ARM-64 bit image, but causes the ARM-32 bit image to restart the install process over.

2

MichaIng
if I’m not mistaken, we had a similar request in the near past about the point where to perform an automated reboot on first install. But I could not remember the exact case.

3

Ah yes that is true. I actually wanted to change that already, done now: https://github.com/MichaIng/DietPi/commit/4a3767b2168fc6ca4eeb1efc29703d190e24dc3b

As a workaround, do

echo 2 > /boot/dietpi/.install_stage

in your Automation_Custom_Script.sh.

4

I my setup process, I want the Pi to reboot after the basic setup, and then continue running a custom setup script for other things I want to be installed.
If possible, I want to have this fully automated, no manual steps in between.

The reason is that I change the hostname in dietpi.txt. In my custom scripts I assume the new hostname to be active, so that needs a reboot first.

What would be the best way to achieve this?

5

For the script-internal environment hostname can be used to set it immediately, but I’m not sure how thoroughly the effect is on the parent shell. But worth to give it a try to skip the additional reboot.

If you need a reboot, to not repeat all the other firstrun setup steps, I’d go with the above solution to force a reboot, but before that, place the second part of your script/steps to /var/lib/dietpi/postboot.d/<script_name>. Scripts in this directory are automatically executed by dietpi-postboot.service, running at the end of the boot process (but before the login prompt). The script could then (re)move itself as last step, to not be repeated on subsequent boots.

So like this:

#!/bin/bash

# Steps to run now
... first part of custom setup steps

# Create script for steps to run after reboot
cat << '_EOF_' > /var/lib/dietpi/postboot.d/custom_script_part2
#!/bin/bash

... second part of custom setup steps

# This script shall run only once
rm /var/lib/dietpi/postboot.d/custom_script_part2
_EOF_

# Do not repeat firstrun setup despite manual reboot
echo 2 > /boot/dietpi/.install_stage

# Failsafe, force sync to disk
sync

reboot
6

Thanks.

I investigated the hostname, and a reboot is really required. Otherwise, the hostname command still returns the default DietPi name.

In the meantime I have a solution that works, but it has still an issue.

#!/bin/bash
hs=`hostname`
if [ "$hs" == "nosey" ]; then
	echo `date` start running jansible bootstrap | tee -a /var/tmp/dietpi/logs/bootstrap.log
	curl https://gitlab.com/janvv/jansible/-/raw/main/bootstrap | bash -s -- -p <my-ansible-vault-pwd>
	echo `date` ready running jansible bootstrap | tee -a /var/tmp/dietpi/logs/bootstrap.log
	rm -rf /boot/Automation_Custom_Script.sh
	rm -rf /boot/AUTO_CustomScript.sh
	rm -rf /var/lib/dietpi/license.txt
else
	echo `date` reboot | tee -a /var/tmp/dietpi/logs/reboot.log
	reboot
fi

So this forces a reboot if the hostname is not active yet.
The mechanism works perfect, but then I run into another issue: in my Ansible playbook I do install additional software depending on the hostname.
I made an Ansible role that runs 'dietpi-software install ’ .
This command gives an error, because dietpi-software is still in memory, because it is finalizing the setup process. The Ansible steps fail with the error message that dietpi-software is already running.

In the end all is good. Part of my setup is to configure a cron job that checks each 15 minutes if the Ansible plays needs to run.
But still… it would be nice to have it running successfully the first time.

7

yes correct, you are not able to run dietpi-software multiple times. This is to avoid inconsistency due to concurrent runs.

8

Great that the script works.

Why don’t you install the additional software on first boot by adding related AUTO_SETUP_INSTALL_SOFTWARE_ID= entries to dietpi.txt? Much cleaner and less overhead :slight_smile:. Otherwise you could do a

while pgrep dietpi-software > /dev/null; do sleep 1; done

to wait until the other dietpi-software instance has finished.