Description of problem: at the end of the boot sequence, splashes displays: .............................................. 119.444400] systemd-journald[953]: Failed to write entry (23 items, 514 bytes), ignoring: Bad address [ 119.486266] systemd-journald[953]: Failed to write entry (23 items, 514 bytes), ignoring: Bad address [ 120.464464] systemd-journald[953]: Failed to write entry (20 items, 934 bytes), ignoring: Bad address [ 120.464583] systemd-journald[953]: Failed to write entry (20 items, 983 bytes), ignoring: Bad address [ 133.315125] systemd-journald[953]: Failed to write entry (21 items, 534 bytes), ignoring: Bad address [ 133.315252] systemd-journald[953]: Failed to write entry (21 items, 489 bytes), ignoring: Bad address [ 133.316398] systemd-journald[953]: Failed to write entry (21 items, 528 bytes), ignoring: Bad address [ 142.622324] systemd-journald[953]: Failed to write entry (21 items, 509 bytes), ignoring: Bad address ............................................... the totality of the message can be found in dmesg Version-Release number of selected component (if applicable): How reproducible: I can't say Steps to Reproduce:??? 1. 2. 3. Reproducible: Steps to Reproduce:
Created attachment 6848 [details] this is the result of the dmesg command
Created attachment 6849 [details] this is the result of the dmesg command
ignore attachment 6848 [details], and consider only attachment 6849 [details]
CC: (none) => zen25000 Attachment 6848 is obsolete: 0 => 1
Hi Igor, Sorry for the very late reply. We are short on active BugSquad members. Is this bug still valid in fully updated Mageia 5 or cauldron? If so: * Does this occur in an installed Mageia, or using a Live iso in Live mode, or...? * How much free space is left on the partition where /var/log/journal/ resides? * Please attach verify.txt that is the result of (as root): journalctl --verify > verify.txt * If (as root) "running journalctl -ab" works, then please attach journal.txt that is the result of: journalctl -ab > journal.txt (It is unclear to me why the Release component was chosen, changing it to RPM Packages)
Keywords: (none) => NEEDINFOCC: sysadmin-bugs => marja11Component: Release (media or process) => RPM PackagesSource RPM: (none) => systemd
Created attachment 8611 [details] return of "journalctl -ab > journal.txt"
Created attachment 8612 [details] return of "journalctl --verify"
Hi Marja, I usually incrementally backup my system with the "dump" command; sometimes, for some reason, I am led to remove the totality of my system; in this case I restore it with the "restore" command; after restoring, at the 6 or 7 following boots, this phenomenon occurs, and vanishes after. the command "journalctl -ab > journal.txt" did work, but "journalctl --verify > verify.txt" didn't; for the latter I have just run "journalctl --verify" in a terminal and pasted it.
(In reply to igor ivanov from comment #7) > Hi Marja, > I usually incrementally backup my system with the "dump" command; sometimes, > for some reason, I am led to remove the totality of my system; in this case > I restore it with the "restore" command; after restoring, at the 6 or 7 > following boots, this phenomenon occurs, and vanishes after. I can't find it now, but I'm pretty sure I've seen another (non-Mageia) report that this happens every time after restoring the system from a backup. Anyway, assigning to basesystem maintainer group and CC'ing the systemd maintainer.
Keywords: NEEDINFO => (none)CC: (none) => mageiaAssignee: bugsquad => basesystem
(In reply to Marja van Waes from comment #8) > I can't find it now, but I'm pretty sure I've seen another (non-Mageia) > report that this happens every time after restoring the system from a backup. Well, there are a lot - basically you need to restart systemd-journald after you restore from backup. I believe there's nothing that we can fix as downstream, and how would systemd magically know that it has been restored from backup ? See https://bugzilla.redhat.com/show_bug.cgi?id=1069828 https://access.redhat.com/discussions/2100681 @Igor: As we have no way to reproduce this, I'm going to close this one. If it still happens on every boot, or if it happens with a fresh installation then please feel free to reopen. But as journalctl --verify shows nearly every journal file as corrupted I don't believe that's the case. For comparison my journald logs go back to 2015 and I have not one such "Failed to write entry" errors in the log. On a related note, you should really take a look at the SMART data for both of your harddisks, there are some offline and some pending offline sectors which may as well influence the health of the filesystem and might as well play into this bug ...
Resolution: (none) => WORKSFORMEStatus: NEW => RESOLVEDCC: (none) => doktor5000