• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. Popular
    Log in to post
    • All Time
    • Day
    • Week
    • Month
    • All Topics
    • New Topics
    • Watched Topics
    • Unreplied Topics
    • All categories
    • M

      FOG Client service disconnection, pending snapins are not even being detected

      Watching Ignoring Scheduled Pinned Locked Moved General Problems
      9
      0 Votes
      9 Posts
      132 Views
      J

      @Tom-Elliott said in FOG Client service disconnection, pending snapins are not even being detected:

      @Jamaal The client lives on the Machine itself. not on the fog server.

      Those logs live on teh Windows machine I forget the exact path but something like:

      c:\program files\fog client\fog-error.log or something like that?

      Yes, it’s c:\program files (x86)\fog\fog.log

      I figured out the issue, lol. I was having a moment, but thanks for helping me out.

    • Gordon TaylorG

      since upgrading to 1.5.10.1754 deploying image from the fog client menu fails (deploying from console is fine)

      Watching Ignoring Scheduled Pinned Locked Moved Solved FOG Problems
      5
      0 Votes
      5 Posts
      199 Views
      Gordon TaylorG

      @Tom-Elliott Thanks Tom, yes that looks to have sorted it out thankyou…

    • B

      Host report with image deployment date?

      Watching Ignoring Scheduled Pinned Locked Moved General
      2
      0 Votes
      2 Posts
      74 Views
      S

      In Reports Menu, Imaging Log You will find this information.

    • T

      PXE partial success, no tftp

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved FOG Problems
      4
      0 Votes
      4 Posts
      304 Views
      george1421G

      @thezman007 I would say the pcap file you provided is a model of how a proxy dhcp and dhcp server should interact. The first part of the pcap is perfect.

      The second part starting at second #19. The client issues a dhcp discover and the dnsmasq answers right away, the client had to issue a second discover request before the main dhcp server @ 2.2 address responded. This pattern is repeated at the end of the pcap (you can see this if you look at the pcap with wireshark).

      So this is only me reading the tea leaves but I think there is something up with your main dhcp server because its being slow to respond to dhcp requests. Understand I only can see 25 second pcap but I find it abnormal. When things go sideways (and it probably will) get a pcap of the failure, that’s going to tell us what’s missing.

      I’m going to remove your pcap from your post because its not needed now.

    • F

      Creating image - permission denied

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved FOG Problems
      1
      0 Votes
      1 Posts
      84 Views
      No one has replied
    • J

      PXE issues

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved FOG Problems
      3
      0 Votes
      3 Posts
      269 Views
      J

      @george1421 said in PXE issues:

      @Jamaal This problem is solvable but it make take some effort on your part.

      Lets start with the basics.

      For the DHCP IP zone where your pxe booting clients live, you need to set dhcp options 66 to the IP address of your fog server. And for dhcp options 67 that needs to be snponly.efi or snp.efi. With those settings configured on a MS Windows based dhcp server a pxe booting client should boot. Make sure on your dhcp server that is responding to bootp and dhcp requests. Its been a while since I messed with windows but on the dhcp server there should be a setting of dhcp bootp or both. Select both.

      Now lets talk about WDS for a second. A WDS server can use dhcp options 66 and 67 as above, but it can also run a proxy dhcp service that tells the client to ignore the dhcp options and come talk to it for boot information after it gets an IP address for the dhcp server. This maybe called a netboot service or something like that on your WDS server. Its not part of the main WDS service. If this service is still enabled it will override any settings you make in dhcp for pxe booting.

      So how do you figure this out to what’s wrong?

      The easiest and most complicated issue is to identify what is flying down your network during the pxe booting process. You can do this with wireshark on a witness computer (computer not part of the pxe booting process). This witness computer can either be a ms windows or linux computer, the key is to have wireshark loaded. When you start up a capture use a capture filter of port 67 or port 68 or port 4011 That will limit what wireshark sees to only the dhcp packets. Make sure the witness computer is connected to the same subnet as the pxe booting computer.

      Start the packet capture and then attempt to pxe boot the target computer. Continue to capture the packet until the pxe booting computer either reaches the fog iPXE menu or errors out. Then stop the capture.

      In the top section you should see the DORA (discover, offer, request, and finally ack/nack) process. The process goes as follows:
      Client -> Discovery
      Server-> Offer
      Client -> Request
      Server -> Ack/Nack

      In this process you are most interested in the one or more OFFER packets. In a normal network you should only see one OFFER packet. When WDS is involved you will see one OFFER packet from your main dhcp server and a second OFFER packet from your WDS server. If you are seeing the OFFER from your WDS server then you don’t have the proxy-dhcp service disabled, and that is causing your issue. If you are seeing two offer packets from two different dhcp servers, such as a primary / secondary setup make sure both dhcp server are configured to boot from FOG server.

      Now what do you do if you only have one OFFER packet and its still not working. This is where you need to select the OFFER packet and then look at the data in the parameters box. There will be the bootp fields of next-server and boot-file these need to be configured for the fog server IP and snp.efi. Then in the dhcp options section options 66 and 67 need to be set correctly. If one or the other sections are not set correctly you will get random machines not booting while others are.

      If you can’t figure it out save the packet capture file “be sure you only captured the dhcp process” and up load the file to a file share site and post the link here and one of us will take a look to see what’s wrong. But I think from what I covered here you should be able to figure out what the pxe booting client is being told to do incorrectly.

      George,

      I ran the idea with the system administrator at my job and of course he was doubtful (conceited), he turned off the server thinking that would solve the issue. I ended up looking at an older forum and made a USB with the ipce file and booted up the machines that were given me issues and that worked. You guys can close this and mark as resolved. Again, I appreciate your guidance on this.

    • AxeMeAQuestion22A

      Fog iPXE Menu no input

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved FOG Problems
      30
      0 Votes
      30 Posts
      14k Views
      S

      There are multiple new problems related to this issue.

      First one is buildipxe.sh script and ipxe with commits after 01/14/26. It does not enable USB_HCD_USBIO correctly.:

      sed -i 's+//#define USB_HCD_USBIO+#define USB_HCD_USBIO+g' config/usb.h sed -i 's+//#undef USB_KEYBOARD+#define USB_KEYBOARD+g' config/usb.h sed -i 's+//#undef USB_EFI+#undef USB_EFI+g' config/usb.h

      but it doesn’t work correctly with latest ipxe source files because of the tabs. It should be:

      sed -i 's+//#define USB_HCD_USBIO+#define USB_HCD_USBIO+g' config/usb.h sed -i 's+#undef USB_KEYBOARD+#define USB_KEYBOARD+g' config/usb.h

      USB_EFI is already defined in the source, so last sed is not needed.

      But after fixing this and compiling, keyboard does not work anyway. There were significant commits to ipxe source on 1/15/26. They changed usb.h along with defaults. I was able to make it work again by going back to 6cccb3bdc00359068c07125258d71ce24db5118a commit, enabling USB_HCD_USBIO in usb.h and disabling “#define USB_CMD” in general.h that FOG uses (without this it won’t compile giving error about multiple definition of `usbio_driver’).

    • R

      Capone PXE Menu Item Missing

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved FOG Problems
      3
      0 Votes
      3 Posts
      627 Views
      R

      Adding the menu manually with the above settings resolved the issue for me.

    • B

      Unable to Capture an image: ERROR: Could not adjust the bad sector list

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved FOG Problems
      10
      0 Votes
      10 Posts
      2k Views
      D

      @Tom-Elliott I’m having this issue currently running Fog version 1.5.10.1593 and OS version 10.0.19044 Build 19044. I’ve tried all of these steps and a plethora of others but have been unable to successfully capture a final image. Do you have any other ideas to try?

    • S

      Huge database entries number

      Watching Ignoring Scheduled Pinned Locked Moved Solved FOG Problems
      12
      0 Votes
      12 Posts
      1k Views
      S

      After upgrading to 1.5.10.1754 it works just fine.
      Thanks for bug tracking and improvement!

    • 1 / 1