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
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…
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).
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.
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…