Hi. I am running Dietpi from a rock pi4b board. And I have some doubts / problems:
The first thing that worries me is that the start takes a long time. I have not timed it, but I think it takes easy up to 2 minutes or more to get the desktop screen (LXDE desktop installed)
I have had problems with the wifi connection, (I do not dare to say that I fix it, because in fact I am not sure it is so), but the truth is that after making some changes in the configuration it is now working. For the one that interests you, I have disabled ipv6. Also disable mac randomization with the following command (echo -e “[device] \ nwifi.scan-rand-mac-address = no” | sudo tee /etc/NetworkManager/conf.d/disable-random-mac.conf), but as I have taken it from another site with a similar problem with the wifi, the reality is that I do not know for sure if that command has affected my dietpi system in any way.Anyway, right now I am writing from the rocpi board with wifi working fine.
The other problem that worries me is that the CPU frequency limits were disabled by default. At one point the temperature of the board was reaching 71º centigrade. I have set it to min = off and max = 1512 mhz.
I would appreciate someone to give me a hand to reduce boot times.
Regards
Hi,
many thanks for your message. Right after reboot, execute the following on command line
systemd-analyze blame
this should give some indication where most of time is spend on during boot.
Hi, thanks for the prompt reply. here I paste the command output
systemd-analyze blame
31.428s dietpi-boot.service
24.294s dev-nvme0n1p7.device
4.715s systemd-udevd.service
3.479s systemd-modules-load.service
3.369s resolvconf.service
3.171s dev-hugepages.mount
3.074s systemd-udev-trigger.service
2.553s sys-kernel-debug.mount
2.453s systemd-tmpfiles-setup-dev.service
2.361s systemd-remount-fs.service
2.312s dev-mqueue.mount
2.274s systemd-sysusers.service
2.020s kmod-static-nodes.service
1.723s fake-hwclock.service
1.333s keyboard-setup.service
1.303s networking.service
1.247s systemd-journald.service
932ms systemd-journal-flush.service
334ms tmp.mount
317ms upower.service
309ms var-log.mount
247ms sys-kernel-config.mount
232ms systemd-sysctl.service
222ms sys-fs-fuse-connections.mount
212ms proftpd.service
192ms systemd-random-seed.service
181ms user@0.service
173ms dietpi-preboot.service
87ms systemd-fsck@dev-disk-by\x2duuid-8bb79367\x2df07
c\x2d41a8\x2d9ae9\x2d0539a80c397e.service
78ms systemd-logind.service
60ms ifupdown-pre.service
53ms dietpi-ramlog.service
43ms alsa-restore.service
37ms dropbear.service
34ms user-runtime-dir@0.service
29ms polkit.service
29ms systemd-tmpfiles-setup.service
24ms systemd-user-sessions.service
24ms systemd-update-utmp.service
22ms systemd-update-utmp-runlevel.service
18ms console-setup.service
17ms boot.mount
16ms systemd-rfkill.service
basically it looks like 2 challenges.
31.428s dietpi-boot.service
24.294s dev-nvme0n1p7.device
Let me do a guess:
First one seems to be related to network time sync taking around 30 sec. Can you check journalctl -u systemd-timesyncd.service right after reboot pls
Secound one seems to be a slow/old RootFS. Around 24 sec to have RootFS mounted is quite a long time. On my RPi4B, its around 1 sec.
Hi. The output of the command does not give any extraordinary result:
journalctl -u systemd-timesyncd.service
– Logs begin at Thu 2019-02-14 07:12:16 -03, end at Mon 2020-07-13 23:02:19 -03
. –
– No entries –
As for slow / old rootFS, I don’t know how to fix it. Would it be a matter of updating it? I am using a multiboot image, provided by people from the radxa / rockpi page, because in fact it is the only way I managed to boot from nvme.
I guess it’s the SD card that seems to be slow.
Strange that systemd-timesyncd.service doesn’t have any output. Usually it should display time sync attempts. Is it same right after reboot?
Hello, I am sorry for the delay in responding.
Can you check journalctl -u systemd-timesyncd.service right after reboot pls
sudo systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; disabled; vend
or preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
└─disable-with-time-daemon.conf
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)
I want to make a clarification pertinent to the boot system that I am using at the moment:
It is a system provided by a member of the Rockpi forum. A multiboot image, which with a series of commands can create a medium (in this case an nvme disk) that can bounce various operating systems. I paste a link if necessary. About multiboot - ROCK 4 Series - Radxa Forum
I say this so that you know that I have an Armbian image on the same support, which incidentally bounces in less than a minute, and also the Dietpi image, which takes about 4 and a half minutes to reach the desktop screen. That said, I think the problem has to do with the nucleus, because investigating in the rockpi forum, they say that although there are several images of Armbian, the only stable one is that of nucleus 4.4. The newer kernel image (5.4) has slow boot. So maybe it’s a problem with Dietpi’s nucleus, which according to una -a is 5.4.49
regards
Hi,
just for clarification. DietPi did not and will not create own kernels. The kernel is provided by the underlying Debian base image, always.
Ok, so there is no way to solve such slow system startup around here?
well you could install plain Armbian Buster Legacy image (kernel 4.4)
https://dl.armbian.com/rockpi-4b/Buster_legacy
and try to run DietPi PREP script afterwards to install DietPi on top. But no guaranty that it will work that way
https://github.com/MichaIng/DietPi/issues/1285
Hi. But in the case of getting the image with kernel 4.4. Wouldn’t it switch to the newer one when I update / upgrade?
could be. something to test. Unfortunately I don’t have a RackPi4 board.