I've stumbled across this error in the journal after spending weeks building a project on top of this OS:
So I tried a fresh install on a brand new SanDisk Extreme Pro and used another Pi 4B 1.5 (4GB). The error starts showing up immediately in every case. There have been no unclean shutdowns.
Switching debug on in cmdline.txt shows
This should be very easy to replicate so I hope that some of the devs are willing to do that and help me fix this.
This should probably be a different post but just for reference; The reason I looked into this is that I get a sporadic reboot loop that seems to be journal or time related. There's no errors in any logs when this happens but the logging stops at the moment the time should start running (just before plymouth starts). So everything is the same time in the log (kernel, .. ) and right at the point where it should start adding seconds the log stops for every boot. Plymouth still shows and systemd is doing stuff but it's no longer logged and I suspect that errors in time functions are the cause. The loop is easily broken just by switching VT or connecting via SSH, otherwise it would continue indefinitely it seems.
I'm just adding this now in case anyone says the error is harmless and just to let it be.
The reboot issue is surely something in my setup because it wasn't there the first weeks I worked on this but I do believe it might be related to a time issue that is baked in at this point.
This is the debug log:
Any help is greatly appreciated!
Thank you.
After some investigation I found that this error has been shown every boot from the very first reboot after installing with the Pi Imager.system.journal corrupted or uncleanly shut down, renaming and replacing
So I tried a fresh install on a brand new SanDisk Extreme Pro and used another Pi 4B 1.5 (4GB). The error starts showing up immediately in every case. There have been no unclean shutdowns.
Switching debug on in cmdline.txt shows
system.journal is from the future, refusing to append new data to it
- I've also tried rm /var/log/journal/* but the issue is always there (as expected since it's also there on a clean install).
- The only thing that stops it is to turn persistent storage off but I don't want to do that.
- I've also installed the Bullseye lite 64 version with the imager and the error is not there
- I've tried with and without personal settings in the Imager and that makes no difference
- ntp, fake-hw-clock, etc are all running as normal and I can't find other errors related to this
- I've used google, chatgpt 4 and Bing co-pilot but there are no reports or fixes to be found anywhere.
Googling the error itself returns thousands of hits but most are about other issues or offer no solution. None are specifically about this exact OS that I can find and chatgpt has no clue.
This should be very easy to replicate so I hope that some of the devs are willing to do that and help me fix this.
This should probably be a different post but just for reference; The reason I looked into this is that I get a sporadic reboot loop that seems to be journal or time related. There's no errors in any logs when this happens but the logging stops at the moment the time should start running (just before plymouth starts). So everything is the same time in the log (kernel, .. ) and right at the point where it should start adding seconds the log stops for every boot. Plymouth still shows and systemd is doing stuff but it's no longer logged and I suspect that errors in time functions are the cause. The loop is easily broken just by switching VT or connecting via SSH, otherwise it would continue indefinitely it seems.
I'm just adding this now in case anyone says the error is harmless and just to let it be.
The reboot issue is surely something in my setup because it wasn't there the first weeks I worked on this but I do believe it might be related to a time issue that is baked in at this point.
This is the debug log:
Code:
Feb 28 16:26:11 tzvpi1 systemd-journald[304]: Time spent on flushing to /var/log/journal/48d069bf1c2340a18395b322c7d9419f is 52.788ms for 860 entries.Feb 28 16:26:11 tzvpi1 systemd-journald[304]: System Journal (/var/log/journal/48d069bf1c2340a18395b322c7d9419f) is 56.0M, max 2.8G, 2.8G free.Feb 28 16:26:11 tzvpi1 systemd-journald[304]: varlink: New incoming connection.Feb 28 16:26:11 tzvpi1 systemd-journald[304]: varlink-18: Setting state idle-serverFeb 28 16:26:11 tzvpi1 systemd-journald[304]: varlink-18: New incoming message: {"method":"io.systemd.Journal.FlushToVar","parameters":{}}Feb 28 16:26:11 tzvpi1 systemd-journald[304]: varlink-18: Changing state idle-server → processing-methodFeb 28 16:26:11 tzvpi1 systemd-journald[304]: Received client request to flush runtime journal.Feb 28 16:26:11 tzvpi1 systemd-journald[304]: Journal file /var/log/journal/48d069bf1c2340a18395b322c7d9419f/system.journal is from the future, refusing to append new data to it th>Feb 28 16:26:11 tzvpi1 systemd-journald[304]: File /var/log/journal/48d069bf1c2340a18395b322c7d9419f/system.journal corrupted or uncleanly shut down, renaming and replacing.Feb 28 16:26:11 tzvpi1 systemd-journald[304]: Fixed min_use=16.0M max_use=2.8G max_size=128.0M min_size=512.0K keep_free=1.4G n_max_files=100Feb 28 16:26:11 tzvpi1 systemd-journald[304]: Reserving 333 entries in field hash table.Feb 28 16:26:11 tzvpi1 systemd-journald[304]: Reserving 233016 entries in data hash table.Feb 28 16:26:11 tzvpi1 systemd-journald[304]: Flushing to /var/log/journal/48d069bf1c2340a18395b322c7d9419f...Feb 28 16:26:11 tzvpi1 systemd-journald[304]: Considering root directory '/run/log/journal'.Feb 28 16:26:11 tzvpi1 systemd-journald[304]: Root directory /run/log/journal added.Feb 28 16:26:11 tzvpi1 systemd-journald[304]: Considering directory '/run/log/journal/48d069bf1c2340a18395b322c7d9419f'.Feb 28 16:26:11 tzvpi1 systemd-journald[304]: Directory /run/log/journal/48d069bf1c2340a18395b322c7d9419f added.Feb 28 16:26:11 tzvpi1 systemd-tmpfiles[324]: Entry "/dev/kvm" matches include prefix "/dev".Thank you.
Statistics: Posted by mkt1 — Thu Feb 29, 2024 11:24 am