• Huge database entries number

    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!

  • PXE partial success, no tftp

    Unsolved FOG Problems
    4
    0 Votes
    4 Posts
    116 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.

  • Host report with image deployment date?

    General
    1
    0 Votes
    1 Posts
    19 Views
    No one has replied
  • 0 Votes
    5 Posts
    44 Views
    Gordon TaylorG

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

  • Phantom Tasks after Host Deletion

    Unsolved Bug Reports
    6
    0 Votes
    6 Posts
    400 Views
    Tom ElliottT

    @Clebboii Following up if you’d be willing to let us know?

    Thank you!

  • PXE issues

    Unsolved FOG Problems
    2
    0 Votes
    2 Posts
    103 Views
    george1421G

    @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.

  • Snapin Tasks Not Creating

    Solved FOG Problems
    12
    0 Votes
    12 Posts
    237 Views
    AUTH IT CenterA

    @Tom-Elliott I can confirm that it works with v1.5.10.1760. 🎉 Thank you very much! 🙇

  • Failed to update/create image log

    Solved FOG Problems
    6
    0 Votes
    6 Posts
    489 Views
    Tom ElliottT

    @The-Dealman Awesome thank you! and we did publish 1754 specifically due to this issue (manually running the automated processes just in case your org is worried at all 🙂 )

  • No pending host

    Unsolved FOG Problems
    7
    0 Votes
    7 Posts
    465 Views
    J

    @Tom-Elliott Sorry for the lack of clarity in my explanations and the use of screenshots unrelated to my problem.

    I have upgrade to the last beta and deploy on registered host works well.
    Thank you.

    I’ll check if not registered host now appear in Pending Hosts.

  • PXE boot failed some computers

    Solved FOG Problems
    7
    0 Votes
    7 Posts
    1k Views
    M

    I had some problems with AMD computers and found this

    https://knowledge.broadcom.com/external/article/269598/firmware-settings-for-ipxe-boot-on-lenov.html

    "Resolution
    During iPXE troubleshooting it has been determined that the following settings in Firmware/BIOS for Lenovo Thinkpad L15 Gen 3 need to be adjusted to allow for a successful iPXE boot:

    Memory protection - Set to ‘disabled’
    AMD V™ Technology - Set to ‘disabled’

    There also may be certain environments that require further changes. For further information contact Lenovo Support.

    Additional DS (Deployment Solution) and GSS (Ghost Solution Suite) files can be found in KB article Updated 64-bit ipxe.efi (ipxe v1.21.1+) binaries

    NOTE: The files in the above KB article are not a pointfix but are new version binaries signed by Microsoft"

    Leaving it here, because it solved my problem and it sounds like your problem

  • 0 Votes
    44 Posts
    19k Views
    R

    @george1421
    to be adding some to this topic since our system was broken again with the same problems.

    I updated recently to newer fog version (1.5.10.1751 and today to 1.5.10.1754) and that seems to break it again.
    I noticed that updating also starts using latest Initrd. (2025.02.4)

    Things are broken with latest Initrd. I set it back to 2024.02.9 AMD/Intel 64 bit and it is working again.
    Then i updated Initrd to 202502.0 AMD/Intel 64 bit and it is still working.

    Strange thing is that in webinterface the latest version is shown multiple times.
    When I open and download the upper one during pxe boot I see version 20251221 loaded. That one is not working.

    Is there anywhere to analyse what the differences are?

    I also want to add that we were focussing on nvme. But VROC doesn’t seem to work with nvme in raid.
    There are sata ssd/nvme in those slots.

    4bcbb845-8bb5-458c-b27a-8794b9b0a5b6-afbeelding.png

  • How to insert pre-deployment scripts ?

    Unsolved FOG Problems
    2
    0 Votes
    2 Posts
    230 Views
  • 0 Votes
    2 Posts
    127 Views
    DBailey635D

    Also occurring on Dell Latitude 5450 laptops.

  • Fog 1.6.0-beta.2268 Could not verify mount point

    Solved Bug Reports
    2
    0 Votes
    2 Posts
    88 Views
    S

    @sgennadi
    Fixed by
    touch /images/dev/.mntcheck

  • Fog 1.6.0-beta.2141 remove folder with image

    Unsolved Bug Reports
    3
    0 Votes
    3 Posts
    386 Views
    S

    Problem exists also with latest 1.6 builds…
    I think problem something in my database…
    When fog competed image early I see failed to update database… latest version no error but folder with previous version of image removed
    Task present not removed

  • 0 Votes
    2 Posts
    294 Views
    george1421G

    @alperi The bit if detail you are missing is what the kernel parameters were that was sent to the fog client. From what you posted it appears that the FOG server has all of the bits in the right spots.

    In the kernel parameters that are passed to bzImage during boot up it lists where the FOS engine can find the deployment server. I would verify the IP addresses are correct. If everything appears correct with the parameters, we can debug this a bit more by debug deploy and then manually interact with the fos engine from the target PC’s console.

  • 0 Votes
    8 Posts
    426 Views
    george1421G

    @djgalloway Just to add a bit of detail here. All of the work you did was on the iPXE side, which is great work by the way. The kernel driver I updated was after you select an FOG iPXE menu item that is when bzImage is loaded and run. It relies on kernel parameters that is provided by iPXE to find the root file system. This is technically what you fixed by ensuring that default.ipxe/boot.php from the fog server was being called. At the end of the day, I’m glad you got that working because your setup is definitely an edge case that works well in your environment.

  • 0 Votes
    6 Posts
    499 Views
    F

    @Tom-Elliott Alrighty. So my FOG server at another location is acting up in the same fashion with the failure to check in.

    Before we used it I updated to 1.60-beta.2265 to hopefully negate it but I did not drop the fog table from mysql before doing so.

    Are there any logs you want me to pull?

  • Ubuntu version to be used for FOG v1.5.10.1734

    Unsolved FOG Problems
    4
    0 Votes
    4 Posts
    402 Views
    A

    Was not sure which ubuntu version of these (20.04, 22.04, or 24.04) was used as the basis for the FOG release v1.5.10.1734.

    Thanks, @FOGBreaker101, for the version you are using.

    Some software doesn’t use the latest released version of the OS distro, but often one major version back.

  • 0 Votes
    7 Posts
    286 Views
    S

    Can you help me with bug topic ?
    Fog 1.6.0-beta.2141 remove folder with image