X86: Hanging for 5 min on reboot when using Dietpi autostart

Troubleshooting
1

I enabled on a small x86 MiniPc (Z83-f) the same autostart script in custom.sh as I got in perfectly running on arm devices:

echo 2 > /proc/irq/162/smp_affinity_list
echo 1 > /proc/irq/161/smp_affinity_list
exit 0

Here are the obversations:

  • When I reboot, the device needs 5 minutes to come back on SSH, you would think the devise is frozen.
  • When I systemd-analyze blame I dont see anything unusuale and it says it needed only 15sec for boot
  • When I use option 14 the script does not get executed, the irq wont be assigned to a different core
  • When I use option 17 the script gets executed
  • In neither case /boot/dietpi.txt gets updated automatically with the boot option from the dietpi-config program

I have the exact same setup running smoothly on arm devices…something is different on the Intel front. When I execute the script as a root user manually: no issues. IRQ get changed as intended

2

Do you have a monitor, have you checked the /var/log/dmesg files

There could be something hanging waiting for dhcp or something else

Some discussion of the “hang” here

Hanging at Starting DietPi-Autostart custom script… - General Discussion - DietPi Community Forum

3

I disabled them now for the moment and it hangs as well …I changed the network adress to static and since then it hangs…and also not consistently…sometimes 2 min, sometimes 5 min…

4

how does it behave while switching back to DHCP?

5

Than we are at under 1 minute…will test this further…

but I dont want dhcp…I want the same IP adresse plus i dont want the dhcp software to be running all the time in the backround…

so, why is booting so slow when using static ?

6

Both boot options do not affect the time when the SSH server is started:

  • Option 14 runs independent of any login at the end of the boot process, and nothing depends on it.
  • Option 17 runs after login on local console (not SSH) and enables autologin on local console, and nothing depends on it either.

/boot/dietpi.txt is intentionally not updated, the autostart index is stored in /boot/dietpi/.dietpi-autostart (if not 0). But actually it wouldn’t hurt to keep both aligned. I’ll think about this, for consistency.

If option 14 does not run it, please check journalctl -u dietpi-autostart_custom whether the service runs and for the scripts output.

To check why SSH takes long to start, please check journalctl for complete boot logs.

When assigning a static IP, the device should be available quicker than with DHCP. But probably the router has an issue with it if it would assign a different IP, probably has a reserved IP (?) for the device. I personally reserve DHCP IPs in my router for all (non-guest) devices in my home network, and assign the same IP as static IP on some of them (all Linux systems at least).

1 Like
7

I am just steeting up a second Z83 to compare the effects of a Real-time-Kernel (works like a charme…DietPi RT !!!) vs normal.

I observe:

  • 14 works.
  • DHCP is as slow as Fixed IP
  • It seems to be an issue with the IRQ-affinity statement for the eth0 to be forced to run on an isolated core itself. It “feels” like this statement and the driver are fighting each other…as somehow magically I had running Eth0 before I forced it to run on core 1…running on core 3…which was a surprise as this was an isolated core already…gave MPD affinity 3 only…so I did not expect eth0 to run on that core (isolcpus=1.3) but on core 0.

Need to test a bit more…

8

Ok, I believe the behavior has nothing oto do with Dietpi. I have set isolcpus as Kernel command and that immedieately brings you 1 min more boottime and adding more kernel commands seem to make it even longer…so I have just to be more patient…the system comes back…