Group Details

FOG Hangouts

Being a member of FOG Hangouts will allow you to stay updated about the latest FOG Hangout; the when, the where, and the details. Membership in this group is automatic membership in a mailing list.

  • RE: ipxe/boot.php and bzImage running very slow

    @danieln said in ipxe/boot.php and bzImage running very slow:

    The only change was that I added one additional storage node.

    Storage node being in the same subnet as well?

    posted in FOG Problems
  • RE: ClearOS-DHCP, Fog, PXE, & dnsmasq

    @geardog Two things from the tutorial I just want to point out:

    1. Make sure its at least version 2.76 by issuing this command at the fog server’s linux command prompt sudo dnsmasq -v. The version needs to be 2.76 or later.

    and as George already mentioned here:

    1. Be sure to replace <fog_server_ip> exactly with the IP address of your fog server. Be aware that <fog_server_ip> appears multiple times in the config file.
    posted in FOG Problems
  • RE: Hanging on ipxe initalizing devices.

    @huecuva said in Hanging on ipxe initalizing devices.:

    Can those iPXE binaries be changed in the webgui?

    No because it all depends on the DHCP server you actually use in your network (quite often it’s not on the FOG server itself).

    posted in FOG Problems
  • RE: ClearOS-DHCP, Fog, PXE, & dnsmasq

    @geardog The linked tutorial and config is about running dnsmasq in DHCPProxy mode. So you’d have a “normal” DHCP server handing out just the IP/router/DNS information to the client and dnsmasq (in the FOG server) can add the PXE boot information for client to do netboot.

    All those machines being on the same subnet should make things work without too much issues. If you have those in different subnets than there is more you need to do.

    posted in FOG Problems
  • RE: "Bad Sectors" when uploading image (Abort), RAID-1 crashed

    @lakk said in "Bad Sectors" when uploading image (Abort), RAID-1 crashed:

    how can i find the original size of the partition?
    because it seems that after every restart and retry to upload the image the last (so shrinked) partition-size is being written to the /dev folder?

    Yes subsequent captures will overwrite the earlier information. FOG does not store all the old information. You can only manually try to put back an older partition layout manually. But this is very tricky and many things can go wrong.

    Before proceeding I would take a RAW (dd) backup of both the disks.

    All in all it sounds like a chain of a couple of things that have gone wrong.

    • RAID got degraded some time ago, so both disks are now in a different state and should not be mixed up!
    • Why did you use the resizable image type? While FOG is not a backup tool I would not use resizable image if I don’t plan to deploy the image to a different size disk.
    • While I can’t be absolutely sure I would think that shrinking should not leave the system in an un-bootable state. So my guess is the bad sector error is playing into that too.

    I think you are raising the right questions about your system but I am not sure this is the right forum for this. There are so many things we don’t know about your setup and I don’t feel confident to give guidance in such a situation (speaking for myself).

    posted in Windows Problems
  • RE: Hanging on ipxe initalizing devices.

    @Huecuva Is secure boot disabled on the HTPC? The other thing you can try is using a different iPXE binary. If the HTPC is set to boot in legacy BIOS mode you can try using undionly.pxe, undionly.kpxe or ipxe.pxe (instead of the default undionly.kkpxe). If it’s set to UEFI mode then you’d try out snponly.efi or snp.efi instead of the default ipxe.efi.

    Be aware that changing that globally in your DHCP configuration (should be in /etc/dhcp/dhcpd.conf on a Debian server I think if you said yes to enable DHCP directly on your FOG server) might change boot behavior for other machines that used to work with the defaults.

    posted in FOG Problems
  • RE: ipxe/boot.php and bzImage running very slow

    @danieln said in ipxe/boot.php and bzImage running very slow:

    My FOG deployment speeds seem to be normal, however, when any client pxeboots into FOG, /fog/service/ipxe/boot.php and bzImage are running very slow . They eventually work, but after each attempt to run there are maybe 30 or so dots after it.

    This is within iPXE that is used by FOG for some of the PXE boot process. So as a first guess I would say there is a driver issue within iPXE with a particular NIC (network interface card). But the question arises if this happens with all of your hosts in exactly the same way?

    Are your hosts and the FOG server all on the same subnet?

    This just started occuring today.

    This makes things even more interesting. What changed since it worked fine? Update on the FOG server (new iPXE binaries)? Changed network components? Used different hosts (NICs, maybe USB ethernet adapters)?

    posted in FOG Problems
  • RE: HP Elitebook 840 G7

    @joyboy11111 I’m going to guess, and no judgement intended please, that you’re not overly familiar with VI/VIM for editing file?

    type these commands:

    Press enter

    Note the/ = search everything after.

    Once you find the line line arrow over to the area to edit and press the i key, Press delete over the ipxe.efi then type snponly.efi

    Note the i = insert to leave “insert/edit” mode press ESC key

    Press the esc

    Type :w

    Note the : puts VI into "command mode. w = save/write file.

    To exit VI type: :q

    Note the : puts the VI into "command mode. q = quit.

    posted in Hardware Compatibility
  • RE: Database Maintenance - Error 1142

    @jdnoble18 Why are you connecting using the fogstorage user? You should be using the fogmaster user to run the db cleanup commands.

    posted in General
  • RE: API Token change

    @alesser Not really unfortunately.

    The token you see on the screen is stored in the fogserver in a different mechanism. What you see is an encrypted string compared to what is actually stored in the FOG Server.

    If you have the original “plain text” value, it should work (even if you don’t see the same key) as it’s still referencing the same “plain text” value.

    posted in General Problems