This is no valid shell syntax but a cron job entry. If you do not need it (seems to be about a Python script to update some DNS entry?), remove or comment it.
Furthermore, the ongoing choosing fan reg 0x7 log spam indicates that /root/fan/fan.py runs as ongoing process, so /root/fan/screen.py is never called. This matches your observation that the OLED screen doesn’t work. Those two scripts need to be called via separate services. I suggest something like that:
cat << '_EOF_' > /etc/systemd/system/fan.service
[Unit]
Description=Custom fan script
[Service]
SyslogIdentifier=fan.py
ExecStart=/usr/bin/python3 /root/fan/fan.py
[Install]
WantedBy=multi-user.target
_EOF_
cat << '_EOF_' > /etc/systemd/system/screen.service
[Unit]
Description=Custom screen script
[Service]
SyslogIdentifier=screen.py
ExecStart=/usr/bin/python3 /root/fan/screen.py
[Install]
WantedBy=multi-user.target
_EOF_
systemctl daemon-reload
dietpi-autostart 0
systemctl enable --now fan screen
The startup.sh is broken in two ways, regarding vcgencmd (I posted the command above to assure the package is installed) and a syntax error as well. Should be reported to the developer of this script. Doesn’t this script actually double with the fan.py, or what different purposes do both have?
Shutdown looks fine until last possible log:
May 06 16:49:51 tubzpi.xyz systemd-journald[145]: Journal stopped
The journal is what catches and stores the system logs, so after it is stopped, there are no more system logs possible. More can only be seen via serial console.
What do you mean by “Nvm”? Which log entry?
It is btw normal that logs from before reboot and after reboot are mixed: Until the network time sync is done, the system knows only the last stored timestamp from when the fake-hwclock.service was stopped, so at least for one second there is an overlap and you can only differentiate by the -- Boot entries which show which logs belong to which boot session. Luckily with Debian Bookworm, this is better, and logs are grouped by boot session blocks.