@Mightmar Do you have an unmanaged (read: cheap) network switch you can place between this computer and your building network switch?

From your first post it looks like iPXE can see the network card because it references the mac address but it appears its not seeing the dhcp response from your dhcp server. I have seen conditions like this before related to having normal spanning tree enabled and not using one of the fast spanning tree protocols. Inserting a cheap unmanaged switch between the pxe booting computer and the building switch is a simple test to see if its a spanning tree issue or not.

The other thing I see is that your network adapter is a realtek nic. Instead if using undionly.kpxe boot loader you can try ipxe.kpxe and see if it boots into the iPXE menu. You will need to change your dhcp option 67 to make this happen. To explain it simply the undionly.kpxe boot loader uses the undi driver built into the network card this boot loader works 95 % of the time. With some cards the undi built in network driver has a conflict with iPXE. The ipxe.kpxe and the ipxe.efi have all of the network card drivers built in. Lastly there is a realtek specific boot loader, you will have to look in the /tftpboot directory, I think its called realtek.kpxe.

If everything else fails we can see if we can boot directly into FOS linux from a flash drive bypassing ipxe all together. There are some caveats using this method but as long as FOS Linux supports that network card it will work.

When you initially create the host via the ui or via a registration it will show as active. There is also an agent that runs in the back ground that repings the client to show if its up or down. Now when I say ping, I don’t mean the traditional ICMP ping, but its more like a socket connection to the target computer on udp port 445.

So the first issue could be the windows firewall blocking connections to udp port 445.

The second issue is that they name you have the system listed in FOG, in this case HE-D001992 can’t be looked up using DNS. FOG doesn’t know IP addresses, it only know the system name. So it will try to ping HE-D001992. If that is not its windows name or you don’t have DNS configured properly then it will appear down to the FOG Service.

WOL is impacted by the target computer more than the fog server.

In my environment I have FOG running on ESXi 6.7 VM. I just had to look but I’m running a vmxnet3 virtual network interface on a centos 7.5 server for my fog server.

I know when I deploy an image to a Dell computer on the same subnet as the FOG server, the target computer will start up.

So what I’m wondering is… is the problem with the fog server or the target computer? One way to test would be to get a windows utility app that sends out WOL packets to see if the computer starts correctly. I’ve used the nirsoft wakemeonlan https://www.nirsoft.net/utils/wake_on_lan.html its pretty basic but should test if the workstation is setup correctly.

On the FOG server side make sure the mac address is right and matches the target computer.

Lastly Windows 10 messes with WOL, messes as is disables it. A way to test if Win10 is messing with WOL. Test WOL by unplugging and plugging in the power cable. This is state G0, if I remember correctly. Test WOL here if it works then great. Next boot into windows and then shutdown. This is state S5. Test WOL again. My bet is that it will not boot with WOL here.

@Jeff-Findley So the only change is time that fixes the problem. I’m going to assume that during the boot into the debug mode it failed to get an IP address, but when you manually issues the udhcpc command it worked fine?

If it is truly time that fixes the issue, the problem is MOST LIKELY spanning tree. Even some of the unmanaged switches have standard spanning tree enabled by default. You typically don’t find this in home switch gear. Usually the test is to put a cheap unmanaged (i.e. $20 monoprice) switch in between to test.

What version of FOG are you using?

Are the fog (target) clients on the same subnet as the fog server?

Do you have igmp snooping enabled on all of your network switches. It just needs to be enabled for the vlan(s) where you are going to multicast.

I can say 95% of the multicasting issues are related to infrastructure and not the fog server. But that 5% we will still need to look into.

@Sebastian-Roth Yes it was on the iPXE side. During testing we booted FOS Linux off a usb flash drive and it imaged fine. Well with some clarity, it imaged fine once we added nvme_core.default_ps_max_latency_us=0 to the usb/grub boot parameters. SO that kind of points to ipxe/hardware/uefi firmware that had a conflict with this specific nvme disk.

@Sebastian-Roth I guess I would have to spin up a new FOG server to see what problem we are trying to solve. I know there are people using their fog server for more than just imaging. If the problem is just to keep people from getting a directory listing of the web server root or landing on http://<fog_server_ip> and seeing things we could just put a index.php file in there to redirect to the fog management interface.

