Bug 1169269

Summary: missing early boot log entries
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: systemdAssignee: systemd-maint
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: awilliam, bitlord0xff, johannbg, jsynacek, lnykryn, msekleta, samuel-rhbugs, s, systemd-maint, vpavlin, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-17 00:10:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
system.journal none

Description Chris Murphy 2014-12-01 07:59:01 UTC 
Description of problem: journalctl logs invariably start at 4 to 7 seconds, all the events from early boot are missing. No idea why.

Version-Release number of selected component (if applicable):
systemd-216-11.fc21.i686


How reproducible:

Always


Steps to Reproduce:
1. Boot
2. journalctl -b

Actual results:

# journalctl -b -o short-monotonic
-- Logs begin at Mon 2014-12-01 00:53:15 MST, end at Mon 2014-12-01 00:53:35 MST. --
[    7.493917] f21s.localdomain systemd-journal[356]: Runtime journal is using 8.0M (max allowed 100.8M, trying to leave 151.1M free of 999.
[    7.560789] f21s.localdomain systemd-journal[356]: Runtime journal is using 8.0M (max allowed 100.8M, trying to leave 151.1M free of 999.
[    4.360780] f21s.localdomain systemd-journald[97]: Received SIGTERM from PID 1 (systemd).
[    5.002247] f21s.localdomain kernel: audit: type=1404 audit(1417420392.611:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
[    5.190161] f21s.localdomain kernel: SELinux: 2048 avtab hash slots, 104136 rules.

Expected results:

I should have a bunch of early boot kernel messages well before 4.36 seconds but there are none for any boot.


Additional info:

Installation is on Btrfs but I don't see how that can be related.
Comment 1 Chris Murphy 2014-12-01 08:00:47 UTC 
Created attachment 963176 [details]
system.journal

This is a clean system.journal with a single boot exhibiting the problem; no systemd debugging enabled.
Comment 2 Chris Murphy 2014-12-01 08:08:24 UTC 
Weird, /var/log/messages contains early boot messages. I guess I just don't understand how rsyslogd is capturing them when journald isn't.

This is Fedora 21 Server, final RC1.
Comment 3 Chris Murphy 2014-12-01 10:00:40 UTC 
If I progressively downgrade systemd, it affects:
systemd-216-11.fc21.x86_64
systemd-216-10.fc21.x86_64
systemd-216-6.fc21.x86_64
systemd-216-5.fc21.x86_64

Does not affect
208-9.fc20 (f20 initial install)
208-28.fc20 (f20 updated)
216-5.fc21 (f21 beta)

Because systemd downgraded to 216-5 exhibits this problem, but f21 beta workstation live which has 216-5 doesn't exhibit the problem, I'm not really sure what's causing this.
Comment 4 Adam Williamson 2014-12-11 00:21:25 UTC 
I see this on my desktop too, FWIW. Haven't checked a clean install, yet. 'bitlord' from #fedora-qa IRC is also reporting the same thing (I think).
Comment 5 Adam Williamson 2014-12-11 00:23:57 UTC 
*** Bug 1172866 has been marked as a duplicate of this bug. ***
Comment 6 Adam Williamson 2014-12-11 00:34:40 UTC 
This affects a clean boot of the Final Workstation live, but not a clean boot of the Beta Workstation live, as cmurf found. The 'Received SIGTERM from PID 1 (systemd).' message occurs in both broken and working cases, but in the working case, all the earlier kernel messages are still present in the journal (that line occurs a long way into the journal output), while in the broken case, no earlier messages are (that line is the first one in the journal output).
Comment 7 Zbigniew Jędrzejewski-Szmek 2014-12-11 16:04:12 UTC 
Might be fixed by http://cgit.freedesktop.org/systemd/systemd/commit/?id=919699ec30.
Comment 8 Chris Murphy 2014-12-16 17:22:32 UTC 
Huh. What about bug 1174733? Seems like /var/log not actually being persistent in early boot could cause the early boot entries to just vanish once the swap happens. Meanwhile those entries were available on the socket that rsyslog is listening on.
Comment 9 Chris Murphy 2014-12-16 17:29:08 UTC 
Upgrading to dracut-038-32.git20141216.fc21 and rebuilding the initramfs appears to fix this bug.
Comment 10 Zbigniew Jędrzejewski-Szmek 2014-12-17 00:10:19 UTC 

*** This bug has been marked as a duplicate of bug 1174733 ***