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
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.
Alan, any thoughts on the TIOCCONS undo?
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 ?
no, just TIOCCONS
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.
jlaska, is there a separate (probably already fixed) bug for the panic issue?
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.
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
(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)?
okay, I've commited this based on man 2 syslog: http://cgit.freedesktop.org/plymouth/diff/?id=0254a231a6fc3610e66b1ab52455596326332d5e
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?
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.
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
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
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
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.