On 2015-06-18 17:46, Rick Stevens wrote: > Maybe we can catch log entries before it completely dies. Bring the > system up in single user mode, then edit /etc/systemd/journald.conf. > Find the line: > > #ForwardToSyslog=no > > Change it to: > > ForwardToSyslog=yes > > and save the file. This should cause journald to forward log entries > to the old system logger. Reboot and force the crash. Hopefully, the > messages will get logged to /var/log/messages before you lose the log > daemon. Haha... that's completely unhelpful as I *have* no /var/log/messages. Not that is in any way useful: Jun 19 14:30:51 gryphon rsyslogd-2027: imjournal: fscanf on state file `/var/lib/rsyslog/imjournal.state' failed [v8.8.0 try http://www.rsyslog.com/e/2027 ] That is THE ENTIRE FILE. (Well, that exact message a few times with various dates, plus a bunch of NUL's.) I'm starting to wonder about the disk(s)... though the OBD's¹ pass, which doesn't give a lot of ammunition to take to Dell's support. Anything else I can run to further diagnose, or better yet, confirm if there is a HW problem? (¹ Not useless-for-this-purpose POST, but the Dell OBD's that take several minutes to run just the basic tests.) Oh, and... apparently some update (or just "additional use") made things worse; I can no longer VTY switch *at all* after a normal boot. (I'd be inclined to believe that the SSD went read-only or something, except I *can* apparently install updates - dnf succeeds, grub shows a new kernel - and /var is on the magnetic disk.) The only other message I can access is: snd_hda_intel 0000:01:00.1 CORB reset timeout#2, CORBRP = 65535 Anything else is going into the bitbucket. The above *does* seem to happen right before the system dies, but it seems innocuous? BTW, this is *all without running X* (AFAIK)... the system freezes trying to go from single-user mode to 'systemctl start graphical.target' without ever seeing kdm start. (I do get kdm when booting normally; in that case, it's hitting enter after typing my password when the system freezes.) ...although in that case, "freezes" means the original TTY is no longer usable, but I can VTY switch (alt-f2) to another, "log in", and get the "last login..." message, but no further. Same deal with ssh; I can get as far as the "last login..." message but never get a shell. This last time I also arranged to have a 'dmesg -w' running at the time; no output of any kind from that on login attempts. (On a different note, Fedora is also unable to reboot or power off this machine, although that's been par for the course with Dell Precision M's.) -- Matthew -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
