Booting on Pi4 Mate - this now has a 1,5 minute delay

Troubleshooting
1

Because our system worked for years and was very fast (also in booting) I refreshed everything. So I did a new Image from scratch for Raspberry-Pi 4 8GB-RAM.

Everything works as expect, BUT not the loading-process. First impression was the internet-connection, but with the

I’ve got this feedback (changed the @-sign to the %-sign because of board-issues here)

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.

graphical. Target @1min 31.152s
└─lightdm.service @1min 31.027s +122ms
  └─systemd-user-sessions.service @4.901s +70ms
    └─network.target @4.836s
      └─wpa_supplicant.service @5.411s +104ms
        └─dbus.service @3.658s +571ms
          └─basic.target @3.617s
            └─sockets.target @3.617s
              └─dbus.socket @3.616s
                └─sysinit.target @3.595s
                  └─systemd-udev-settle.service @1.424s +2.169s
                    └─systemd-udev-trigger.service @1.023s +386ms
                      └─systemd-udevd-kernel.socket @840ms
                        └─system.slice @707ms
                          └─-.slice @707ms

What is happening there that the graphical-part is now taking a 1,5minute delay before it continous from the shell-mode to switch to the Mate-Desktop? Same screen but older software-version has this effect not…

How can I get more information on that?

2

can you share some more information in our system? Somehow the troubleshooting template was not filled by you :wink:

Required

  • DietPi version | cat /boot/dietpi/.version
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
  • Kernel version | uname -a
  • Architecture | dpkg --print-architecture
  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
3

Sure, sorry.

DietPi Version:
G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=8
G_DIETPI_VERSION_RC=0
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’

Distro version: bookworm 0

Kernel version: Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux

Architecture: arm64

SBC model: RPi 4 Model B (aarch64)

4

as a workaround, you could switch to auto start option 2 : Automatic login. At least if you don’t require a specific user login

5

Thankyou for being so precise! Yes THAT is exact the problem: The autostart!!!

2 in Autostart is already selected - but it seems that THIS is the cause of the long delay.

If I login with the user “dietpi” and use “lightdm” everything is working as expected - and fast. But the Autostart with option 2 doesn’t do it. Okay, there is an effect, but AFTER OVER ONE MINUTE LATER. Do you really don’t have such an effect?

6

I have this effect on auto start option #16 only, there I have lightdm.service

graphical.target @1min 30.959s
└─lightdm.service @1min 30.896s +62ms
  └─systemd-user-sessions.service @10.337s +21ms
    └─network.target @10.290s
      └─ifup@eth0.service @2.804s +7.482s
        └─network-pre.target @2.780s

Option #2 works perfectly. No login screen should appear, and you should see the desktop immediately

graphical.target @11.311s
└─multi-user.target @11.308s
  └─getty.target @11.305s
    └─getty@tty1.service @11.301s
      └─systemd-user-sessions.service @11.272s +20ms
        └─network.target @11.227s

As you can see, 1min 30.959s vs 11.311s

Maybe you can try to activate autostart option 2 again

7

ohh one more observation. How does it behave if you choose option #2 with user root instead of dietpi. I guess it will make a difference :wink:

8

Yes there are different timings in the current dietpi-verion - not so seen in an older release.

with option#2 for dietpi-user was it fine: graphical.target 1m 31.051s
with option#2 for root-user was it fine: graphical.target 17.913s
with option #16 (lightdm-mask without automatic login): graphical.target 1m 30.939s

We need the option 2 for the dietpi-user because the automatic-login is important for us - but this is really slow right in the bootprocess now. :frowning:

9

I don’t think it has a direct link to the version of DietPi. Probable more an issue with the Debian lightdm package. I guess it has been updated via apt.

10

ok found something, can you check following

journalctl -u *.device

At least on my demo system, 2 devices that cause the boot delay have failed. But I was able to mask them and the system boots quickly again.

11

The result of this command is:

Nov 07 11:10:05 DietPi systemd[1]: Found device dev-disk-by\x2dpartuuid-e87e153f\x2d01.device - /dev/disk/by-partuuid/e87e153f-01.
Nov 07 11:11:33 DietPi systemd[1]: dev-dri-card0.device: Job dev-dri-card0.device/start timed out.
Nov 07 11:11:33 DietPi systemd[1]: Timed out waiting for device dev-dri-card0.device - /dev/dri/card0.
Nov 07 11:11:33 DietPi systemd[1]: dev-dri-card0.device: Job dev-dri-card0.device/start failed with result 'timeout'.
Nov 07 11:11:33 DietPi systemd[1]: dev-dri-renderD128.device: Job dev-dri-renderD128.device/start timed out.
Nov 07 11:11:33 DietPi systemd[1]: Timed out waiting for device dev-dri-renderD128.device - /dev/dri/renderD128.
Nov 07 11:11:33 DietPi systemd[1]: dev-dri-renderD128.device: Job dev-dri-renderD128.device/start failed with result 'timeout'.
12

Please try following

systemctl mask dev-dri-card0.device
systemctl mask dev-dri-renderD128.device
reboot
13

YES, that solves this. Tahnkyou VERY MUCH. Do you think that will be solved in the future automatically?

Now it is fast again:
graphical.target: 13.891s :muscle:

14

Honestly, I don’t know. Actually, I’m not sure if these 2 devices are used on RPI. Would need to check with our developer @MichaIng

15

seems to be related:
/dev/dri/card0 creation is significantly delayed on boot

16

@thxstr do you have KMS enabled, i.e. vc4-kms-v3d in dietpi-config deplay options, respectively dtoverlay=vc4-kms-v3d in /boot/config.txt?

And if so, can you try to install the Debian LightDM build, instead of the one from RPi Ltd? The have an own build, with a changelog entry that the X server shall be attempted to restart, when failing. I all non-binary files/configs (aside of the changelog) are however identical, so either it is a change in binary source code, or obsolete in the meantime.

echo -e 'Package: src:lightdm\nPin: origin archive.raspberrypi.com\nPin-Priority: -1' > /etc/apt/preferences.d/dietpi-lightdm
apt update
apt install --reinstall --allow-downgrades lightdm=1.26.0-8
17

I took the last image again (without the changes from above, so that my start takes 1,5minutes longer)

Yes, in the config.txt is the entry:
dtoverlay=vc4-kms-v3d

I was not able to execute the echo-command, but the last two lines of your suggestions. And YES, the start was as fast as before (without the 1,5mins delay)!

18

well this was just a downgrade of lightdm package to version 1.26.0-8. Can you share output of

apt update && apt list --upgradable
19

Image (3)
Image (3)1920×1440 383 KB

Image (5)
Image (5)1920×1440 381 KB

20

pls connect via SSH and copy whole text from your SSH client. This will be better readable :wink: