Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
While investigating the boot time difference in this particular x86_64 PC case, I couldn't replicate the 15s anymore in 3 individual attempts. The remaining difference is due to: - "guiet" kernel command-line argument adds ~0.5 seconds. Surprising that printing to screen/console is so heavy, respectively it seems to not be done asynchroniously. - Another ~0.5 seconds, more depending on Ethernet vs WiFi and DHCP vs static IP + local network setup, is added by our ifup@+ifupdown-pre service overrides, and that dietpi-postboot pulls in network-online.target into the boot sequence by default (dietpi-config option "Boot wait for network"). ifup@ services are oneshot on DietPi instead of "Type=simple", to give the network-online.target more meaning, waiting for interfaces to be up, instead of only for the startup procedure to just have started. But even that dietpi-postboot is "Type=idle", not actually making network-online.target dalying boot, network.target is delayed as well, which does have an effect on the boot sequence. ifupdown-pre.service is altered to imply "udevadm settle" as well when only "hotplug" interfaces are configured. On stock Debian, "hotplug" is also used by default, but in this case, ifupdown-pre.service does not wait for udev events to settle. Hence on Debian, network targets can be reached before network adapters even have been detected, again breaking the meaning of those targets. Overall, if a service depends on network, stock Debian has no native method to make them start reliably after network is online. Since this was an ongoing problem for many common server systems, we applied and polished these changes, and they are totally worth a little longer boot time. And of course, this is mostly visual only, and for these kind of comparisons/benchmarks, while in practice, SSH logins are simply not possible before network is there, and the local console login prompt on DietPi can appear before network is there: This larger number hence does not have any practical downside, but the reasons for it have many practical benefits. - Removing those two differences, DietPi boots faster, despite our additional ramdisk and preboot services. Those have no measurable impact, but the additional services stock Debian is shipped with (dbus, logind, apparmor, anacron, ...) and probably our mount options (noatime,lazytime) do in sum have some positive effect on boot time.
- Loading branch information
