Bug 975063 - Anaconda pre script stdin file descriptor set to /tmp/ks-script-xxxxxx.log instead of /dev/tty1
Summary: Anaconda pre script stdin file descriptor set to /tmp/ks-script-xxxxxx.log in...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 19
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Brian Lane
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-17 14:30 UTC by Ian Neal
Modified: 2014-10-07 23:33 UTC (History)
8 users (show)

Fixed In Version: anaconda-19.31.1-1
Clone Of:
Environment:
Last Closed: 2014-10-07 23:33:11 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Ian Neal 2013-06-17 14:30:51 UTC
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.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 16:07:31 UTC
Fixed in commit a8046ae on master only.


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