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