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%
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 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="
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.
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. ***
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
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
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
Doug, what's the status on this? Did you discuss with Prarit? Has it gone into anaconda proper at this point?
Aron, Just talked to Prarit and Jeremy. Sounds like we should be able to get this in soon. - Doug
Fixed in booty-0.79