Bug 469181 - plymouth:nolog required to see kernel panic on ppc serial console systems
plymouth:nolog required to see kernel panic on ppc serial console systems
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-30 10:08 EDT by James Laska
Modified: 2013-09-02 02:29 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:41:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Laska 2008-10-30 10:08:21 EDT
Description of problem:

Unable to see that my system panic'd on boot when booting F10 on an IBM ppc (ibm-505-lp1) with no VGA (only serial console).

Version-Release number of selected component (if applicable):
 * plymouth-0.6.0-0.2008.10.24.2.fc10.ppc.

How reproducible:
100%


Steps to Reproduce:
1. Install F10 to IBM Power5 virtual guest
2. Boot
  
Actual results:
System appears to stop during bootup ... no messages supplied.  sysrq-h works, so the kernel appears to be alive (responding).  It hasn't gone into sysinit startup yet.

Expected results:

Booted successfully

Additional info:
 * Booting with plymouth:nolog shows a kernel panic was being hidden.
 * See boot up at http://fpaste.org/paste/8280
Comment 1 Ray Strode [halfline] 2008-11-10 15:41:33 EST
So thinking about this more, I'm not sure there's much we can do on the plymouth side.

I mean it's not like we'll get notified of the panic or get given an opportunity to show it.

I guess the kernel should undo TIOCCONS before spewing the panic message.

Moving to kernel, but this issue seems a little tricky.  I think we may end up having to WONTFIX it.
Comment 2 Dave Jones 2008-11-11 12:04:30 EST
Alan, any thoughts on the TIOCCONS undo?
Comment 3 Alan Cox 2008-11-11 12:31:44 EST
panic() calls don't go via TIOCCONS redirection

So the question is what is hiding them and why. Does plymouth use the syslog functions to hide kernel printk messages ?
Comment 4 Ray Strode [halfline] 2008-11-11 12:47:47 EST
no, just TIOCCONS
Comment 5 Ray Strode [halfline] 2008-11-11 12:51:12 EST
If that's not sufficient that would explain why bug 462172 is an issue.

I do remember doing some tests some time ago where i converted all messages to uppercase to show messages were getting redirected, and I'm pretty sure kernel messages were uppercase, too, at the time.  But, who knows, I may have botched the test.
Comment 6 Ray Strode [halfline] 2008-11-11 12:55:08 EST
jlaska, is there a separate (probably already fixed) bug for the panic issue?
Comment 7 Ray Strode [halfline] 2008-11-11 13:09:35 EST
So I just confirmed that kernel messages don't get redirected.

Using this module here:

http://cgit.freedesktop.org/~halfline/kecho

I did 

sudo sh -c 'echo "long ugly, gnarly message here" > /sys/kernel/echo/alert'

while the splash screen was going and the message overwrote the splash.

So it could be jlaska was only getting the panic if plymouth:nolog was specified and boot up was just spinning before the panic happened if plymouth:nolog wasn't specified.
Comment 8 Alan Cox 2008-11-11 13:14:53 EST
What you actually want I think is to see man 2 syslog.

Now that may break panic() and I need to check that out and fix it if so
Comment 9 James Laska 2008-11-11 13:55:26 EST
(In reply to comment #6)
> jlaska, is there a separate (probably already fixed) bug for the panic issue?

halfline: the kernel bug that was hidden is now fixed.  See bug#469079.  Oddly enough, I believe that involved selinux and tty handling (says the non-kernel guy)?
Comment 10 Ray Strode [halfline] 2008-11-11 14:04:08 EST
okay, I've commited this based on man 2 syslog:

http://cgit.freedesktop.org/plymouth/diff/?id=0254a231a6fc3610e66b1ab52455596326332d5e
Comment 11 Ray Strode [halfline] 2008-11-11 15:46:07 EST
So one possible explanation for the behavior described in the last paragraph of comment 7 is the bug that this commit fixed:

http://cgit.freedesktop.org/plymouth/commit/?id=b67ba5977e1c82476c65ef2d953b6e962fecd614

jlaska do you know if you were booting with plymouth:debug when this problem happened?
Comment 12 James Laska 2008-11-11 16:11:07 EST
Unfortunately, I can't recall and my fpaste.org seems to have been trashed.  Apologies, I won't be relying fpaste.org for boot logs in bug reports.
Comment 13 Ray Strode [halfline] 2008-11-11 16:42:33 EST
well that's as plausible an explanation as any I guess. Let's go with it.

So, to summarize

1) kernel panic wasn't getting suppressed it just wasn't happening, because a different bug was making things spin.
2) adding nolog worked around the "spin bug" but ran into the panic issue
3) both of those bugs have been fixed
4) plymouth is now suppressing kernel messages, but wasn't before
5) Alan is going to check if this new found suppression is going to stop panics from showing up.  If it turns out panics *do* show up okay then we can just close this report NOTABUG
Comment 14 Bug Zapper 2008-11-25 23:29:54 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 Bug Zapper 2009-11-18 03:42:21 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2009-12-18 01:41:46 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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