Installation On Knights Landing (KNL) Machines Failure

Home » CentOS » Installation On Knights Landing (KNL) Machines Failure
CentOS 3 Comments

Hi all,

We have a customer, where we are trying to install CentOS 7.3 on the new Intel Knights Landing nodes, unfortunately, we are unable to install then using PXE boot.

Now, I have a lot of experience of installation of machines using PXE
boot, so the setup of that is not the problem. Both myself and my colleagues have looked through the problem, and we are unable to get much diagnosis of the problem.

When booting the machine via the network, it loads the ramdisk, and then we get no output, and then the machine reboots. Unfortunately, we have unable to get anything else on the screen. The machines don’t have VGA, and monitor capable ports, so we are stuck with Serial Over Lan over IPMI.

We have however, after some searching via search engines, we found some documentation suggesting that RHEL 7.2 and then with significant updates on 7.3 do work on these types of machines. We have then followed the same process to try installing the machines, and we have managed to get the machine up, and in a working order. However, we’d like to use CentOS
7.3, and would like to find the process of doing so, if it is any different

I was wondering to see if anyone else has seen any similar issues, and if there is a problem here, that we haven’t tackled? Any further debugging we can do? Any assistance on this would be much appreciated

3 thoughts on - Installation On Knights Landing (KNL) Machines Failure

  • Apologies for the noise, it was a mistake from our side

    For some reason someone had set the installation directory to be from aarch64 instead of x86_64

  • Arif Ali wrote:


    YES. I was unable to build my four nodes using PXEboot, because the damn thing won’t take what it’s given, and won’t skip to the default target. It INSISTS (ok, it is in the RFC, but…) on trying its MAC, or maybe it’s the UUID, I disremember, and spends *MINUTES – 4? 5? then tries again by shortening it by one char, and again, and again, and by the time it tries default, it’s literally FIFTEEN MINUTES LATER, and the TFTP/pxe has timed out.

    Had to use a USB…. Strong suggestion: if you’re doing more than one node, I’ve posted more than once how to do an upgrade by rsync. I did one of our four, tried, and tried, and finally gave up, and once the first was correctly built, rsynced to the other three nodes.

    mark

  • Mark,

    I haven’t faced the slow iterations you’re seeing, but I sometimes use a shell script I wrote for naming PXE configuration files on per-IPv4
    bases:

    https://github.com/heinlein/pxehex

    I don’t know if it will help in your case, but I thought I’d pass it along.