Cannot deploy images

[Tom]

@sebastian-roth
The system is Latitude E7240 with Intel onboard NIC I218-LM.

attached is the result of lspci -n
when I tried to run lsusb, I got “unable to initialize libusb: -99”

[Tom]

@george1421
We have only Latitude in our environment, the issue repeats on 7280 as well. All firmware are up to date.
I cannot tell what changed, I’ve upgraded to 1.4.4 awhile ago and it was working properly.
Is there any log I can look into?

Thanks,

Tom

[Sebastian Roth]

@Tom Ok I was wrong on this one. Not one of these realtek USB NICs, thank god! Searching the forum I can see that many people have used this model. So it definitely works or has worked. Let’s see if George can replicate the issue or not.

[george1421]

@sebastian-roth OK I can pxe boot these 7240s no problem. I set the bios back to factory, put laptop in bios (legacy mode), enabled pxe booting on built in network interface and then booted into FOG registration.

This is just for documentation purposes: this laptop has bios A21 with 4GB of ram and a 128GB SSD.

[george1421]

@tom Can we make the statement that all latitudes have the issue, or all computers have the issue?

While this is just a wild (strange) idea, do you have an unmanaged switch you can place between the pxe booting computer and the building network switch? This really doesn’t sound like a spanning tree issue, but it just might. Those 7240s are pretty quick.

[Tom]

@george1421

Actually, there is already unmanaged switch between.
Tom

[george1421]

@tom OK watching your video frame by frame (well almost). I see your fog server is on 192.168.2.196 but your pxe client computer and dhcp server are on 10.141.32.x/24 Is this expected?

Unfortunately the video doesn’t show me where its getting bzImage from (just off the top of the screen)

[Tom]

@george1421
Yes, the IP’s are correct and expected.

[george1421]

@tom ok just to rule out a routing/router issue can you try and move the pxe booting client to the same subnet as the FOG server? I know I’m grasping at straws here, but it should but working… We have to find out where the issue isn’t at this point.

[Tom]

@george1421
That was not it. I put the laptop on the 192.168.2.x subnet and I got the same results.

Thanks,

Tom

[george1421]

@tom These next steps are shotgunning in several directions.

1. Do you have any other models we can try. Like an older latitude or even a desktop. I’m interested to see if we can get FOS to boot at all.

2. Lets assume that FOS is corrupted. From the fog server linux console, navigate to /var/www/html/fog/service/ipxe and then lets run the md5sum command and compare your images to mine.
   1 md5sum bzImage dfba0a3d8b0e8652857c69c45393465a
   2 md5sum bzImage32 87d61b318f111434f880e0d4b500e539
   3 md5sum init.xz edbd5936f81144d1afb888f4b8712de5

3. If we put the pxe booting computer on the same subnet as the FOG server, we can use the fog server to listen in on the pxe booting process of the target computer. (I’m not sure this one is going to tell us much, but again your pxe booting process is not typical either). Follow the instructions here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue upload the pcap to a google drive or dropbox and I’ll take a look at it. Either post the link here or send me an IM and I will review it off-line. Use the provided instructions except use this tcpdump string. tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 or port 80 because I want to see what is going on with the init.xz download, which uses http.

[george1421]

@george1421 Wait, I remember another situation just like this, where the OP was sending pxelinux.0 or any of the undionly.0 files as dhcp option 67 {boot-file} and it would run just fine but blow up while it was downloading the init.xz. This sure seems to fit that situation.

[Tom]

@george1421

seems to be correct.

[george1421]

@tom Ok then we can rule out something happened to the FOS image during or after the upgrade since the keys match.

[Sebastian Roth]

@Tom Would you please also comment on George’s question about other laptops/PCs PXE behavior. Is it only one single device or all of the 7240s? Please try other devices to see if you have a general issue or if it’s model related in your case.

[Tom]

@george1421

Please find the PCAP file:
https://drive.google.com/file/d/0B1snnogmII3BU0xkSlJjczE5b1E/view?usp=sharing

[george1421]

@tom Looking at it now

[george1421]

@tom Look at your IM (chat bubble) on the FOG tool part. I have a few questions

[Tom]

@george1421

#!ipxe
set fog-ip 192.168.2.196
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
colour --rgb 0x00567a 1 ||
colour --rgb 0x00567a 2 ||
colour --rgb 0x00567a 4 ||
cpair --foreground 7 --background 2 2 ||
goto MENU
:alt_console
cpair --background 0 1 ||
cpair --background 1 2 ||
goto MENU
:get_console
console --picture http://192.168.2.196/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
colour --rgb 0xff0000 0 ||
cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||
item --gap Host is NOT registered!
item --gap -- -------------------------------------
item fog.local Boot from hard disk
item fog.memtest Run Memtest86+
item fog.reginput Perform Full Host Registration and Inventory
item fog.reg Quick Registration and Inventory
item fog.deployimage Deploy Image
item fog.multijoin Join Multicast Session
item fog.sysinfo Client System Information (Compatibility)
choose --default fog.local --timeout 10000 target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
:fog.memtest
kernel memdisk initrd=memtest.bin iso raw
initrd memtest.bin
boot || goto MENU
:fog.reginput
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.2.196/fog/ consoleblank=0 rootfstype=ext4 storage=192.168.2.196:/images/ storageip=192.168.2.196 loglevel=4 mode=manreg
imgfetch init_32.xz
boot || goto MENU
:fog.reg
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.2.196/fog/ consoleblank=0 rootfstype=ext4 storage=192.168.2.196:/images/ storageip=192.168.2.196 loglevel=4 mode=autoreg
imgfetch init_32.xz
boot || goto MENU
:fog.deployimage
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:fog.multijoin
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param sessionJoin 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:fog.sysinfo
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.2.196/fog/ consoleblank=0 rootfstype=ext4 storage=192.168.2.196:/images/ storageip=192.168.2.196 loglevel=4 mode=sysinfo
imgfetch init_32.xz
boot || goto MENU
:bootme
chain -ar http://192.168.2.196/fog/service/ipxe/boot.php##params ||
goto MENU
autoboot

[george1421]

@george1421 So far we found in the pcap that the client is trying to download bzImage412 and the fog server is replying with file not found.