On Fri, Dec 04, 2015 at 08:02:28AM -0500, mark wrote:
> No, *you* don't understand what we're saying: pre-systemd, if the o/p saw
> that one stmt before the panic, they could look at what the system was doing
> *sequentially*, and so have an idea what it was failing on. With systemd's
> parallelism, we have no clue, other than what it's done, and no idea what's
> happening that's failing.
Sadly, in this case, no init system would help with the fact that the
kernel panic is more lines than are shown on a VGA screen. So, no
help there.
Also, while the systemd init system is loaded very early, judging from
the call trace, it happened before or during the pivot from the initrd
to the root filesystem. There's little that can be done to address
this kind of panic, no matter what init system you're running, you
basically just need to have a logging console somewhere.
However, if you have a journald writing into memory, its very possible
that if it doesn't panic enough to kill the journal you might have a
copy of what *was* running. It's not the case here, but this is
something that you get from having a journal -- you have real logs of
what was happening, what processes were running and what emitted the
error. With Upstart and SysVinit, you were stuck watching the output
on the console and hoping whatever generated the error was good enough
to say what program it was. Sure, you could make guesses based on the
serial startup (although Upstart also supported parallel startup,
although the CentOS init system rarely used it).
For what its worth, you could always crank up systemd.log_level=debug
on boot and you'll see what's going on when it panics.
--
Jonathan Billings <billings@xxxxxxxxxx>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
