Boot Times on Pi Zero W

dietpi@DietPi:~$ sudo systemd-analyze
Startup finished in 3.613s (kernel) + 47.706s (userspace) = 51.320s reached after 47.531s in userspace
dietpi@DietPi:~$ sudo systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character. @47.531s
└─ @47.530s
  └─dropbear.service @47.263s +266ms
    └─dietpi-boot.service @13.075s +34.165s
      └─ @13.067s
        └─dietpi-preboot.service @11.717s +1.336s
          └─dietpi-ramlog.service @11.323s +373ms
            └─ @11.303s
              └─ @11.292s
                └─systemd-update-utmp.service @11.020s +268ms
                  └─systemd-tmpfiles-setup.service @10.514s +489ms
                    └─ @10.460s
                      └─boot.mount @10.356s +101ms
                        └─systemd-fsck@dev-disk-by\x2dpartuuid-0e2887fb\x2d01.service @9.127s +1.210s
                          └─dev-disk-by\x2dpartuuid-0e2887fb\x2d01.device @8.684s

I installed DietPi hoping to get a boot time that could beat the ~20seconds I was getting to on Raspbian Lite.

I’m running an internet radio that basically consists of an amp/speaker, lcd screen, and a few buttons, a rotary encoder, and a few leds. As I’m setting up the sound, etc. I’m noticing that the boot times are almost double what I was starting with on Raspbian.

dietpi-boot.service is clearly the primary culprit, my question is if it is normal at all for that service to take so long, and how might I stop it from taking so long?

Hah, after searching for 30 minutes and not finding anything I decided to post a question.

Of course, 5 minutes later I found a solution with a slightly different search term :thinking:

Turning off the network time sync in /boot/dietpi.txt seems to have done the trick

# Network time sync: 0=disabled | 1=boot only | 2=boot + daily | 3=boot + hourly | 4=Daemon + Drift

dietpi@DietPi:~$ sudo systemd-analyze blame
9.473s ifup@wlan0.service
6.472s systemd-random-seed.service
5.514s dev-mmcblk0p2.device
3.177s keyboard-setup.service
2.818s systemd-udev-trigger.service
2.091s systemd-journald.service
1.508s dietpi-boot.service
1.348s systemd-fsck-root.service
1.348s dietpi-preboot.service
1.307s networking.service
1.263s systemd-fsck@dev-disk-by\x2dpartuuid-0e2887fb\x2d01.service
1.086s systemd-rfkill.service


if time-sync takes that much time, your system is not having a valid network connection at the beginning or the used NTP server is not responding in time. Disabling the time-sync isn’t a good idea as your system will now running incorrect system time, and this could lead to other issues.

I’m pretty sure what’s happening is that the time stamps for the services are shifted when the system time is synced to the NTP server.

If I run a reboot cycle only changing the NTP setting, it takes 34-36 seconds on a stopwatch to getting my radio.service started (I stop the watch when I see the lcd on my radio indicate that the program is running).

Setting CONFIG_NTP_MODE=1 increases the recorded time for dietpi-boot.service by a lot (30-45s), but has no apparent change in reality.

I’m leaving NTP on.

Separately, systemd-random-seed.service seems to be taking a lot of time (~6-7s).

From reading around it seemed that running haveged helped some others with the same issue on Arch; no help for me.

It seemed that haveged helped for those systems where entropy was low, as I read things, >1000 for entropy_avail should be totally fine.

dietpi@DietPi:~$ sudo cat /proc/sys/kernel/random/entropy_avail

Doesn’t seem to be my problem.


can you have a look pls

Do you have a static IP applied or DHCP? Generally I’d recommend a static IP on any server to skip the DHCP lease step.The second thing is the time sync, so you may try to use a different NTP server, at best your router itself, if it serves as NTP server as well (many do): dietpi-config > Network Option: Misc > NTP mirror > Gateway, or one in your country, like in UK.

We really need to put the time sync into background. I have already an idea how, including the removal of dietpi-boot.service in favour of the now more meaningful (since a few versions already). I’ll have that as a target for v7.6, which should reduce boot times significantly when DHCP and/or time sync takes a while.

The random seed btw doesn’t seem to be part of the critical chain, so while it takes some seconds, it doesn’t prevent boot to continue. In fact, a quite recent change in the RPi kernel enhanced the situation by making available another entropy source on early boot stage, before the entropy daemon kicks in:
haveged is not required, as RPi has a hardware random generator which is used by the installed rng-tools5 (rngd process).

Thanks for the reply.

Static IP set, and tried local NTP mirror as well as router. When I started thinking about the router, I’m guessing that’s really the primary culprit; it’s closing in on 10 years old and being shared by a ton of devices with really limited options for QoS settings.

Re: timesync in the background, FWIW, I’m playing with the radio in parallel on Raspbian Lite and DietPi. In Raspbian the time syncs/updates about 10s after I have an audio stream playing.

Novice here, but my sense is that on a Pi Zero with a single core, there’s time to be gained by killing/shortening processes that are running in parallel to the parts of the critical chain. Random-seed seems to run right along side dev-mmcblk0p2.device, I know when I killed keyboard-setup that there was ~1s reduction in the time for that even though keyboard-setup was also not critical chain. It could just be my novice eyes though as I’m focused too much on that big random-seed time in DietPi when I’m seeing ~350ms for it in Raspbian. All of that happens within the first 10s of user space, which all seems not to be captured by critical-chain.

Makes sense that a single-core device cannot benefit from parallelism too much, but considering that many boot tasks make use of quite different hardware resources, it will still benefit: The root mount depends on hardware initialisation of the SD card, probably udev, time sync on network initialisation and initial connection time, others may be limited by disk I/O speed and others may limit the CPU alone. Would be actually interesting to see a details CPU load, RAM, net and disk I/O evolution during boot, together with the currently running tasks. Only problem may be that the monitoring itself may consume significant CPU time on such a little SBC and hence messes with the true results :wink:. Not sure if there is some way that is more integrated into the kernel or at least into systemd :thinking:.