Bug 196709 - anaconda improperly puts console=ttyS0 in elilo.conf
anaconda improperly puts console=ttyS0 in elilo.conf
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
ia64 Linux
high Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
: Regression
: 196976 (view as bug list)
Depends On:
Blocks: fedora-ia64 196976
  Show dependency treegraph
 
Reported: 2006-06-26 12:21 EDT by Doug Chapman
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-19 11:45:42 EDT
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 Doug Chapman 2006-06-26 12:21:52 EDT
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
be generated.



Version-Release number of selected component (if applicable):
rawhide-20060626
anaconda-11.1.0.48-1


How reproducible:
100%
Comment 1 Jeremy Katz 2006-06-27 12:58:46 EDT
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?
Comment 2 Doug Chapman 2006-06-27 13:49:46 EDT
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.

Comment 3 Jeremy Katz 2006-06-27 14:15:26 EDT
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
appropriately.

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
console="
Comment 4 Doug Chapman 2006-06-27 14:39:33 EDT
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:

Documentation/ia64/serial.txt

This describes why the console numbering changed and how it determines what
console tty port to use.

Comment 5 Jeremy Katz 2006-06-27 14:50:25 EDT
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.  
Comment 6 Doug Chapman 2006-06-27 18:00:57 EDT
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.

Comment 7 Jeremy Katz 2006-06-27 19:33:05 EDT
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.
Comment 8 Jeremy Katz 2006-06-27 19:36:08 EDT
*** Bug 196976 has been marked as a duplicate of this bug. ***
Comment 9 Doug Chapman 2006-06-28 09:48:54 EDT
Jeremy,

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.

thanks,

- Doug
Comment 10 Doug Chapman 2006-06-28 14:41:42 EDT
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 ?
    import dispatch
  File "/usr/lib/anaconda/dispatch.py", line 31, in ?
    from bootloader import writeBootloader, bootloaderSetupChoices
  File "/usr/lib/anaconda/bootloader.py", line 31, in ?
    import booty
  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

Comment 11 Doug Chapman 2006-06-28 17:00:07 EDT
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
Comment 12 Aron Griffis 2006-07-11 10:58:43 EDT
Doug, what's the status on this?  Did you discuss with Prarit?  Has it gone into
anaconda proper at this point?
Comment 13 Doug Chapman 2006-07-11 11:27:00 EDT
Aron,

Just talked to Prarit and Jeremy.  Sounds like we should be able to get this in
soon.

- Doug
Comment 14 Jeremy Katz 2006-07-19 11:45:42 EDT
Fixed in booty-0.79

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