Bug 114174

Sorry, Tim -- already known.

*** This bug has been marked as a duplicate of 112776 ***

Aaaaarg!  Wrong bug closed.  Bad Glen!  Bad dog!

I remember this working for me... did this just break in U3 (since I
definitely didn't change any code in this area)?

I'm (finally) getting around to trying this with AS2.1 Update 2...
just so I know if I'm doing this correctly, I start up the kickstart
with console=ttyS0 on the command line (e.g., there's nothing in the
kickstart script required to make this happen) and it's just supposed
to work, right?

Same behavior with 2.1-update-2 -- I perform an everything install,
edit the kickstart config, reboot with "linux ks=nfs:IP:path
console=ttyS0".
Kickstart does indeed run but there's no console=ttyS0 in "elilo.conf".

Same behavior with stock 2.1 Advanced Server.

Glen, any special box to recreate this? 

SEG, Summer has an IPF workstation (zx2000?) in her office that you 
may be able to use. 

ISSUE TRACKER 35444 OPENED AS SEV 1

HP-IPF asks this me fixed for U4. Nominating for U5 MUSTFIX in case 
it doesn't make U2.

I can recreate this problem reliably on a Longs Peak (rx2600).  It
shouldn't take anything special.

Glen, I just ran an install on the aforementioned zx2000 with AS2.1 U3
and the line made it to elilo.conf. Can you please try with u3. 

Hi, James - long time no hear/see!

Actually, I mentioned in the initial problem report that I get this
behavior EVERY time I do a kickstart install on IPF.  And later on in
the defect report, I confirmed it appears it's always been that way
for RHEL 2.1, RHEL 2.1 update 2, and RHEL 2.1 update 3.

I get the serial console lines when I do a plain install.  This defect
report is specifically for a "kickstart" install -- and I select the
"Everything" package set, in case it really matters.

Please tell Tish I said "how-dee" next time you remember it, OK?

Ok, going to attempt a kickstart version today to replicate. And Ill
make sure to tell her:)

So I ran the kickstart and it propogated the line to elilo.conf. I am
attaching the ks.cfg I used with names changed to protect the
innocent. Any chance you could throw yours up here so I can give it a
hack. Also the one possible difference I noted was that I set the
speed for the console at the command line when I ran it: 

linux text console=ttyS0,9600n8 ks=nfs:nfsserver.com:/kickstart/ks.cfg

Created attachment 98428 [details]
kickstart file

This file coupled with the linux:
linux text console=ttyS0,9600n8 ks=nfs:nfsserver.com/kickstart/anaconda-ks.cfg 

seemed to propogate changes where neccessary to ensure the console line works
after install.

The hardware-independent portions of the kickstart script attached in
comment #15 isn't that different from what I've got.  But I _am_ using
the kickstart script from what anaconda drops, adding only the "nfs
--server" line, adding "text", and adding "reboot" so that I can
completely automate the kickstart install.

Differences I see in what anaconda makes and the above ks script:

Johns: bootloader
Mine: bootloader --append hda=ide-scsi console=ttyS0
Mine: text
Mine: reboot

Again, the ks script I'm using was generated by anaconda and when I
use it, I get no setup for "console=ttyS0".

So, is it the "text" path, does "reboot" cause the setup to not take
place, or does the different "bootloader" clause cause the problem?

Johns?  Sorry, I mean James' ... and this is entirely reproducible,
using the kickstart script created by anaconda.

I can still reproduce this AT WILL on both RHEL3 update 2 and RHAS 2.1
update 4.  Is this going to be fixed?  Enterprise customers need to
have the ability to install systems via kickstart and know that if
it's invoked over a serial console that the system configuration will
be right at post-install time.

Yeah, It appears the bug(s) are related to the kickstart file and also
the gui kickstart configurator. The Gui tool adds options which dont
work, and the kickstart file generated during install appears to do
strange things. It appears you can workaround this by writing your own
like the one I attached above, but the other two parts appear to be bugs.

Note that the only way to get all of the serial console stuff always
set up right (and the way that I've always instructed people to do it)
is to do the install as a serial install passing all of the console
options during the install.   You can add some quoting and it will do
some of the things, but it's not guaranteed to do everything (only the
kernel argument side)

But... I *am* running the kickstart over serial console. :)
I suspect the problem has something to do with the bootloader line.  I
looked at the docs but I can't really tell what's going on.  I'm using
the kickstart script that anaconda generates and all I'm adding are
the lines "text", "reboot", and some sort of network/hard-drive
install reference so kickstart knows where to look for the distro (and
the latter lines work because the package selection/installation stuff
is fine) -- it's just that when run over a serial console, the
kickstart script generated by anaconda doesn't configure console=ttyS0
properly.

Is this enough for you to hunt down and kill this?  This problem is
seen on both RHEL 2.1 and RHEL 3.

If you quote the bootloader arguments as

bootloader --append="hda=ide-scsi console=ttyS0"

does it work?  Looks like it should

Yes, it works when I force it myself.  It would be EvenCooler(tm) if
anaconda could/would do that for the customer.

Okay, added bits so that we quote appends in CVS which should take
care of this.

Validated the changes work correctly in RHEL2.1 update 6 beta. Thanks!