Best posts made by george1421

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

@symrex On the windows side you need to drop the firewall because tftp works much like ftp in that there is a command channel from the remote to the server and then a data channel from the server back to the remote. Both links are needed to get the file.

There is not quite enough info in your OP.

1. Is the computer a bios or uefi based?
2. Is your dhcp server configured for static or dynamic boot file names?
3. What is your dhcp server? (mfg and model)
4. Is it only this specific computer that has booting issues or do you have others that have similar failures?
5. It would be really handy to know what it flashed on the screen after it gave up with ipv4. Possibly video it with a mobile phone in slow video mode?
6. Is the firmware (bios) up to date on that target computer?

@symrex said in TFTP port is closed is it normal?:

Next-Server: xxx.xxx.xxx.xxx
Bootfile: undionly.kpxe
Option 66: yyy.yyy.yyy.yyy
Option 67: boot\x86\wdsnbp.com

It looks like someone setup a Windows Deployment server/SCCM server.

Just for clarity the next server and dhcp option need to be the same (exactly) the same goes for boot file and option 67.

The first part is in the ethernet header, that is for bootp the dhcp options are for dhcp. Some clients use bootp some use dhcp so they both need to be set correctly.

@berndttoast23 In the fog installer directory there should be a log directory ./fogproject/bin/error_logs. There will be a fog_error-xxxxx.log Where xxxxx will match the version of FOG you are installing. That should give us a bit more detail on what is wrong.

I don’t have an answer for you directly, but I can tell you how FOG work and how to reverse engineer a few things.

When a computer pxe boots it downloads the iPXE boot loader that has been customized by the FOG Developers. This will be ipxe.efi or undionly.kpxe (typically). Inside that boot loader the FOG Developers placed an initial iPXE script. That script calls a script on the FOG server called default.ipxe. That script then chains into FOG via the boot.php code. If you were to write your own code for the default.ipxe file (its just a text file) that displayed some background image and that had a count down timer. If no key is pressed then it would just boot from the hard drive. If a key was pressed then you could chain to the default FOG iPXE menu by calling the boot.php file directly.

So you will want to review the file /tftpboot/default.ipxe just know when you update fog it will overwrite this file so keep a backup if you alter it.

The next bit of hackery is seeing the text behind the FOG iPXE menu (I would use this as the framework for your own custom default.ipxe file). If you go to a web browser and key in http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 that will display the text behind the FOG iPXE menu. In there its really a program that runs based on the iPXE programming language. You will see how menu entries work as well as the default menu selection as well as how the backgound image is called (hint you don’t have to use the fog background image for your custom boot menu).