@Sebastian-Roth

Unfortunately there is no simple logging you could turn on. You’d need to add you own debug statements in the code to figure out what’s going wrong.

When I worked with Tom on the ldap plugin, I did have some basic messages logged. I know the code has been worked on since then so that debugging code may have been removed.

When we were first testing the mods a few years ago I had it working with the email address. Our focus was on getting the samaccount working with ldap reliably. If I remember right we made the decision to remove any special characters from the uid field because we ran into issues with non-low order ascii characters so Tom created those regex expressions to filter out everything except low order ascii.

One of the things you probably will run into is the UPN address will probably be longer than the field in mysql to hold the user account. I don’t really remember without looking but NT had a 15 character account limit and I bet the database field is pretty close to that. Some UPN names can exceed that length causing a login issue. Beyond the database issue, if the regex expression is updated the UPN name (or email address) should work without issue. You will still need to be mindful that the characters have to be low order ascii because the ldap program doesn’t support double byte characters at all.

@fritoss007 Since the developers haven’t really looked into use email address or upn names for LDAP authentication can you do some research for them. If you could export you AD into something like excel and then create a quick formula to get the length of the upn name (could do with powershell too) and then post what is the longest UPN name (email) address you have in your AD. This would give the developers an idea if 40 characters is good enough or something else is needed.

The partclone speed is a composite speed built on the product of fog server transfer rate + network transfer rate + target computer ingest + target computer (unzipping) + target computer writing to disk.

In fog imaging almost all of the heavy lifting is done by the target computer. For imaging the FOG server does very little, it basically moves the file from its local storage and sends it out the network (and of course oversees the imaging process). The network transfer speeds have an impact, but again its the target computer that does almost all of the work. If you have a slow processor, insufficient RAM, or a rotating hard drive they will have a bigger impact on the imaging process than the FOG server or network.

For a modern computer with an NVMe drive I get about 13GB/min. With a Dell 7010 with a traditional hard drive I get about 5GB/min transfer. All from the same fog server. I would say that 1.4GB/min (23MB/sec) is a bit low.

So for you to see such a large difference I would have to ask what was unique about these systems was it geographic location, type of computer, phase of the moon?

@Sebastian-Roth said in Use fog with Windows Server 2008 R2 DHCP:

Why do you think so?

I would have to grab a nuc to prove it, but I would think it would say something about nbf if it was in uefi mode (having a picture would speak volumes). The dhcp server appears to be configured correctly for uefi systems, so as long as the nuc is on a routable network it should pxe boot.

I realize this thread talks a lot about other things but this post should get you pretty close. https://forums.fogproject.org/topic/14254/high-cpu-usage/10

You need to set the sqlmode parameter without the NO_ZERO_IN_DATE and NO_ZERO_DATE values. Then restart mysql and then rerun the command that should take care of the zero date error.

@Wayne-Workman What has happened is mariadb starting at version 10 (?? I think) added some default values to mysql startup that are causing an issue with some of FOG’s default values (such as 0’s in date fields) I think we need to update the schema to use a invalid, but valid date of something like 1/1/1900 instead of 0/0/0000 as an unset date.

Again its not a problem with the renumber script, but the default startup values used for the sql server that was introduced with the later releases of mariadb.

@JimmyJ0516 Instead of going backwards, lets take you to 1.5.9RC2. That RC version will probably become the next 1.5.9 GA release. There hasn’t been any bug reports against that RC release so far.

If you used the git method to install FOG change to that directory (typ /root/fogproject) and issue the following commands.

git checkout dev-branch
git pull
cd bin
./installfog.sh

Now when 1.5.9 comes out you will want to switch back to the master branch to get 1.5.9.

git checkout master
git pull
... and so on

@sudburr said in FOG 1.5.9-RC2 incompatible with Windows 10 v2004 Partition Structure:

I would say this is the incorrect format with the recovery partition first

