Bug 1169269 - missing early boot log entries
Summary: missing early boot log entries
Keywords:
Status: CLOSED DUPLICATE of bug 1174733
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1172866 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-01 07:59 UTC by Chris Murphy
Modified: 2014-12-17 00:10 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-17 00:10:19 UTC
Type: Bug


Attachments (Terms of Use)
system.journal (49.84 KB, application/bzip2)
2014-12-01 08:00 UTC, Chris Murphy
no flags Details

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 ***


Note You need to log in before you can comment on or make changes to this bug.