Bug 722331

Summary: When invoked from a start-up script (e.g. firstboot) newt ignores ENTER key
Product: Red Hat Enterprise Linux 6 Reporter: Alex Agranov <alex.agranov>
Component: plymouthAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.0CC: fedora, mlichvar, rstrode
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-06 12:40:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Alex Agranov 2011-07-14 21:56:18 UTC
Description of problem:

   When newt is invoked from a start-up script that runs prior to user login (e.g. firstboot) it ignores ENTER key. Other keys - LEFT, RIGHT, SPACE and F12 - are processed just fine. But ENTER key is ignored in all dialogs.
   The problem exists both in python bindings and in whiptail.

Version-Release number of selected component (if applicable):

    newt-0.52.11

How reproducible:

    always

Steps to Reproduce:
1. create a simple /etc/init.d startup script that uses whiptail, e.g.:

#!/bin/bash
#
# chkconfig: 3 99 95
#
case "$1" in
 start)
   /usr/bin/whiptail --msgbox "Some text" 8 50
   ;;
 stop)
   ;;
esac
exit 0

2. install new script into chkconfig
   chkconfig --add test
   chkconfig test on

3. Run this script from a regular shell and verify that ENTER key works correctly
4. Reboot the machine (at init level 3). The script will run automatically in the end of the reboot. Verify that ENTER key doesn't work.
  
Actual results:

    ENTER key doesn't work.

Expected results:

    ENTER key should work.

Additional info:

Comment 1 Miroslav Lichvar 2011-07-15 10:22:57 UTC
This looks more like a plymouth or systemd issue.

Comment 2 Alex Agranov 2011-07-16 08:44:09 UTC
You were absolutely right - adding rd_NO_PLYMOUTH to kernel parameters solved the problem.

Comment 4 RHEL Program Management 2011-07-16 09:17:58 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 5 Jan Kurik 2017-12-06 12:40:00 UTC
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/