@cammykool I would search for bonding and your linux distro. Bonding or teaming (depends on which method you use) is setup at the OS level. You will also need to get with your infrastructure folks to setup the switch the fog server’s plugged into for bonding. I would suggest LACP also called 802.1ad. Both the switch and the server needs to be configured for the same bonding type. When you setup bonding on the linux side, it will create a new network adapter typically called bond0. That virtual network adapter will then talk to its slave interfaces (the real physical nics). You will apply the IP address to the bonding nic and not the physical nics. The bonding driver will manage the physical interfaces once its setup. When you configure FOG you will tell it to use bond0 (or what ever the bonding interface name that is created). Once you have bonding setup and WORKING at the linux level then you can forget about it and install FOG. Don’t install FOG without or before bonding setup.

@tneuber The unattend.xml thing, is a windows thing and not a fog thing.

For example I don’t use the FOG client in my environment but I use the unattend.xml file to configure the target computer and connect it to AD. Here is an example of a sanitized version of my unattend.xml file: https://forums.fogproject.org/topic/11920/windows-10-1803-sysprep-problem/7

@marted said in Remove press F12 for network boot (PXE):

No need to press F12 if I stop all computers and send a signal with the image wake-up on lan

Just be mindful that windows 10 doesn’t play nice all of the time with WOL. Many have reported that wol doesn’t work if the computer was in windows and is either put to sleep or shutdown from inside windows. WOL does work if the computer is unplugged and then pugged in, where windows wouldn’t leave its bits hanging around and breaking the wol process.

@jack_chapman2020 Error is: Logon failure: unknown username or bad password, code = 1326

Try DOMAIN\username and simply username - we have seen one or the other working. Though we have not found the time to figure out in which situation one works or the other.

@lordbob75 Good to hear you got this fixed! Though the error message for me didn’t point to be the IPs to be the issue. But well.

Would you be interested to get in touch with the person who created the Docker image to see if he/she’d be keen to update the FOG version?

Thanks!! I will take a look

@Sebastian-Roth
Yes on proxmox

@wreckignize The rest of the setup should be the same, just how it gets installed is different.

@execcr said in Fog and pxe boot Esxi 6.7u3 installer on HPE Server can't pass k.b00 module:

i just spin up a VM with UEFI bios and E1000E adapater and tried to deploy esxi 6.7u3 to that vm and get past the loading modules stage and i can actually install esxi here.

From what you have told us so far I think this might be some problem with iPXE booting in the other VM. Can you please give us more details on what setting(s) is/are different between the one that works and the one that doesn’t properly load.

@vic60400 Would be interesting to hear if (and how) you were able to exchange the certificates. Other users might find it very helpful.

@george1421
Thank you so much !
It works well !
Have a good day.

Thanks all. You are right. LDAP uses plain text password. I had ‘&’ symbol in the password and that breaks it. I set up a test RHEL server and was able to make it work by removing ‘&’ symbol. My “controlled” server however is till not working. No error in /var/log/php-fpm/www-error.log. Apache detected when I tried to login. Re-installing -php-ldap but no go. Does anyone know how to debug it? Thanks!

@george1421 said in Where are the general iPXE settings?:

and that should pull the file from the tftpboot directory. But then you will need to have a mac address file for each system. But then what happens if you don’t have a mac address file the boot fails.

in this case, you could just end the chain command with || and it would try the next available command, which can be booting to the fog server

@lebrun78 said in Need advice for network configuration:

Which architecture do you recommend?

That depends on the network components you have. What kind of router do you have? If possible I’d put the 500 educational hosts and the FOG server on the same switch/branch of your network. Don’t run it through your backbone if you can avoid it. Leaning towards setup one (above picture).

On the other hand I am not sure I understand why you’d make things more complicated by running the FOG server dual homed. Why not just have the FOG server in the educational hosts network segment and allow HTTP/HTTPS web access from the admin PCs to the FOG server across your router.

@Sebastian-Roth

ok

@Sebastian-Roth said in FOG client with dual boot image:

@EduardoTSeoane Ok, seems like I got a bit confused about the custom install path. Now I got it. Opened an issue on github for this so we won’t loose it: https://github.com/FOGProject/fog-client/issues/117

Hehe, that has name, is too much work…, I was thinking that it was a problem with our Windows Customizations, I had no time to investigate it.

Typically a post install script relies on the image being on the computer because the post install script would interact with the image once its downloaded to the disk.

With that said I can give you some tips to make debugging a bit easier.

Schedule your deployment task, but before you hit the submit button tick the debug checkbox. PXE boot the target computer. After a few screens of text that needs to be cleared with the enter key you will be dropped to a linux command prompt.
These next to steps are optional Get the IP address of the target computer using ip addr show Set root’s password with passwd give it a simple password like hello. Don’t worry it will be reset the system is rebooted. Now use putty and connect to the target computer using the information from steps 3 and 4. Using putty you will be able to cut/copy/paste a bit easier than using the FOS Linux console. But these 3 steps are up to you
The rest of the steps work both from the putty shell as well as the console shell. Start the deployment process from the command prompt by keying in fog. You will now single step through the imaging process pressing enter at the each debugPause command. You can insert the debugPause command into your post install script to stop the deployment at critical points. Pressing enter will continue the script until the next debugPause breakpoint.

Hints:

Add liberal echo commands to indicate the start, execution of critical points and exit of your post install script. If something goes wrong, pressing ctrl-c will exit out of the deployment script at the point where you hit ctrl-c. If you are linux savvy you can navigate to where the postinstall script is and rerun just that script after you fix what needs fixing. (I don’t know the path off the top of my head, sorry) You can start the deployment process over again without needing to reboot by just keying in fog again at the command prompt.

If you are interacting with windows, I have some post install scripts with examplesin the tutorial forum. While they are windows focused they should show you some trick you could implement in your scripts.

Personally I would install a second nic on the fog server. Have a dedicated imaging network and then a business network management interface. This is a normal configuration for FOG. Your FOG server will supply dhcp for the imaging network only.

You can change the IP address after FOG is install, but its a bit of a pain. All you need to install FOG cleanly with dual network interfaces is to know the interface name of the imaging network and to have your business network nic to be able to get to the internet directly or via a proxy server.

@Jack252 Do you have different IP address subnet in the isolated network??

You cannot simply change to a different subnet. There are a couple of things you need to do: https://wiki.fogproject.org/wiki/index.php/Change_FOG_Server_IP_Address

I’m not fully sure how to implement proper login checking. This is a feature that is kind of in flux. When initially coding the ipxe stuff, there was a lot of ties in to protect things that were “natural” to the main menu. However, this made making password protected items less possible because there isn’t a nice easy api in ipxe to call back and check “login” against a url.

The current password protected items have 2 different elements. The first is to pass the login stuff to the second element, and that second element cross checks login capability and passes through if all passes properly. It’s because of this double step that currently custom pxe items can’t just have a password protection nicely integrated. It would need a secondary element tied in to the main boot code. This could be done with hooks I’m sure, but it’s still fairly complicated. The simplest methods would be to do as you did (use ESC to force all menu items to be login protected) or use the advanced menu with login enabled.