Microsoft Windows 10_v1903 64bit (10.0.18362.30)
Partition ### Type Size Offset
Partition 1 Recovery 529 MB 1024 KB
Partition 2 System 99 MB 530 MB
Partition 3 Reserved 16 MB 629 MB
Partition 4 Primary 1023 GB 645 MB

I would say this is a better disk structure in that the uefi boot partition is in the first position. d1p1. But I would not have the recovery partition as the last partition on the disk, if you have a choice on how is created move it ahead of the drive. I would say when we create the master image with MDT with the exception of the recovery partition this is how the disk structure looks.

Microsoft Windows 10_v2004 64bit (10.0.19041.264) aka 20h1
Partition ### Type Size Offset
Partition 1 System 100 MB 1024 KB
Partition 2 Reserved 16 MB 101 MB
Partition 3 Primary 1023 GB 117 MB
Partition 4 Recovery 505 MB 1023 GB

I would almost bet it has nothing to do with the partition location but instead some kind of hokus-pokus MS has done within the partitions themselves (like creating their own filesystem or something). FOG doesn’t really care about the content or location since it only copies blocks of data.

I guess its time that I load 2004 into MDT and spin up a new test golden image to see what is broken.

Either way thank you for letting the developers know that their summer break has now been canceled.

@babouche said in Force bios to PXE boot after task:

Start PXE…
Check media presence…
start pxe over ipv4 on mac: XXXXXXXXXXXX (stuck 30 seconds a this) Maybe it’s because i have radius authentification+dhcp.

This bit is part of your infrastructure. As you suggested it appears your NAC/NAP system is running a bit slow at this point. I think I would focus on understanding why this is slow, especially since during the boot process of the FOS Engine it queries for a DHCP address 3 times (once for PXE ROM, once for iPXE (fog boot menu), and once for the FOS engine). If you are getting a delay each time I can see why you have a slow booting process.

And then the tftp begin (it takes then 20 second to begin the deployment)

This sounds normal from my experience. The iPXE boot manager (program that creates the FOG iPXE menu) is small in size, about 1MB and the FOS engine (the OS that clones the hard drives) is about 28MB in size. These files should transfer really fast. The FOS Engine takes about 15 seconds to boot and start doing things.

@browlry Ah so your recovery partition is the first partition and is marked as primary.

While this is a philosophical question, but is a recovery partition even necessary (today) if you have an imaging solution in place? It talks less time to image with FOG than it does to even begin the recovery process. Its very rare that a recovery partition is the very first partition on the disk, even M$ recommends the uefi boot partition to be disk 1 partition 1 position. I’m not saying its wrong only abnormal.

@browlry That first partition is suspect. Normally that first partition on the disk is the efi boot partition. Are you using some kind of third party disk encryption system (not bitlocker)? It could also be an OEM repair partition too, but its surely suspect.

Its possible since its not an efi partition the fog code is getting confused. The rest of the disk structure looks OK.

@browlry In general I can say that FOG should only recreate the disk partitions as they were on the source disk. So your situation is a bit unique.

Will you provide the output of this command cat d1.partitions this must be executed on the FOG host server in the image directory. On my FOG server, I can’t “visually” tell the difference between a gpt and mbr image (other than the content of the d1.partitions and the number of partitions). So the FOS engine must detect the image format via some other methods.

I can tell you from my experience both MBR and GPT images deploy correctly and we NEVER have to mess with the disks to get them to boot. My intuition kind of tells me there may be something a bit abnormal with your master image that is confusing the FOS engine when it either captures the image or as its deploying. We’ll have to get the fog developers to take a look at the output of the d1.partitions file to see if anything jumps out at them.

@Sebastian-Roth said in Snapin problem on fog 1.5.9-RC1 and 1.5.9-RC2:

fopen(ftp://

This is what confused me, does the client access the snapins over ftp protocol? I still think its on the php-fpm side though. Lets see if bumping up the number of clients fixes the error. I do have some doubt that the max number of clients is the issue because there are only 30 systems at each site. At 100 systems I might see an issue.

I guess the OP should check to ensure this file /opt/fog/snapins/BMS_Genveje.ps1 exists and has the right permissions so that the fogproject user can read it.