Red Hat Bugzilla – Bug 196709
anaconda improperly puts console=ttyS0 in elilo.conf
Last modified: 2007-11-30 17:11:36 EST
Description of problem:
When using serial console install (text mode or VNC) of recent rawhide builds it
appears that "console=ttyS0" is being placed into the elilo.conf even though
anaconda was never told any console= info. On recent kernels (i.e. 2.6.16 and
later) the HP Integrity console is typically NOT ttyS0 as it was back in the
RHEL4 days. These kernels are able to automatically determine the proper
console device so unless the system is set up with a non standard configuration
console= should not be specified at all.
So, the proper behavior would be:
If the user specified a console= argument at install bootup time that argument
should be added to the append line in the generated elilo.conf.
If the user did not specify a console= argument then no console argument should
Version-Release number of selected component (if applicable):
This then breaks other cases. Inconsistent kernel behavior is *BAD*. We had to
add the support for doing this previously because of weird ia64 behavior.
What _is_ the console device on these systems now?
What was the weird ia64 behavior? Would that have been the other BZ I filed
(191087)? If so then the 2 are not contradictory. That BZ just says that if
the user DID specify a console= argument then that info should be carried
forward into the newly created elilo.conf on the installed system.
The console on these systems varies. The kernel determines what device the
console is on during bootup. You will see a messages like this during boot:
Adding console on ttyS1 at MMIO 0xf8050000 (options '9600n8')
I imagine there is some way to determine what the console is via /proc. I will
check with our serial console expert in HP to see how anaconda can easily
determine what the console is.
No, this is from way back in 2002 when we did AS/AW 2.1 for ia64. And it also
ties in with things done for RHEL4 so that we would appropriately decide that
you are on a serial console and set the behavior throughout the install
If there's a good way to determine what the serial console actually being used
is, I'm more than glad to adjust the code to take advantage of that. But
parsing dmesg just isn't the way (it's not reliable enough given that it could
be out of the buffer by the time we need it). As it stands, we fall back to
ttyS0 purely out of "nothing better to autopick if you're serial console but not
I agree we don't want to parse dmesg output, was just using that to demonstrate
how the kernel automagically determines the console device.
It really seems the way to go would be to just see what the user passed in
during the inital boot by looking at /proc/cmdline. If a console= argument was
needed then the user would have had to supply it here and that info should be
used by anaconda. If the user did not supply a console= argument here then it
is either not needed or if it is needed the user won't see any console output so
they won't be able to install and will say "oops I forgot my console= argument".
Keep in mind a LOT has changed since RHEL 2.1 and quite a bit has changed since
RHEL4 in this area (starting with 2.6.10). This is documented in the kernel
source tree at:
This describes why the console numbering changed and how it determines what
console tty port to use.
If the user passes something, we use it. It's just when they don't that we have
to be tricky. And while ia64 may have some new magic here, I guarantee that's
not the case on all arches. I guess we could make this not happen just on ia64,
but I'd want confirmation that it's not going to break non-HP ia64 platforms.
I understand the concern about potentially breaking non HP ia64 platforms but
with the current setup we are breaking 95% of HP ia64 platforms. I see now that
we get this behavior on the RHEL5 alpha now as well.
If you verify that changing it doesn't break the HP platforms, I'm fine with
making the change on an ia64-only basis -- updates.img that can be used to test
is at http://people.redhat.com/~katzj/updates-ia64-serial.img.
But I'm not just going to go and irresponsibly break all other ia64 systems.
*** Bug 196976 has been marked as a duplicate of this bug. ***
Sorry for the RHEL5 dup, I was asked to file one there for RHEL5 tracking. I
don't mean to create busy work.
Not sure what to do with the updates-ia64-serial.img file. What is this? I
will test this ASAP once I know what to do with this.
OK, clumens told me about the updates= boot arg so I could test this. It
appears to have a typo in it:
Traceback (most recent call last):
File "/usr/bin/anaconda", line 604, in ?
File "/usr/lib/anaconda/dispatch.py", line 31, in ?
from bootloader import writeBootloader, bootloaderSetupChoices
File "/usr/lib/anaconda/bootloader.py", line 31, in ?
File "/usr/lib/booty/booty.py", line 28, in ?
from bootloaderInfo import *
File "/tmp/updates/bootloaderInfo.py", line 509
if device is None and rhpl.getArch() != "ia64"::
SyntaxError: invalid syntax
I have now tested this update. (thanks Chris for your help getting this going)
I did 2 installs, one where I did not specify a console= argument and let the
kernel determine this on it's own and another where I explicitly set the
console= (which is ttyS1 in this case) and both cases work perfectly.
I will discuss this with Prarit tomorrow who should be able to raise any
potential concerns regarding SGI ia64 hardware but I have a very high level of
confidence that this will not case any problems on non HP hardware.
I really appreciate the attention paid to this issue, thanks.
Doug, what's the status on this? Did you discuss with Prarit? Has it gone into
anaconda proper at this point?
Just talked to Prarit and Jeremy. Sounds like we should be able to get this in
Fixed in booty-0.79