Dell Latitude 3500

[SebastianWolf]

G’Day!

I’ve got problems with PXE booting a Dell Latitude 3500. This piece of … nice technology … is the last computer here that is refusing to register to fog.
Of course, I have used the search function and of course I did a thorough Google Search. However, none of the mentioned solutions did work for me.

So: The BIOS is configured with UEFI stack enabled, Secure-Boot off and Fast-Boot on thorough. When booting from NIC it is downloading the NBP file successfully and then it stops - no loop or anything, it just stands still.
I updated the bios to the current version. I tried any of the available boot files in tftpboot and tracked that the correct file was being downloaded. Then I tried to use an external LAN-adapter with which I successfully deployed a Dell Latitude 7430.
No success at all.

Anyone got an idea?

Thanks!

[Tom Elliott]

@SebastianWolf Do you know if the network is doing an STP style connection that might be holding things up? I suppose this isn’t really the issue as it’d probably show up on other systems just as likely too.

Could also be “power saving” on the interface? Like it detected connection, then detected disconnection and just shut the power off.

[SebastianWolf]

@Tom-Elliott No STP connection, however, I forgot to mention, that I’m using Proxy-DHCP as I cannot access the DHCP. It’s a Meraki setup and the networks are managed by a centralised OU. This, again, is not causing any trouble with any other device. I even got some legacy rom machines that are well-behaved.
I cannot see any power saving settings, that may interfer.

[koenr]

Unfortunately I can’t offer any help, just a me too.

I see the same problem on Latitude 3440 and Latitude 3540, latest Bios, latest FOG, latest Kernel, Bios settings as they should on an installation that installed already 1000ths of devices (e.g. today 80 Latitude 3310 - no problem)

They boot fine over the network, but it goes wrong after the selection of the image to deploy (not registered host - host registration fails too). The big difference between the working L3310 and the not working devices I noticed, is that at some point all cksums in the tcp stream are incorrect.

alioth.http > 10.4.50.87.26147: Flags [.], cksum 0x4c2e (incorrect -> 0x7455), seq 2483321:2484769, ack 118, win 509, options [nop,nop,TS val 1727144768 ecr 204544], length 1448: HTTP

using tcpdump -s0 -vvv -i enp2s0 ether host ac:1a:3d:a4:dd:36

while with a working setup the failed checksums are rare.

I’m pulling my hair out - I’m out of ideas and 250 devices to deploy

[george1421]

@SebastianWolf What version of FOG are you running?
Second bit is have you tried to rebuild ipxe with the latest source code: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe?_=1687483137078 sometimes it does take the iPXE developers (not related to the fog project developers) a little bit of time to support really new kit. So there may be updates to iPXE after the FOG developers released the latest version. So lets start with iPXE rebuild if you are never seeing the iPXE banner on these computers.

If iPXE is failing for you we do have a method to usb boot into FOG, you lose some capabilities but it will image correctly once you register the target computer with FOG. So you guys are not dead in the water if iPXE doesn’t support your hardware just yet.

[koenr]

I got it working, using the realtec.efi driver. It took me some time to realise that the short vendor-class versions take over the later set long ones. Commenting out previous Arch:00007 was necessary.
Now the L3420 doesn’t install anymore, but I know were to look …

class "Legacy" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
    filename "undionly.kkpxe";
}
class "UEFI-32-2" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002";
    filename "i386-efi/snponly.efi";
}
class "UEFI-32-1" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
    filename "i386-efi/snponly.efi";
}
#class "UEFI-64-1" {
#    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
#    filename "snponly.efi";
#}
class "UEFI-64-2" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008";
    filename "snponly.efi";
}
class "UEFI-64-3" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009";
    filename "snponly.efi";
}
#class "SURFACE-PRO-4" {
#    match if substring(option vendor-class-identifier, 0, 32) = "PXEClient:Arch:00007:UNDI:003016";
#    filename "snponly.efi";
#}
class "Apple-Intel-Netboot" {
    match if substring(option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386";
    option dhcp-parameter-request-list 1,3,17,43,60;
    if (option dhcp-message-type = 8) {
        option vendor-class-identifier "AAPLBSDPC";
        if (substring(option vendor-encapsulated-options, 0, 3) = 01:01:01) {
            # BSDP List
            option vendor-encapsulated-options 01:01:01:04:02:80:00:07:04:81:00:05:2a:09:0D:81:00:05:2a:>
            filename "snponly.efi";
        }
    }
}

class "LATITIDE-3340" {
    match if substring(option vendor-class-identifier, 0, 32) = "PXEClient:Arch:00007:UNDI:003016";
    filename "realtek.efi";
}

[george1421]

@koenr said in Dell Latitude 3500:

class “LATITIDE-3340” {
match if substring(option vendor-class-identifier, 0, 32) = “PXEClient:Arch:00007:UNDI:003016”;
filename “realtek.efi”;
}

This will cause other systems to fail. There is nothing unique about “PXEClient:Arch:00007:UNDI:003016” multiple hardware will match.

Also order that the item appears in the list is important. The first match wins rule. For Dells the UUID field of the ethernet header should be unique within a model. If you use wireshark you can pick up the uuid of the pxe booting computer in dhcp option 97. You can tell if you have the right value because the first 4 characters spell DELL in reverse in ascii.

The other option if you only have a few of these devices is to use mac address matching to target specific computers with specific boot loaders.