linux psp74 kickstart install never returns control in %post

[Noal Miles]

In the %post section of my kickstart file I call the psp74 install with the --inputfile option. The psp does the install successfully but nothing following the psp in the %post section runs. If I comment out the psp install I everything runs fine. Looking at the %post section below the perl script and the echo never occur when the psp is run.....

Any thoughts?
Thanks,
Noal

Here is what my %post looks like..

#Redirect IO to 3rd tty
exec < /dev/tty3 > /dev/tty3
#Change to 3rd tty
chvt 3
echo -e "STARTING post install \r" | tee /root/ks-out.log
mkdir /mnt/psp | tee /root/ks-out.log
mount -t nfs -o nolock 172.17.20.28:/s_psp74 /mnt/psp | tee /root/ks-out.log
cp /mnt/psp/compaq/csp/linux/psp74.cfg /tmp | tee /root/ks-out.log
/mnt/psp/compaq/csp/linux/install740.sh --nui --inputfile /tmp/psp74.cfg
/usr/bin/perl /mnt/psp/compaq/csp/linux/io.pl
umount /mnt/psp | tee /root/ks-out.log
echo -e "DONE post install \r" | tee /root/ks-out.log
chvt 7

[Gopi Sekar]

Few notes:

PSP install requires the running kernel (not the kernel which is used to do the installation). So it would be better to start the installation of PSP after the OS is installed and server is rebooted in to production kernel. (use /etc/rc.d/rc.local file to do the PSP installation)

We call the psp installer this way and it works fine for us:
install740.sh --silent --inputfile psp.dat 1>>log_file 2>>log_file

I would suggest to add two -- for inputfile switch.

Hope this helps,
GOpi

[Noal Miles]

Why do you say the psp requires the running kernel? We are using the smart start scripting toolkit which basically ends up calling kickstart from a kernel runnning on a fat partition on local disk. The kernel there is the same version as what ks will install and ks runs in a chroot'd environment to what will be the running kernel. It has been my experience with this method I have to use the kernel from the /images/diskboot.img of the install media (i.e. the same kernel). As an updated I have worked a bit with HP support. The problem *seems* to be that some psp process(es) never return from tty1. Commenting out the last portion of the install740.sh script (where it hups some pids) seems to make the problem go away while still completing successfully. Hopefully this can be better explained....

[Jess Long · Accepted solution]

Noal:

Kudos to you as you have found a bug in the script. The code beginning at line 1929, should only be executed if the install script was called from the autorun of a CD. A fix has been implemented for the next PSP release. However, if you need to fix your copy before that release, you can replace the code from line 1929 to eof with the following:

# If we were called from a CD using autorun and a reboot is scheduled, we need to eject the CD.
if [ \( -n "$AUTO" -a -n "$CDDEV" \) -a $RC -eq 16 ]
then
[ -x /usr/bin/eject ] && EJECT=/usr/bin/eject
[ -x /bin/eject ] && EJECT=/bin/eject
cat >/tmp/eject.sh <<-[]

cd /root
autorunpid=`ps -eaf | grep autorun | awk '{print $2}'`
kill -HUP $autorunpid
sleep 2
kill -HUP $PPID
sleep 2
$EJECT -r $CDDEV
sleep 5
/bin/rm -f /tmp/eject.sh
exit
[]
cd /tmp
chmod 700 /tmp/eject.sh
nohup /tmp/eject.sh >/dev/null 2>&1 &
disown %nohup
$EJECT -r $CDDEV > /dev/null 2>&1
sleep 3
$EJECT -r $CDDEV > /dev/null 2>&1
fi
cd "$HOME"
exit $RC

Again, thanks for bringing this to our attention.

Hope this helps