Bug 975063 - Anaconda pre script stdin file descriptor set to /tmp/ks-script-xxxxxx.log instead of /dev/tty1
Anaconda pre script stdin file descriptor set to /tmp/ks-script-xxxxxx.log in...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
19
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-17 10:30 EDT by Ian Neal
Modified: 2014-10-07 19:33 EDT (History)
8 users (show)

See Also:
Fixed In Version: anaconda-19.31.1-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-07 19:33:11 EDT
Type: Bug
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 Ian Neal 2013-06-17 10:30:51 EDT
Description of problem:
When running Anaconda from the Fedora19-netinstall disk with a kickstart file selected, our pre script runs with a bad file descriptor for stdin; /tmp/ks-script-xxxxxx.log (changes each time).

How reproducible:
This happens each and every time we run our kickstart with F19-Beta

Steps to Reproduce:
1. Using F19-Beta netinstall disk, try to install with a kickstart file by adding ks=(kickstart cfg here) to the boot line
2. This fails as soon as step-1 of Anaconda starts, with the pre script section.

Actual results:
Enter username: /tmp/ks-script-VsOCR, line 14: read: read error: 0: bad file descriptor

Expected results:
Enter username: (username)

Additional info:
I realize the easy way to fix this is redirecting stdin for read to the terminal, and that's our solution at the moment, but this is a strange bug.

The pre script in our kickstart (the error rears its ugly head on the line `read -ep "Username: " USERNAME`:


%pre --interpreter /bin/bash

source /etc/bashrc

chvt 1
exec &>>/dev/tty1

# Checks the file exists and has some data in it
looks_good() {
        [ -f "$1" ] && [ $(wc -c <"$1") -gt 50 ]
}

forge_init() {
        echo "You must authenticate as an employee in order to install this host's keytab file."
        read -ep "Username: " USERNAME

        # Work whether or not we have kinit on this boot disk
        if ! which kinit &>/dev/null
        then
                # Connecting to a host will give us a kerberos ticket
                # that we can use to connect to rsync@update.
                # Alternatively we could do that locally with kinit,
                # but that requires building that into the boot image.
                ssh -qnKl "$USERNAME" -o StrictHostKeyChecking=no machine1 "ssh -qnK -o StrictHostKeyChecking=no rsync@machine2 cat 'keytabs/$(hostname)'" >/tmp/krb5.keytab
                return $?
        else
                # Hey we have kinit

                export KRB5CCNAME=/tmp/keytab

                # Get a temporary kerberos ticket as this user
                kinit -FP -r1h "$USERNAME"
                if ! looks_good "$KRB5CCNAME"
                then
                        return 1
                fi

                # Use that ticket to download this host's keytab
                scp -o GSSAPIAuthentication=yes -o StrictHostKeyChecking=no "rsync@update.nmt.edu:~/keytabs/$(hostname)" /tmp/krb5.keytab
                return $?
        fi
        # Shouldn't get to this point
        return 10
}


until forge_init
do
        echo "Failed, please try again."
        sleep 1
done

# Check that the keytab file exists and has content
if ! looks_good /tmp/krb5.keytab
then
        echo "Keytab file not retrieved correctly. Halting."
        halt
fi

%end
Comment 1 Brian Lane 2013-06-24 12:07:31 EDT
Fixed in commit a8046ae on master only.

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