Hi, I have dietpi installed on my raspberry pi 4 4 gb and for some time the reboot command does not work, the machine turns off and does not turn on, I have to unplug the power cord and put it back on to turn on. …any solution??
are you sure the system has been turned off? Or could it stuck on shutting down as well? Any possibility to force the behavior?
I did some tests and found that the restart only works with the hdmi cable plugged into the tv, without it the raspberry turns off but does not start, the cooler remains on but the ethernet cable led off and does not turn on… very strange
Index quite an interesting behaviour.
MichaIng
Any ideas?
I remember there was a similar case some year(s) ago on GitHub, but can’t find it anymore and don’t remember whether there was a solution or not. Does the reboot work when you unplug the HDMI cable from the Pi? Also, on the still running system, please show the output of:
dmesg -l emerg,alert,crit,err
If the kernel does not indicate something voltage/power related while the system is still running, probably persistent system logs will help:
dietpi-software uninstall 103
mkdir /var/log/journal
reboot
To revert to RAM logging:
systemctl stop systemd-journald
rm -R /var/log/journal
systemctl start systemd-journald
dietpi-software install 103
Thanks, after using your command the restart is working.
this is quite interesting, because the commands did not do anything. They show kernel error messages and enable persistent logging only 
strange, so it must be some bug that works sometimes yes and sometimes no … 
At least now persistent system/kernel logs are enabled, so when it happens again, via journalctl command you should be able to see the logs from shutdown phase, which probably gives a hint.
what hardware changed before the issue started?
(new powered usb hub?)
are you using a audio extractor or powered hdmi switcher?
I’m not using
hello could someone look at my log to solve my reboot problem?
1log- rebooted via ssh 11:07 am ,at 11:09 i unplugged and reinserted the power cord.
https://drive.google.com/file/d/1LxdSAWVIbl8cnIcTDrTHLDUtTyXXq7xA/view?usp=sharing
2log- rebooted via ssh 13:13 pm ,at 13:20 i unplugged and reinserted the power cord.
https://drive.google.com/file/d/1CHCcgjP0KOFUF0h4huwlzv9OAEgodi-n/view?usp=sharing
At the end of the file is a --More–, so there are lines missing!
You have maybe several problems, I just searched for the string “fail” in the first dump:
Mar 23 11:07:15 DietPi systemd[1]: Unmounted /mnt/ad136f98-d995-4186-b33a-19ecb1b6be20/dietpi_userdata/docker-data/overlay2/21bd197b3885cb5fee9eecaed186daa988ea0752fe6943e5c00ae9bf513e692b/merged.
Mar 23 11:07:15 DietPi systemd[1]: Unmounting /mnt/ad136f98-d995-4186-b33a-19ecb1b6be20...
Mar 23 11:07:15 DietPi umount[7848]: umount: /mnt/ad136f98-d995-4186-b33a-19ecb1b6be20: target is busy.
Mar 23 11:07:15 DietPi systemd[1]: mnt-ad136f98\x2dd995\x2d4186\x2db33a\x2d19ecb1b6be20.mount: Mount process exited, code=exited, status=32/n/a
Mar 23 11:07:15 DietPi systemd[1]: Failed unmounting /mnt/ad136f98-d995-4186-b33a-19ecb1b6be20.
-- Reboot --
Mar 23 11:07:25 DietPi kernel: bcm2708_fb soc:fb: Unable to determine number of FBs. Disabling driver.
Mar 23 11:07:25 DietPi kernel: bcm2708_fb: probe of soc:fb failed with error -2
-- Reboot --
Mar 23 11:07:25 DietPi systemd[1]: Unset automount mnt-ad136f98\x2dd995\x2d4186\x2db33a\x2d19ecb1b6be20.automount.
Mar 23 11:07:25 DietPi systemd[1]: Unmounting /tmp...
Mar 23 11:07:25 DietPi systemd[1]: Unmounting /boot...
Mar 23 11:07:25 DietPi systemd[1]: mnt-ad136f98\x2dd995\x2d4186\x2db33a\x2d19ecb1b6be20.mount: Failed with result 'exit-code'.
-- Reboot --
Mar 23 11:07:25 DietPi systemd[1]: Hardware watchdog 'Broadcom BCM2835 Watchdog timer', version 0
Mar 23 11:07:25 DietPi systemd[1]: Failed to set timeout to 600s: Invalid argument
Mar 23 11:07:25 DietPi kernel: printk: systemd-shutdow: 36 output lines suppressed due to ratelimiting
Mar 23 11:07:27 DietPi ifup[355]: Cannot find device "usb0"
Mar 23 11:07:27 DietPi ifup[355]: ifup: failed to bring up usb0
Mar 23 11:07:27 DietPi systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Mar 23 11:07:27 DietPi systemd[1]: networking.service: Failed with result 'exit-code'.
Mar 23 11:07:27 DietPi systemd[1]: Failed to start Raise network interfaces.
Mar 23 11:07:33 DietPi systemd[519]: pam_unix(systemd-user:session): session opened for user pihole by (uid=0)
Mar 23 11:07:33 DietPi systemd[519]: gpgconf: running /usr/bin/gpg-agent failed (exitcode=2): General error
Mar 23 11:07:33 DietPi systemd[519]: gpgconf: fatal error (exit status 1)
Mar 23 11:07:34 DietPi containerd[502]: time="2022-03-23T11:07:34.489773068-03:00" level=info msg="skip loading plugin \"io.containerd.snapshotter.v1.aufs\"..." error="aufs is not supported (modprobe aufs
failed: exit status 1 \"modprobe: FATAL: Module aufs not found in directory /lib/modules/5.10.103-v8+\\n\"): skip plugin" type=io.containerd.snapshotter.v1
Mar 23 11:07:50 DietPi perl[867]: pam_unix(webmin:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=root
I don’t know how severe these failures are, but I also found this:
Mar 23 13:26:43 DietPi kernel: EXT4-fs (sda1): error count since last fsck: 603
which means you have a corrupted hard drive?! I’ not sure!
the log is not really clear as at a specific moment it start to mix shutdown task together with startup process. This is because the time stamp will be saved to disk during shutdown and reused on reboot.
Mar 23 13:13:26 DietPi systemd[1]: Reached target Reboot.
Mar 23 13:13:26 DietPi systemd[1]: Stopping Restore / save the current clock...
Mar 23 13:13:26 DietPi systemd[1]: Shutting down.
And Mar 23 13:13:26 is used on reboot again (until a time sync happen)
Mar 23 13:13:26 DietPi kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd083]
Mar 23 13:13:26 DietPi kernel: Linux version 5.10.103-v8+ (dom@buildbot) (aarch64-linux-gnu-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1529 SMP PREEMPT Tue Mar 8 12:26:46 GMT 2022
But looking to the log will show that the booting message happen before the shutting down message appears. Something we can’t change. I guess system is not able to handle the “double” time stamp correctly and is simply mixing them at that moment. I hope my explanation did not confused that much 
Doesn’t matter. For me it looks like it is reaching the correct point to reboot.
MichaIng
can you have a look to the 2 log files pls.
Hmm, the userdata drive /mnt/ad136f98-d995-4186-b33a-19ecb1b6be20 fails to unmount, likely because some service has not yet fully stopped. Should however not be a real issue.
It seems in /etc/network/interfaces(.d/) a usb0 interface is configured, which is not attached (usually USB gadget mode Ethernet). This makes the ifup and network targets fail. I’d remove or comment that interface declaration, at least the “allow-hotplug usb0” resp. “auto usb0” line to not have systemd trying to start it automatically.
The bcm2708_fb failures are expected when having only 16 MiB GPU memory assigned (default, reasonable for headless and server systems): The driver cannot fully load then, but it is not required either.
The filesystem errors are indeed something you should fix:
> /forcefsck
reboot
# after reboot check the logs:
journalctl -t systemd-fsck
The last logs from the shutdown phase I see are:
Mar 23 11:07:26 DietPi systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Mar 23 11:07:26 DietPi systemd-journald[126]: Journal stopped
Aside of the failing userdata drive unmount, it looks good, shutdown and reboot targets are reached .
I wonder whether this suppressed logs would give a hint, near the end of the complete shutdown logs:
Mar 23 13:13:26 DietPi kernel: printk: systemd-shutdow:
34 output lines suppressed due to ratelimiting
Try to raise the rate limit (this is only temporary until next boot):
echo 1 > /proc/sys/kernel/printk_ratelimit
echo 50 > /proc/sys/kernel/printk_ratelimit_burst
hi inserted your commands and the raspberry reboot works , but I still need to do some tests, because sometimes the reboot works for awhile(Very rare).Logs>>>
https://drive.google.com/file/d/1FfxVZvjx_Xr_GpOubPc6eLptoKgWARhA/view?usp=drivesdk
https://drive.google.com/file/d/1kLv5pICZuo1iSYDPqEPbSReZFFVTM3eN/view?usp=drivesdk
fsck didn’t find any errors, that is good. Rate limiting still kicked in, probably related to the watchdog driver failure, which is expected, I guess, if the daemon is not installed.
Let’s check the logs when the reboot fails again.
I bought the original raspberry pi 4 and it has restarted perfectly in my tests, strange that the power supply I had was the default for raspberry
What do you mean by “font”?