root@DietPi:~# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @5.135s
└─multi-user.target @5.134s
└─dropbear.service @5.049s +83ms
└─dietpi-boot.service @4.799s +241ms
└─network.target @4.796s
└─ifup@wlan0.service @4.621s
└─network-pre.target @4.614s
└─dietpi-preboot.service @3.411s +1.201s
└─dietpi-ramdisk.service @2.932s +473ms
└─basic.target @2.913s
└─sockets.target @2.912s
└─dbus.socket @2.912s
└─sysinit.target @2.912s
└─systemd-update-utmp.service @2.877s +34ms
└─systemd-tmpfiles-setup.service @2.819s +54ms
└─local-fs.target @2.816s
└─boot.mount @2.168s +646ms
└─systemd-fsck@dev-disk-by\x2dpartuuid-6
c586e13\x2d01.service @1.844s +320ms
└─dev-disk-by\x2dpartuuid-6c586e13\x2d01.devic
e @1.668s
root@DietPi:~# systemd-analyze
Startup finished in 1.300s (kernel) + 5.170s (userspace) = 6.471s
graphical.target reached after 5.135s in userspace
root@DietPi:~#
Yes, the last list is the original image that I have been using for the digital dashboard for my Boat. It boots up very quickly. The software loading is slow, but to get to the Dietpi screen is 20 seconds.
root@DietPi:~# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @5.001s
└─multi-user.target @5.001s
└─smbd.service @4.203s +796ms
└─network-online.target @4.200s
└─network.target @4.199s
└─ifup@wlan0.service @4.024s
└─network-pre.target @4.017s
└─dietpi-preboot.service @2.815s +1.199s
└─dietpi-ramdisk.service @2.308s +502ms
└─basic.target @2.287s
└─sockets.target @2.287s
└─dbus.socket @2.287s
└─sysinit.target @2.287s
└─systemd-update-utmp.service @2.253s +33ms
└─systemd-tmpfiles-setup.service @2.194s +55ms
└─local-fs.target @2.192s
└─boot.mount @2.142s +48ms
└─systemd-fsck@dev-disk-by\x2dpartuuid-6
c586e13\x2d01.service @1.828s +309ms
└─dev-disk-by\x2dpartuuid-6c586e13\x2d01.devic
e @1.678s
root@DietPi:~# systemd-analyze
Startup finished in 1.304s (kernel) + 5.040s (userspace) = 6.344s
graphical.target reached after 5.001s in userspace
This is the image I would like to modify to open as fast as the original one.
I get a line that states “waiting for Dietpi postboot to finish” It counts for 90 seconds and then finishes the loading.
Looking at this data, it doesn’t show actual boot time.
The trimmed down version of this, without SSH boots in to the Dietpi Graphic in 20 seconds.
I can only take a picture of the chain because the SSH is not enabled. Once it is enabled, it stops for 90 seconds during boot up to wait for Dietpi postboot.
I also noticed that after it starts to finish the boot, there is 4 statements about Services.
Two of them fail on the slow boot image.
Start umbd
Start hostaptd
On my fast boot image those statements read.
Skip nmbd (due to mask)
and the failed statement is
Start hostaptd
So I am trying to look at the differences between the two images and understand what has been shut off in the fast image, compared to the updated version I enabled SSH to.
This will create a file boot.log within the boot partition of the SD card. You should be able to connect the SD card to a Windows/Mac system and copy the log file. Pls attach the whole log.
Slow boot.log is from the updated version of V.6.28 that I updated to Bullseye and it will boot from the M.2 card.
It has the Message "Waiting for Dietpi post boot to finish. And counts the seconds, up to 88s before it moves on and finishes the boot.
Let me know if that tells you something.
I did a file comparison and I see a lot of differences, but I don’t know what it means.
main difference seems to be network configuration. Do you use the network at all? On the slow system, there is some wicd tool installed. This is not part of our standard image and was manually installed, I guess.
Quite weird setup this system. Samba as well as Hotspot seems to be failing. I guess due to missing network connection/configuration.
You are correct. Once it is setup and used for a digital dash, no external connections are need accept for the USB connection to the ECU that manages the engine.
The Wicd is manually enabled and then you can connect to retrieve datalogs that can be stored in the tuning software.
The main purpose of the stripped down version is for it to boot as fast as possible.
There are icons that allow me to enable/disable a network connection, either Wifi or Ethernet.
Both images have the Wicd, but on the fast one, it is not turned on.
I was able to get the fast boot image upgraded to Bullseye… If I could shut off the network stuff to keep it from slowing the boot… That may be better… At least with this upgraded image, I can boot from the M.2, which speeds up the tuning software…
Any thoughts on how to do that??
I can take a video of the start up of each and post a link to view them, if that would help…
My thoughts also. I’m just not sure how it was done. I’m thinking it was done with scripts. In files somewhere. I compared dietpi.config and both are exactly the same. So it has to be in another file. Any idea where to start?
Check in dietpi-config network options: misc whether waiting for network on boot is enabled (default). Without network, this indeed would delay service starts by 90 seconds timeout. And without network you may want to disable network time sync as well.
I took a look where you suggested and this older version didn’t have the option to
So I decided to use my comparison app to look at all the files in dietpi folder. I found some differences, between the slow and fast boot images, but none that pointed to boot up delays, that I could figure out.
So I went back to the person that setup this image in the first place and he had the latest version online still. So I down loaded it, made some updates and then flashed it to my M.2 drive. Still would not boot up from the M.2 drive.
So I decided to do a Dietpi upgrade using one of the tools in his menu.
The previous 6.28 version upgraded to Bullseye, and would boot from the M.2, but had that long delay.
This new image was still v6.28, and the upgrade said it was moving it to 6.35. I forgot to check, but after all the updates, it Does boot from the M.2 drive and does it in less than 20s from power on to the interface screen!!
So after spinning my brain for a couple of weeks and learning a lot about Dietpi!! I am happy to say I was successful in reaching my goal!!