Cannot deploy images
-
@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.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@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.
-
@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.
-
Actually, there is already unmanaged switch between.
Tom -
@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)
-
@george1421
Yes, the IP’s are correct and expected. -
@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.
-
@george1421
That was not it. I put the laptop on the 192.168.2.x subnet and I got the same results.Thanks,
Tom
-
@tom These next steps are shotgunning in several directions.
-
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.
-
Lets assume that FOS is corrupted. From the fog server linux console, navigate to
/var/www/html/fog/service/ipxeand then lets run themd5sumcommand and compare your images to mine.
1md5sum bzImagedfba0a3d8b0e8652857c69c45393465a
2md5sum bzImage3287d61b318f111434f880e0d4b500e539
3md5sum init.xzedbd5936f81144d1afb888f4b8712de5 -
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
exceptuse this tcpdump string.tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 or port 80because I want to see what is going on with the init.xz download, which uses http.
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
-
-
@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. -
@george1421
seems to be correct. -
@tom Ok then we can rule out something happened to the FOS image during or after the upgrade since the keys match.
-
@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.
-
Please find the PCAP file:
https://drive.google.com/file/d/0B1snnogmII3BU0xkSlJjczE5b1E/view?usp=sharing -
@tom Looking at it now
-
@tom Look at your IM (chat bubble) on the FOG tool part. I have a few questions
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
-
#!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 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.
-
@tom Well that wasn’t what I expected (it looks good).
Lets try one more URL call:
http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=<mac_address_of_target_computer>Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
-
@george1421 Just for clarity this is what we see in the pcap
Note that packet 56 asking for
bzImage412and then in packet 58 the FOG server says 302 not found.
