@george1421 I see now and you’re right as my clients are all legacy boot/BIOS boot non UEFI and would not benefit from the client-arch examination.

I’ve already declarations set for each host in my dhcpd.conf file in terms if MAC to IP and so adding another field of filename “some boot loader file” won’t be impossible.

Thanks you for this exercise as I’ve learned some very important things here.

@george1421 First off thank you very much for this and for taking the time to reply.

It would work for sure but I’ve roughly 150 clients, not a lot but more then I’d like to add specifics for in my dhcpd.conf file.

Sooooo, this bit below is what I think that I’m after. However would you know how I can determine the client-arch value for a particular host?

Example code below.

# Define a class for PXE clients
class "pxeclients" {
    # Check if the client provides the client-architecture option
    match option client-arch;

    # If the client is UEFI x64 (client-arch code 00:07 or 00:09)
    if option client-arch = 00:07 or option client-arch = 00:09 {
        filename "boot/ipxe.efi";
    }
    # If the client is UEFI IA32 (client-arch code 00:06)
    elsif option client-arch = 00:06 {
        filename "boot/ipxe32.efi";
    }
    # Default to BIOS bootloader for all other clients
    else {
        filename "boot/undionly.kpxe";
    }
}

@george1421
Thanks for the reply and based on your answer it’s obvious that I havn’t explained my self well enough.

I’ve a diverse and split mix of 1Gb, 10Gb, 25Gb and 40Gb all which support either udionly.kpxe or ipxe.kpxe but not both.

What I’d like is to configure my DHCP server in suppling the right boot loader based on a condition that the host NIC returns.

I’d seen a how to or article here somewhere but it evades me. And so I was hoping that some one would know where to point me.

It was a clever if/then statement in a dhcpd.conf based on some hex value that the host NIC returned in order to load the correct boot loader.

Does this make more sense?

I’ve several workstations in place where some work with the undionly.kpxe while others the ipxe.kpxe file.
I had briefly read that one could do if/then statements on there PXE server in choosing the correct boot loader based on some condition that the hosts NIC returns.

Would some one know where I can find some docs regarding this as I’d love to implement it.

Right now I manually switch between the two fils on my PXE server.

@Tom-Elliott Alrighty then, I set the BIOS for legacy only and it worked with undionly.kpxe. So all good here.

@Tom-Elliott said in Mellanox ConnectX 3 imaging issues.:

ipxe.kpxe

Hi Tom,
Is there a document some where which explains all of the files in the tftpboot directory and there use case?

I’m having a hard time with this 40Gb system.

@Tom-Elliott Awesome, I’m excited to try it. Thanks Tom, much appreciated!

Hello,

I’m trying to image a system with a 40Gb Mellanox ConnectX 3.

My MPO cable is connected and I can see a light through it and the QSFP.

However I get this message that the link is down and the link status is unknown.

Is it a driver issue?

On my DHCP server, I’m using the supplied file from The Fog Project named undionly.kpxe.

Shall I use a different file?

Attached is a screen shot of my issue.

In short, it simply cycles through this message.

Hello,
I’ve Fog running w/o issue but was curious if some one has a link to more detailed docs regarding all of the different PXE files included with Fog?

I’m currently using undionly.kpxe and while it works for Intel NICs, I’m having a bit of a time in Fog working with the older SolarFlare SFC9020 10Gb fiber based NICs which I have plenty of.

BTW these are great cards.

@Tom-Elliott Hellooooo,
Sooooo, leaving the UUIDs as is I simply decided to use a different machine to create the image. I was using Intel and switched to a SuperMicro and set BIOS booting option to BOTH meaning Legacy + UEFI.

That same image was successfully deployed to that very problem Intel box as well as others. And since it was EXT4, the partition grew and shrunk as needed.