Bug 439323 - serial console broken
Summary: serial console broken
Alias: None
Product: Fedora
Classification: Fedora
Component: upstart   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Casey Dahlin
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-03-28 02:06 UTC by Dave Jones
Modified: 2015-01-04 22:30 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-29 12:21:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Dave Jones 2008-03-28 02:06:57 UTC
boot with console=ttyS0 and set up a serial terminal on another machine. The
kernel starts printing boot messages, and then once the init scripts start up,
it never prints anything again, until midway through the shutdown sequence.

I'm not 100% sure it's consolekit at fault, but I have no idea of a better
component to assign this to if I'm mistaken.

Comment 1 Dave Jones 2008-03-28 18:36:27 UTC
Jeremy mentioned that this may be more likely to be upstart.  I'm inclined to
believe him.

Comment 2 Bill Nottingham 2008-03-28 18:50:46 UTC
Is a getty running on the box?

Comment 3 Dave Jones 2008-03-28 20:03:55 UTC
 2138 tty4     Ss+    0:00 /sbin/mingetty tty4
 2139 tty5     Ss+    0:00 /sbin/mingetty tty5
 2140 tty2     Ss+    0:00 /sbin/mingetty tty2
 2141 tty3     Ss+    0:00 /sbin/mingetty tty3
 2142 tty1     Ss+    0:00 /sbin/mingetty tty1
 2143 tty6     Ss+    0:00 /sbin/mingetty tty6

If I boot with just 'console=ttyS0' I see boot messages. I can then log in etc
over serial, that all works.  kernel printk's still don't appear.

If I do what I usually do... 'console=ttyS0 console=tty0' I see boot messages on
both the screen, and over serial. Until the initscripts start, and then nothing
until shutdown.

Comment 4 Bill Nottingham 2008-03-28 20:23:58 UTC
That's weird, that almost sounds like a kernel bug.

Comment 5 Dave Jones 2008-03-28 20:28:53 UTC
If I got no messages over serial during bootup/shutdown, I'd have looked there
first, but 'something' seems to be diddling 'something else' at some point,
which makes stuff stop working.

Comment 6 Dave Jones 2008-03-28 21:35:28 UTC
debugged this a little further with notting on irc.
if I replace /sbin/init with one from f8, everything works as expected, so this
is definitely an upstart problem, but why is a mystery.

Comment 7 Dave Jones 2008-03-28 23:08:40 UTC
ok, now I'm even more confused.
to test the f8 /sbin/init, I had to boot with selinux=off, because..

<notting> davej: we switched to loading the policy in the initramfs to be more
sane. unfortunately, the old init code was 'policy already loaded? wtf? I CAN'T

After testing the f8 /sbin/init, I switched things back to the regular f9
upstart /sbin/init, rebooted, and was really confused when things worked.
Then I noticed I still had selinux=off in my boot flags.

It turns out that's the key.  With selinux enabled, I don't see output. With it
disabled, I do.  But it has to be 'selinux=off', just running 'setenforce 0'
doesn't cut it.

Perhaps I was right the first time, and this is a consolekit problem.. I see
this in the audit log..

type=USER_AVC msg=audit(1206734217.347:22): user pid=1845 uid=81 auid=4294967295
subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  {
send_msg } for msgtype=method_call interface=org.freedesktop.ConsoleKit.Manager
member=OpenSessionWithParameters dest=org.freedesktop.ConsoleKit spid=1063
tpid=1950 scontext=system_u:system_r:initrc_t:s0
tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)'

Comment 8 Daniel Walsh 2008-03-29 12:21:06 UTC
I can add this, but what  script executable is talking dbus to consolekit?  It
should have a policy for it.

Well I added this allow to 

Comment 9 Bill Nottingham 2008-03-31 16:59:36 UTC
I'm confused. Something futzing with dbus to CK shouldn't affect kernel messages
to the console.

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