@alexnoel2 I don’t think we are too far apart. So let me explain.

If you are using the same network connection, same computer and the only thing you are changing is putting the computer into one more or another, then we’ve ruled out a bunch of possibilities. Its either the computer, the dhcp server configuration, or ipxe.efi is missing on the fog server (for some reason).

I understand these computers in question only have uefi mode. So do you have a different model that supports both modes for testing? We need to test everything the same except the computer mode bios/uefi because you said bios mode works perfectly.

@alexnoel2 Ok so let me ask again because I’m not absolute about your answer.

1. You can take the same computer and in bios mode does it boot into the iPXE menu?

2. If you switch that same computer into uefi mode does it boot into the iPXE menu?

We are trying to find the exact point of failure. If the answer is yes in bios mode and no in uefi mode then lets focus on uefi boot file.

For the uefi boot file, if you have a computer on the same network install the tftp client in windows, you will need to temporary drop the windows firewall on the test computer, but then use tftp to get ipxe.efi from the fog server. We are only concerned that it download the file. We don’t need it only to download the file.

If the tftp works then we need to find out exactly what the network admin did to make this work.

@alexnoel2 said in PXE-E99: Unexpected Network Error:

We were able to deploy to laptops with legacy bios from the same location

So if you take (for a test) switch one of these laptops from bios to uefi mode (on the same network jack) can you get into the iPXE menu? We don’t need to image them only get into the iPXE menu.

@alexnoel2 Well it could be a few things and nothing its hard to explain because there is a lot of exceptions. You want to look in the OFFER in both the ethernet header there is a next-server and boot-file that should point to the ip address of fog server and ipxe.efi file. Also dhcp option 66 and 67 should be the same.

Do you see the tftp query from the target computer to the FOG server asking for the ipxe.efi file?

You said something earlier that the network engineer did something to make this work. What did the engineer touch? Because this should have just worked out of the box.

Just to be clear if you put a bios computer on this network it will pxe boot into the iPXE menu just fine? The only thing that is changing is bios to uefi? On the bios computer does it also support uefi mode? So on the same computer if you change it from bios to uefi mode does it pxe boot into the iPXE menu?

Understand I’m coming cold into the problem not knowing your environment or what might have been changed. So I have to give a lot of guesses until we narrow in on where the problem is.

@alexnoel2 And when you installed FOG you select the right interface to bind the dhcp server too? I assume from your post that FOG was working fine on bios but uefi not so good?

If you are using the FOG server for dhcp services, then it should automatically support both bios and uefi computers. There should be nothing you need to do to make it pxe boot into the iPXE menu.

EDIT: sorry i missed you have it virtualized and the fog server might not have 2 interfaces but the host server does.

@alexnoel2 Since the FOG server and target computer are on the same subnet I would use tcpdump on the fog server to see what communication is going on between the dhcp, client, and fog server. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

You can review the captured pcap with wireshark. Since you are not able to provide the file you will need to look through it to see what is failing. You should see the DISCOVER, OFFER, REQUEST, ACK process of dhcp and right after that you should see the target computer connect to the FOG server first to confirm the file size and second to download the file. I suspect this is where its failing.

Just out of curiosity, what device is your dhcp server (mfg and model)?

@matthew11 Totally out of scope question for FOG. FOG hasn’t use syslinux for pxe booting in over 10 years. FOG uses iPXE for a pxe boot loader. There are parallels between the two, but they are not the same.

With that said, if you have the default config file for syslinux it might be possible to translate that into iPXE syntax, but I would have to see the changes needed to that file.

@sebastian-roth I have FOG server(s) running on proxmox on my home lab. If you use the full VM mode there is nothing you have to do FOG just works, If you use the lxc containers… I don’t know.

@nil Just looking at the exports line the fsid=0 and fsid=1 stanza missing from each line. Did you hand edit the exports file?

Also you can run the showmount -e 127.0.0.1 to show the nfs exports.

Also make sure the debian firewall is disabled.

@seppim I have no idea since I did not test loading it with memdisk. I did not look but I suspect the iso image may be larger than 2GB (thinking memdisk is a 32 bit application and not a 64 bit app. But this is only a guess). I know when I was testing the boot.wim file on the iso was 1.3GB in size.
I was able to get it to boot in uefi mode here: https://forums.fogproject.org/post/140212 but in bios mode it complains about needing bootmgr.exe in the iso image.

@devrick I would move the call to funcs to the top just below the call to bash.

I’ll have a little time in about 30 minutes to fire up my fog server and debug this a bit. I think you are very close though.

@george1421 Thinking about it a bit more when you see the “Running my script” text in your postinstall script hit ctrl-c and drop to the FOS Linux command prompt then just issue set | more or set | grep other to see the environment variables. If the other tags are not there then you need to use the wget into hinfo.txt and stat it, then the variables will be set.

@devrick If you stop the script where/when it displays “Running my script” those variables should have been set. Now its been several years so I might be not thinking right.

But this code should pull those variables.

if [[ ! -z $mac ]]; then
    wget -q -O /tmp/hinfo.txt "http://${web}service/hostinfo.php?mac=$mac"
    if [[ -f /tmp/hinfo.txt ]]; then
        . /tmp/hinfo.txt
    fi
fi

What this does is makes a call to the FOG server using the network adapters mac address. The returned file contains the code to set the environment variables into hinfo.txt Then it stats hinfo.txt to load the variables into bash. That hinfo.txt file should contain the other1 tag.

You could test this from the FOS Linux command prompt by just issuing the wget command replacing the variable with real values. Then look through the hinfo.txt file to make sure it has the variables you need.

@devrick Ok lets start a crash course in FOG debugging.

First of all the error message with a \r I think is telling. Did you use a windows computer at any time when you created or edited these scripts? Of so that is why things are a bit crazy. Windows Notepad add a carriage return \r to the end of every line. This drives linux crazy. You will need to find and load the dos2unix for your fog server’s distro and scrub your post install bash files. If you want to edit these files on a windows computer use notepad++ and your life will be much easier.

Now to the debugging steps.

Using vi or nano add this just below the #!/bin/bash in fog.custominstall

echo "Running my script"
debugPause

What this will do is display “Running my script” during image deployment then wait. When its waiting hit ctrl-c to exit out of the script. This will toss you back to the FOS Linux command prompt.

Now how to get there.
If you have any open image deployment tasks for this specific target computer cancel them .

Schedule a new deployment task for this target computer, but before you hit the schedule task button, tick the debug checkbox then schedule the task.

PXE boot the target computer. After a few screens of text you will be dropped to the fos linux command prompt.

Key in ip a s and get the IP address of the target computer
Now give root a password with passwd make it something simple like hello. This password will be reset on the next reboot so no worries. Now you have the IP address and the root password set you can use Putty or SSH to connect to this target computer remotely. This will help with debugging, copying and pasting.

Now that you have connected remotely, or working right from the target computer’s console lets start the debugging process. Key in fog at the fos linux command prompt. This will start the imaging process. The system will pause at each debugPause statements in the deployment process. You will need to hit enter to move to the next step.

After you see the partclone screens close out the next step is your post install script. When you see “Running my script” you can hit ctrl-c and exit the script. Your post install scripts will be in /images/postinstall directory on the target computer. Only vi is loaded on the target computer, but you can also edit the scripts via the fog server so you can use vi there or nano. If you want to test the deployment scripts again (without needing to reboot) just key in fog at the FOS Linux command prompt and it will deploy again without needed to touch the FOG WebUI. You can do this over and over again until the target computer reaches the end of the deployment task and tells the FOG server its done. Then the task will be removed from the queue.

My bet is that once you get the extra carrage

@julio This is a new error for me. If the destination is failing to deploy I think there should be a different error. But I give you steps to debug this.

1. Schedule another deploy task to this computer, but before you press the “schedule task” button, select the “debug” check box then submit the task.
2. PXE boot the target computer. The computer will start into the imaging steps, but this time you will see many pages of text that you will clear by pressing the enter key. At the end of the text you will then be at the “FOS Linux” command prompt.

At the “FOS Linux” command prompt key in lsblk. This will show you if FOS Linux can see the local hard drive.

The next step you will start the imaging process. In debug mode the imaging process will pause at certain steps. This is done so you can read errors during imaging. I am guessing since your deployment is failing, there is an error message that is getting overlooked. I might think there will be an error message on the partclone screens (blue screen with text). To start the imaging process at the FOS Linux command screen key in fog and press enter. You will need to press the enter key at each pause to go to the next steps.

@devrick That is a copy/paste artifact (but good catch) Change $devpath to this ${devtag} and you are good to go.

If you are not familiar with bash variables.
$devtag and ${devtag} are usually equivalent. Its just that ${devtag} describes exactly that its a variable and sometimes bash gets confused with just $devtag thinking its something other than a variable so its best to enclose the variable name in curly braces.

@devrick said in Updating a registry file after deployment:

/usr/share/fog/lib/funcs.sh

To extend what Tom said…

These post install scripts are run from the context of the target computer running FOS Linux. That file contains a swiss army knife of useful scripts that is needed for both imaging as well as post install script functions. That referenced file is on the virtual hard drive that is downloaded to the target computer during the pxe booting process.

When you get to the point where you want to start debugging your post install script we can give you some additional guidance to make debugging a lot easier. But I don’t want to flood this thread with useless stuff until you are ready.

@julio said in Problème de brouillard:

si j’aimerais avoir le parefeu active que pourais je faire pour cela???

You need to research ubuntu “enable firewall nfs” Understand that FOG uses NFSv3 right now. So you will need to open all of the ports needed to make NFSv3 to work with the firewall.

@julio said in Problème de brouillard:

ok je viens de desactiver mon parefeu. je le fais pour mon travail de fin d’etude.

Yes this is the quickest fix. You can leave firewall with NFS but it needs a lot of configuration. Must FOG admins just turn off firewall and image happy.

@julio Ok now we find the problem.

Does your company require the firewall to be turned on? If no, then turn off with the command I give you last.

If you must keep firewall on then you will need to add more firewall rules to allow NFS to communicate with FOG server.