Anaconda Not Installing To Sda?

Home » CentOS » Anaconda Not Installing To Sda?
CentOS 1 Comment

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.

One thought on - Anaconda Not Installing To Sda?

  • 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?idx4314

    (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@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@c7.4 ~]# ifconfig eth0 | head -4
    eth0: flagsA63 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 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.