Broken autofs maps 'variable replacement' in Kickstart post installation process

[yubby]

Have 'variable substitutions' been removed/disabled from the automounter in the Kickstart 'post install' process ?

I'm testing my Kickstart infrastructure, which uses the NFS automounter in the "%post" section, that has functioned in all of the EL 5.x, 6.x, and RHEL 7.2 (last time I tested O/S updates) versions.

BUT in preparation of the upcoming 7.4 release I'm testing the process using CentOS 7.3 (x86_64), where I encountered the issue. The 'post' portion of the Kickstart process fails to mount (or 'locate') the exported NFS locations specified, though when I intervene (on 'console 2') I can edit the '/etc/auto.nfs' file (in the chrooted environment) replacing the 'variable' with the hard-coded "x86_64" text, and successfully access them.

If left with the 'variable' designation intact, the auto.nfs designations function correctly once the server has rebooted (completed the Kickstart process).

I am able to get the correct value for "uname -m" when in the 'chrooted' environment ('x86_64') such that it appears that the 'variable replacement' is just not being performed...

The "/etc/auto.nfs" configuration file contains:

Code: Select all

kickstart       -ro,soft,intr   buildsvr:/export/software/linux/CentOS/dists/centos-7.3-$ARCH
yum             -ro,soft,intr   buildsvr:/export/software/linux/&/repos/centos-7.3-$ARCH
updates         -ro,soft,intr   buildsvr:/export/software/linux/yum/&/centos-7.3-$ARCH
extras          -ro,soft,intr   buildsvr:/export/software/linux/yum/&/centos-7.3-$ARCH]

[aks]

(Work around).
Suggest test for ${ARCH}. Then check the file and use sed as appropriate to fix the issue. There seems top be a whole bunch of sh*t happening with kickstart now (TM). It was so much easier/better pre 7. I usually end up NOT running in the chroot (for example systemd "knows" you're in a chroot and refuses to do certain things).