Dell Latitude 5510 Will Not PXE Boot

[colossalfalafel]

@george1421 I can use an older model Dell Latitude and PXE booting and image capture/deploy works perfectly fine.

The Fog server is on the same IP subnet as the 5510

[george1421]

@colossalfalafel The older dells are also uefi mode? (sorry have to ask so I can build a picture of the setup in my mind)

[colossalfalafel]

@george1421 Correct, the older model is also UEFI. I believe the older model is from ~2018, but it’s currently at another office, so I will have to get back to you on the exact model

[george1421]

@colossalfalafel No that’s fine. My question was more focused on have you ever pxe booted a uefi system before.

ok now the fun part (maybe). Lets grab a pcap of the pxe booting process. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

This will let us evesdrop on the pxe booting process using the FOG server. Upload the pcap to a file share site and either DM me the link or post it in this thread and I will take a look at it.

[Sebastian Roth]

@colossalfalafel That’s an interesting UEFI setting we see in the picture. From my point of view this looks like a pointer to a local file on disk. I am not sure but I would not expect this to be a pointer to a PXE boot file.

Looking forward to see what we get from the PCAP - follow George’s post!

[colossalfalafel]

Sorry about the delay in response, I support several satellite locations and wasn’t able to get back to the office hosting Fog until earlier this week.

I’ve solved the PXE boot issue, turned out to be a DHCP server config issue.

However, I’m still unable to deploy images with Fog to the Latitude 5510 models. I’ve done a bit of digging and found that they are arriving with a RAID configuration using one 256GB NVMe drive, and presumably another chunk of soldered 256GB on the motherboard (UEFI only reports a single slot-in drive).

I’m under the impression that the RAID config is causing the Fog imaging to fail. The RAID is set to “On” and is identified as ‘Intel Rapid Restore Technology’ in the UEFI.

Boot Options (F12) “Device Configuration” option sends me to the Intel Rapid Storage Technology RAID utility, which is running Intel RST 17.8.1.4572 RAID Driver. It lists the NVMe drive as a non-RAID physical disk, but the OS and Windows install boot UI shows ~465GB of usable space.

Is it possible that the Fog platform is missing support of some level for the Intel RST RAID Driver and/or Micron 2200S NVMe drive installed in the laptop?

Here is a screenshot of the error I’m seeing when configuring the drive as AHCI:

Here is a screenshot of the error I’m seeing when configuring the drive as RAID (default UEFI option):

Here is the NVMe drive as listed in the Intel RAID utility:

Thank you very much for your help.

[george1421]

@colossalfalafel Acutally I’m working on this issue in this thread: https://forums.fogproject.org/post/140103 I have positive success with a precision 5510, but I have doubts that its actually working. Would you test both bzImages from the above post? I don’t know if it works on my wife’s 5510, because the linux kernel developers fixed it or there is something strange with the configuration her company puts on her computer (I didn’t want to make any adjustments to it because its protected by bitlocker). The computer is in uefi raid-on mode and I can see the storage disk when I pxe boot into FOG. This is a driver compatibility between the hardware and linux kernel itself (bzImage) in FOG’s case.

The issue is that the intel sata controller changes its personality based on raid-on mode vs ahci mode. It actually presents itself as a different device with a different hardware ID based on what mode it is running in.

Edit: Ignore this request, the 5510 I have has a sata disk in it. I just tested the kernel with a 7280 with an NVMe disk and the linux kernel does not work with this disk structure. So we are still no where in regards to a solution to this.

[Sebastian Roth]

@colossalfalafel In AHCI mode we see an error pointing to the fact that the Image was captured from a larger size disk and FOG is not able to deploy it to this disk being too small. Please post the contents of the text file d1.partitions found in /Images/IMAGENAME/ folder on your FOG server.

[colossalfalafel]

@sebastian-roth Here is the output from my d1.partitions file regarding the image mentioned in the Fog screenshot:

cat d1.partitions
label: gpt
label-id: 1AD8A27B-2892-4B58-9460-570AEA20B851
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 1000215182
sector-size: 512

/dev/sda1 : start= 2048, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CCD22F06-7C7D-4383-9965-A85BB0B66131, name=“EFI system partition”, attrs=“GUID:63”
/dev/sda2 : start= 206848, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=399B665C-FE87-492E-A245-6080EB049F28, name=“Microsoft reserved partition”, attrs=“GUID:63”
/dev/sda3 : start= 239616, size= 998952902, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=CB4B85CB-1D38-4D03-AF1E-D44D1966CAAC, name=“Basic data partition”
/dev/sda4 : start= 999192576, size= 1019904, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=857DFACC-AE01-4E3A-A64E-99C4F6A788F7, attrs=“RequiredPartition GUID:63”

Thanks again for the reply!

[Sebastian Roth]

@colossalfalafel said in Dell Latitude 5510 Will Not PXE Boot:

last-lba: 1000215182
…
/dev/sda4 : start= 999192576 …

With these two numbers we see that this image was captured on a 477 GB (sector value * 512 byte block size / 1024 / 1024 / 1024) disk. Deploying this image to a smaller size disk will fail with this partition layout - unless you use a new init we just started testing.

[colossalfalafel]

@sebastian-roth After calling Dell support, it seems there was something wrong with the laptop that was being used to test. I re-configured the UEFI to defaults, purged the default config of RAID to AHCI, and have rebuilt my images using the smaller drives on the newer laptops.

I am now able to capture and deploy as expected. Thanks to everyone for your assistance with this! We can consider this thread resolved.