Rockpi4b issues

[aguapi]

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

[Joulinar]

Hi,

many thanks for your message. Right after reboot, execute the following on command line

Code: Select all

systemd-analyze blame

this should give some indication where most of time is spend on during boot.

[aguapi]

Hi, thanks for the prompt reply. here I paste the command output

Code: Select all

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

[Joulinar]

basically it looks like 2 challenges.

Code: Select all

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.

[aguapi]

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.

[Joulinar]

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?

[aguapi]

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. https://forum.radxa.com/t/about-multiboot/2838

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

[Joulinar]

Hi,

just for clarification. DietPi did not and will not create own kernels. The kernel is provided by the underlying Debian base image, always.

[aguapi]

Ok, so there is no way to solve such slow system startup around here?

[Joulinar]

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