Just to follow up for posterity, found the issue some time ago. In short, using a slightly older version of cobbler with a later version of CentOS shipping an updated ifconfig. Upshot, keep cobbler up to date. More details (identifying information has been munged): It turns out that under the hood, the pre_install_network_config snippet is generating this code in Cobbler 2.6.11 (released in January 2016): IFNAME=$(ifconfig -a | grep -i '00:50:56:8e:44:ee' | cut -d " " -f 1) However the output format of the ifconfig command changed in Fedora way before that (Fedora feeds into RHEL which feeds into CentOS): https://bugzilla.redhat.com/show_bug.cgi?id=784314 (Now that said, lots of people are so used to ifconfig, which has been deprecated for at least a decade, that they still use it even though ip exists and is installed by default.) The output changed like so, and obviously that expression would not function. [root at c6.9 ~]# ifconfig eth0 | head -4 eth0 Link encap:Ethernet HWaddr 00:50:56:8E:82:05 inet addr:1.2.3.4 Bcast:1.2.3.255 Mask:255.255.255.0 inet6 addr: fe80::250:56ff:fe8e:6605/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 [root at c7.4 ~]# ifconfig eth0 | head -4 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 2.3.4.5 netmask 255.255.255.0 broadcast 2.3.4.255 inet6 fe80::250:56ff:feb9:ec1f prefixlen 64 scopeid 0x20<link> ether 00:50:56:b9:ab:1f txqueuelen 1000 (Ethernet) It turns out that cobbler 2.8 (in EPEL) has a new pre_install_network_config snippet which uses iproute2's "ip link", something like this: ip -o link | grep -i '00:50:56:b9:ec:1f' | awk -F': ' '{print $2}' I didn't want to mess around with cheetah or updating cobbler right before we really needed it for a large build, so I copied in the updated pre_install_network_config snippet under a new name, and duped the existing network_config snippet under a new name to call the pre-install snippet. $SNIPPET('network_config_el7') $SNIPPET('pre_install_network_config_el7') As to how this previously worked with CentOS 7, I am quite puzzled. I suspect maybe anaconda was rebuilt with a new net-tools (package including ifconfig) for 7.4 but that sounds wrong. However since investigating this would require more time spent digging around in anaconda internals I have decided that I have anything else to do first. On Wed, Sep 27, 2017 at 10:47:11AM -0400, Christopher Wood wrote: > I'm having what appears at first glance to be a kickstart+anaconda issue on CentOS 7.4. > > As near as I can tell in the program.log in the anaconda environment, the partitioning instructions downloaded with the kickstart from cobbler appear to simply not be applied. Then /mnt/sysimage is not mounted, the logs are not copied to /mnt/sysimage/root and the installation stalls due to the anamon checking. (Also anaconda is trying to e2fsck /dev/loop devices which is puzzling.) > > If anybody has hints about what I would double-check or if you've resolved a similar issue I would be quite interested. > > More details: > > I see the same behaviour after cutting most items out of the cobbler kickstart template, however I confirm that /run/install/ks.cfg in the anaconda environment has the following: > > ignoredisk --only-use=sda > > zerombr > bootloader --location=mbr > clearpart --all > part / --label="/" --fstype=ext4 --grow --asprimary > > program.log from the anaconda environment is here: > > https://gist.github.com/christopherwood/72f390d7e5788b9bc9e841d40c926895 > > The system does boot and install just fine from the CentOS 7.4 iso without being kickstarted. > > This is on vmware (esxi 6.0), I've tried with the paravirtual and lsi logic scsi controllers with the same result. > > I've tried different previously (CentOS 7.3) working cobbler profiles that do not work with 7.4 now. > > If I change the drive name (sda) to a ludicrous value anaconda simply errors, so at some level it's understanding about sda. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos