There is a bug in FOG 1.4.4 that needs to be patched with a hot fix. The hot fix has been applied to the dev branch of 1.5.0, but its not in 1.4.4.

Here is the process to manually apply the patch:

1.Open a linux command prompt on your FOG server.
2. Key in the following command:
sudo wget -O /var/www/fog/lib/fog/plugin.class.php https://raw.githubusercontent.com/FOGProject/fogproject/6717f382177e714c1bd22eb11627133cfd4e0ebe/packages/web/lib/fog/plugin.class.php
3. Remove the plugin
4. Reinstall the plugin
5. Add in your plugin settings and save

@tom OK watching your video frame by frame (well almost). I see your fog server is on 192.168.2.196 but your pxe client computer and dhcp server are on 10.141.32.x/24 Is this expected?

Unfortunately the video doesn’t show me where its getting bzImage from (just off the top of the screen)

Since you have isolation between your staff network and your student network, then you can configure something called a split horizon DNS.

Now for the questions:

1. Can we confirm that each network has its own DNS server?
2. Is there any type of routing between the staff network and the student’s network?

@aziraphale OK then we might have a path forward. Understand I haven’t had to do this before so there may be something that will go sideways on us.

But the concept with split horizon dns is to create an A record entry in each dns server. On the dns server on the staff network you will create an A record fogserver.domain.com (or whatever name you choose) that points to the nic on the staff network. You will do the same for the students network. That A record for fogserver.domain.com will point to the nic on the students network. That way a client on either network will always resolve to an interface on the right network.

Once that is setup now you need to get in and tweak the FOG configuraiton. Anywhere in the FOG Settings that refer to an IP address you need to replace it with fogserver.domain.com. Also in the storage node configuration for your FOG server, replace the fog server IP address with its fqdn name.

Now there is one other place you will need to edit by hand. In /tftpboot/default.ipxe exchange the fog server IP address with the fqdn name.

Understand this setup is not supported by the FOG Project and the next time you upgrade your fog installation, the installer may overwrite certain configurations for you. Most will stay the way you put them.

Now the only gotcha here is that there are some pxe boot roms that that are pretty dumb and will not translate the fqdn name to an ip address because they ignore DNS resolution. You are going to have to try it to see how well this setup works for you. It may be just as easy to setup a second fog server on the students network so you don’t have to deal with this complexity.

Is the source image LVM based? AFAIK you can’t resize (or more correctly fog can’t) resize a disk that has been created as LVM. FOG should have copied it as raw partitions. You can test this by deploying to a disk bigger than the source disk. Does the new target use the entire disk or is it constrained to the same allications as the source disk?

@x23piracy we can then close the issue?

Can we get one of you guys to install the RC9 release of FOG 1.5.0 to see if the issue has already been addressed? The process is this to update to an RC release.

If you don’t have the local install files, use git to pull them down using this process.

sudo -i
git clone https://github.com/FOGProject/fogproject.git /opt/fogproject
cd /opt/fogproject
git checkout dev-branch
cd bin
./installfog.sh

If you already have the git install files on your fog server then do this

sudo -i
cd <where_ever_your_install_files_are>
git checkout dev-branch
cd bin
./installfog.sh

Now when its time to switch to the stable branch once fog 1.5.0 stable has been released you will do this:

sudo -i
cd <where_ever_your_install_files_are>
git checkout master
cd bin
./installfog.sh

Telling git to checkout the dev-branch or master is the key to switching to an RC release.

I must warn you that upgrading to 1.5.0 is a one way street. If you upgrade you can't roll back to 1.4.4 because of the gui changes. So consider this well. 1.5.0 RC9 is stable and works well. You shouldn't have any concerns about updating.

@julienl Ok that is what I thought you meant.

First let me say I’m not in education or have dealt with education licensing so I may be wrong. But as far as I can find you can’t activate the Win10 Education with OEM keys for Win10 Pro. You need to use a Win 10 Education MAK or KMS key.

When I look at my company’s MS Volume license site, there are keys that are specific to Win10 Pro Education.

Now I have to ask, can you manually activate Win10 Pro Education by keying in the OEM key?

Microsoft gives you details on how to activate or switch between Win10 Pro and Win10 Pro Edu: https://docs.microsoft.com/en-us/education/windows/switch-to-pro-education

@brad-schumann said in Image upload & deploy taking a long time:

@george1421 In Image Management it shows 465.30 under “Image size: on Client”.

It almost sounds like fog is copying the file as RAW for some reason. Can you confirm from inside windows that the disk contains only a little percentage of the entire size?

@abra4242 You were able to register the machine using FOG pxe booting process without issue?

What version of fog are you using?

At what point does the target computer reboot? FOS [customized linux that runs on the target computer] should say something is wrong and will reboot in 1 minute if it detects an error. A clear picture of this error taken with a mobile will help diagnose the issue.

What is your target computer (mfg and model)?

Is your target computer in uefi mode or bios (legacy) mode?

What exactly are you sending out for dhcp options 66 and 67?

@abra4242 We need to change a few things in your environment.

1. Your computer is a thinkpad T520. That unit can have 2 personalities. This is configured in the firmware. BUT since you have windows 7 installed on that computer, its probably in BIOS (legacy mode). This is important because you need to tell it which iPXE file to load.
2. DHCP Option 66 must be the IP address of your fog server. (which you have)
3. DHCP Option 66 must be undionly.kpxe for BIOS (legacy) mode computers and ipxe.efi for UEFI mode computers. If you get the wrong one the FOG iPXE menu will not be displayed.

Your statement

When PXE Boot is attempted, it finds everything but times out at TFTP then exits the intel boot agent.

Is happening because you have the wrong boot file set in dhcp option 67. pxelinux.0 is not used any more with fog for quite a long time.

@caw001 It shouldn’t matter.

I’m pretty sure your situation isn’t unique (obviously because of this thread). We need to understand why some systems expand correctly and some don’t. I’ve got a meeting right now, but it may be useful to compare what you have in the following files.

d1.minimum.partitions
d1.fixed_size_partitions
d1.partitions

From the image directory on the fog server. There has to be something unique here we can feed to the developers.

@clickwir said in Don't want host registration.:

This seems needlessly complicated. Is there a setting to fix this?

Unfortunately that is how the forum works. You have the original post and then the newest responses. I know its different than most other forums or blogs, but you will also understand that the latest posts are at the top and you don’t have to scroll all the way to the bottom so see answers to previous questions. It took me quite a while to get use to the format coming from Spiceworks.

Do you by chance use the linux user fog for system maintenance or have change the linux user fog’s password. This error message is typically created when someone uses or changes the linux fog service account.

I agree driver injection isn’t that hard even with non-Dell systems as long as you can get the driver packs in inf format and not as self install .exe files.

Since you are working as a hardware refurbisher, you are probably working just with the Deploy menu in FOG. Without modifying FOG, having a great naming convention for the images is important. With iPXE there isn’t a very easy way to add submenus.

@Quazz or @x23piracy Did one of you guys have a complex iPXE submenu structure. I seem to recall someone on the forums built a complex submenu design using the custom iPXE menus option in FOG.

@lemeunier What I’m referring to specifically is the FOG server that you are capturing the image to. There is a linux account called fog where the password seems to be out of sync with what FOG thinks it should be.

Here is the process to get everything back in alignment.

1. Review the hidden file /opt/fog/.fogsettings on the fog server that is generating the invalid login.
2. In that file will be a setting password=“something”. You need to note and document this password. (Hint: if you connect to your fog server with putty and copy that password out using putty your life will be much easier).
3. Now from the linux command prompt set the fog user’s password to the value found in the .fogsettings file with passwd fog and then paste in the password you collected in step 2.
4. In the FOG Webgui, goto the FOG Settings and then tftp server settings. Ensure the password defined there matches what you collected in step 2.
5. Still in the web gui go to the storage node configuration for that server. Ensure the management password matches what you collected in step 2.
6. Now from a windows computer make sure you can log into the FOG server using a FTP client. User the user ID of fog and the password you collected in step 2.
7. If successful now to the last bit of cleanup. Rerun the fog installer ./installfog.sh script that will clean up the remaining bits and put you back in a happy place.

I have worked with this area of pxe booting on some pretty tough problems. So I have a few things I can tell you.

First for your dnsmasq if you can install / or have installed dnsmasq 2.76 or 2.77 your configuration will be a bit easier. I would first focus on getting on this release. I have not personally done this with Debian but I have a tutorial on how to compile dnsmasq 2.76 and I know it works on Ubuntu. https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support

Before you go through all of that open a command window on your fog server (or dnsmasq server) and key in the following command dnsmasq -v to get the dnsmasq version. If its less than 2.76 then consider compiling an update using my instructions.

If you are on 2.76 or later consider using my ltsp.conf from this end of this post [ https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support/6 ]. I can say for absolute this configuration works perfectly. Make sure you change the <fog_server_IP> to the IP address of your fog server. Don’t forget to restart dnsmasq after you make a change to the config file. Also ensure that when you reboot your fog server that dnsmasq restarts too.

I have seen what Sebastian said about home routers. They do send their IP address as the next server but no boot file. That isn’t very helpful if you want to pxe boot at home. So far I’ve been able to use dnsmasq to over ride home dhcp setups of all kinds. In my home right now my home router does exactly what we are talking about, sends itself as the next server with no boot file name. I’m running FOG and dnsmasq on a Raspberry Pi3 server and I can pxe boot both uefi and bios systems no problem. If we take my config file and make a small tweak to it, we should be able to override even a valid dhcp server sending out a proper next server and boot file.

The other thing that Sebastian mentioned was to capture the network traffic using wireshark or tcpdump. Since the pxe booting process needs dhcp and dhcp is communicated via broadcast messages we can have any computer on the same subnet eavesdrop at least on the dhcp process to understand what is going on. There is no need for a mirror port. If you use tcpdump running on the FOG server you can view the entire pxe booting process, even after the target computer switches over to unicast communication since it is talking directly to the fog server at that point. I do have a tutorial on that too: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Steps to switch to working branch.

cd <directory where git-repo is stored>
sudo git checkout working
sudo git pull
cd bin
sudo ./installfog.sh

@wayne-workman ref: https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin

@robtitian16 Tutorial most appropriately names: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Post the pcap to a google drive/dropbox/etc and then share the link, either in a forum or IM me the link and that will tell us what is going on. It really helps to have the fog server, dhcp server, and pxe booting client on the same vlan to see the entire conversation. If that’s not possible, you can use wireshark on a notebook on the same vlan as the pxe target computer to capture at least the dhcp process. That is where the process is failing.