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
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
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
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…
how does it behave while switching back to DHCP?
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 ?
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.
- 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…
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…