Bug 83661 - Corrupted screen/view during kickstart install under serial console on bl10e
Corrupted screen/view during kickstart install under serial console on bl10e
Status: CLOSED DUPLICATE of bug 83024
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2003-02-06 15:47 EST by Larry Troan
Modified: 2016-04-18 05:39 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 13:51:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
hyperterm.jpg (scren capture) (114.88 KB, image/jpeg)
2003-02-13 17:44 EST, Larry Troan
no flags Details

  None (edit)
Description Larry Troan 2003-02-06 15:47:34 EST
Using a serial console during the OS installation, shows corrupted characters.

Under a RDP unattended install, we lay down a DOS partition on the server and
copy over Linux files onto the harddrive.  At the next reboot, loadlin is used
to start the install, "loadlin vmlinuz
ks=nfs: initrd=initrd.img text
console=tty0 console=ttyS0, 115200n8".  In watching the installation through the
serial console as the primary console, corrupted characters occur, for example
the rQm 232401 issue of waiting on user input for network device, appears on the
screen barely readable as "etwork..." and cannot see ethernet choices.  Since I
know this issue, just pressing return, will continue with the installation, but
the text and package installation status bar are not clear, but can tell
something is installing/progressing.  When I know that the installation is
complete, I can shut down the serial console window and open another to come to
the Linux prompt.  The serial console is good after the installation reboot. 
This issue is for during the installation.

This same command line is used with RH80 installs with no issues.  The text mode
installation appears as black/white text not blue/red color where this corrupted
view for RH81 is in blue/red.

Things I tried to correct this without success.
* Thinking this is a emulation problem, added the ",vt100" to end of
console=ttyS0,115200n8.   Searched on web for advice on how to indicate vt100
emulation via the serial console argument but didn't find anything. 
* Thinking the kernel command line text isn't working (like we found with UL),
put "text" in bl10e.ks.cfg kickstart file.
* The only diff between RH80 and RH81 call is the version of loadlin (and
obviously the vmlinuz and initrd.img that are RH81) -- rQm 232368, where I need
to use the 1.6c version versus 1.6.  Using loadlin 1.6 with RH80 hasn't been an
issue for me.  I did a RH80 install test using loadlin 1.6c and the serial
console install was just fine, no corrupted characters.

Removing the console=ttyS0,115200n8 from the command line, then the console view
through a debug adapter connected on the front of the blade, shows the install
with no issues.
Action by: Bryan.Leopard
Issue Registered

ISSUE TRACKER 15384,  opened as sev 2
Comment 1 Bill Nottingham 2003-02-06 16:15:41 EST
Do you have a UTF-8 capable serial console attached?

This seems like a dup of 83024.
Comment 2 Larry Troan 2003-02-13 17:43:43 EST
 Response:  No we have a vt100 serial console.  It is not UTF-8 capable.

We have attempted to change the term type to vt100 trying the TERM=vt100
parameter in the loadlin vmlinuz kernel command line.  This did not work. 
Either the kernel needs to default to vt100 for *serial console* when it is the
primary console OR we need a way to indicate on the kernel command line that we
need vt100 terminal type.

Attached is an example screen shot showing the corrupted characters using

File uploaded: hyperterm.jpg
Comment 3 Larry Troan 2003-02-13 17:44:42 EST
Created attachment 90072 [details]
hyperterm.jpg (scren capture)

Screen Capture
Comment 4 Matt Wilson 2003-02-18 20:52:39 EST

*** This bug has been marked as a duplicate of 83024 ***
Comment 5 Red Hat Bugzilla 2006-02-21 13:51:37 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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