Thank you for your replies. I found the advice to post in github after posting here so I did that as well.
I've been investigating further and added the results there. As I understand it, the forum is the place where users help each other and github where the devs decide if it's a bug or not. I hope that's ok.
For now I'll keep both threads active and post this weird finding here too. Shown below is a possible reason for the 'journal is from the future' message. Jan 26 is not the epoch and it's not the start of the journal. It's also not the time that I installed this OS, that was later so I have no idea where this static date comes from.
$ journalctl | grep 'Executing: /sbin/fake-hwclock'
Jan 26 22:48:37 tzvpi1 (-hwclock)[287]: fake-hwclock.service: Executing: /sbin/fake-hwclock load
Feb 28 16:54:09 tzvpi1 (-hwclock)[1132]: fake-hwclock.service: Executing: /sbin/fake-hwclock save
Jan 26 22:48:37 tzvpi1 (-hwclock)[287]: fake-hwclock.service: Executing: /sbin/fake-hwclock load
Jan 26 22:48:37 tzvpi1 (-hwclock)[285]: fake-hwclock.service: Executing: /sbin/fake-hwclock load
Feb 28 17:20:21 tzvpi1 (-hwclock)[1089]: fake-hwclock.service: Executing: /sbin/fake-hwclock save
Jan 26 22:48:37 tzvpi1 (-hwclock)[285]: fake-hwclock.service: Executing: /sbin/fake-hwclock load
Feb 28 21:00:30 tzvpi1 (-hwclock)[1411]: fake-hwclock.service: Executing: /sbin/fake-hwclock save
Jan 26 22:48:37 tzvpi1 (-hwclock)[285]: fake-hwclock.service: Executing: /sbin/fake-hwclock load
Feb 29 14:04:29 tzvpi1 (-hwclock)[1270]: fake-hwclock.service: Executing: /sbin/fake-hwclock save
Jan 26 22:48:37 tzvpi1 (-hwclock)[285]: fake-hwclock.service: Executing: /sbin/fake-hwclock load
Using journalctl without options does not show these entries. The journal starts on Feb 28. Grep
For a more detailed log extract please see the https://github.com/raspberrypi/bookworm ... issues/221 thread
The dependencies are all set to orchestrate it well and it's running really well but I'm sure there can be some bug causing the reboot loop once in a while. I just wish that I could get it to log what is happening then...
I've been investigating further and added the results there. As I understand it, the forum is the place where users help each other and github where the devs decide if it's a bug or not. I hope that's ok.
For now I'll keep both threads active and post this weird finding here too. Shown below is a possible reason for the 'journal is from the future' message. Jan 26 is not the epoch and it's not the start of the journal. It's also not the time that I installed this OS, that was later so I have no idea where this static date comes from.
$ journalctl | grep 'Executing: /sbin/fake-hwclock'
Jan 26 22:48:37 tzvpi1 (-hwclock)[287]: fake-hwclock.service: Executing: /sbin/fake-hwclock load
Feb 28 16:54:09 tzvpi1 (-hwclock)[1132]: fake-hwclock.service: Executing: /sbin/fake-hwclock save
Jan 26 22:48:37 tzvpi1 (-hwclock)[287]: fake-hwclock.service: Executing: /sbin/fake-hwclock load
Jan 26 22:48:37 tzvpi1 (-hwclock)[285]: fake-hwclock.service: Executing: /sbin/fake-hwclock load
Feb 28 17:20:21 tzvpi1 (-hwclock)[1089]: fake-hwclock.service: Executing: /sbin/fake-hwclock save
Jan 26 22:48:37 tzvpi1 (-hwclock)[285]: fake-hwclock.service: Executing: /sbin/fake-hwclock load
Feb 28 21:00:30 tzvpi1 (-hwclock)[1411]: fake-hwclock.service: Executing: /sbin/fake-hwclock save
Jan 26 22:48:37 tzvpi1 (-hwclock)[285]: fake-hwclock.service: Executing: /sbin/fake-hwclock load
Feb 29 14:04:29 tzvpi1 (-hwclock)[1270]: fake-hwclock.service: Executing: /sbin/fake-hwclock save
Jan 26 22:48:37 tzvpi1 (-hwclock)[285]: fake-hwclock.service: Executing: /sbin/fake-hwclock load
Using journalctl without options does not show these entries. The journal starts on Feb 28. Grep
For a more detailed log extract please see the https://github.com/raspberrypi/bookworm ... issues/221 thread
I guess it's a graphical component crashing and the time issue might only be responsible for the absence of any logs to see what is going on in the loop. I should make this another thread but wanted to get the journal mystery solved first. I'm using Xorg, Openbox and Thorium all as services. This is a view only kiosk with a single user and priority on speed so I'm not using a display manager, startx or xinit.I highly doubt this has anything to do with your issue. Is the reboot loop really rebooting, or is just some graphical component crashing and restarting?
In a multi-user system, rebooting is a privileged operation, and few programs have any code to do it. To the best of my knowledge, there is nothing that would attempt a reboot because of an error, as a last resort, or anything like that. Even in the event of a kernel panic, the default behavior is to halt, not reboot.
The dependencies are all set to orchestrate it well and it's running really well but I'm sure there can be some bug causing the reboot loop once in a while. I just wish that I could get it to log what is happening then...
Statistics: Posted by mkt1 — Thu Feb 29, 2024 2:35 pm