@willingmost7 Since you are using grub, I assume your computer is in bios mode. Doesn’t SANBOOT work as expected? The grub for dos implementation in FOG is a hold over from long ago.

Might you need to reinstall SmartRecovery again to resetup windows since the windows upgrade basically reinstalled windows all over again. It might have broken the chain in booting.

This is not specifically a FOG thing because from what I see grub is working as expected. The grub_first_hdd is booting the hard drive from sector 0 block 0 where SmartRecovery lives. But SmartRecovery is not chaining to windows after it does its recovery. The grub_first_found_windows, is looking at all of the partitions to find the windows partition and then booting into windows (bypassing the sector 0 block 0 startup code). I can understand why its working as you outlined, its just not as you need.

Is your version of SmartRecovery compatible with the version of Windows you just upgraded to?

@stu Deploy over the top. FOG will destroy previous image when new image is downloaded.

@eruthon said in EFI EXIT type chainloading failed:

But if I understand correctly, wouldn’t editing only the original refind.conf file by adding Debian option solve the problem, too?

I guess I have 2 points here.

1. We created a second exit mode for refind in case the settings you have in the second refind conflict with efi exit booting for other hardware. If what you have in this second refind.conf file is acceptable for all of your computers on your campus then these edits are unnecessary. I didn’t know to what extent you would need to adjust the original refind.conf file (possibly we should have started there and then decided to go the hack path).
2. The FOG programmers have to keep the configuration generic so that it works for the largest population of hardware. Most don’t want an additional menu after exiting from FOG. I personally would like to see a few extra UEFI exit modes included in the FOG base so for unique hardware this process you did could be used by picking an alternate refind.conf file.

If updating the default refind.conf works for you and its good on all of your hardware, then just update the global UEFI exit mode in the FOG Configuration->FOG Settings panel.

@eruthon The system is working as designed but not like how you want it. I do have a few ideas to get to where you need. Its going to take a little code hacking but the changes are not significant.

rEFInd should probably do what you need to point to grub.efi refind has a config file on the fog server that can be used to tweak how refind goes about finding the bootstrap file you want. The issue is with the default config file for refind its an all or nothing situation. I assume you might have other EFI systems that you would want to boot normal, but specific systems where you want to boot into the grub menu and not directly into windows (default action for how refind works). To do this we need to create a new refind.conf file with the settings we need to locate the grub.efi file, but leave the original one in place so the other efi systems boot normally.

To give us a bit more flexibility we are going to modify just a few lines of code in the fog programming. Understand the next time FOG is upgraded you will loose these edits.

On the fog server here are the steps to make a few adjustments. I use vi as my default editor (because I’m crazy) you can use whatever editor you want.

cd /var/www/html/fog
vi lib/fog/bootmenu.class.php

Around line 131 you will see this section of code

         $refind = sprintf(
            'imgfetch ${boot-url}/service/ipxe/refind.conf%s'
            . 'chain -ar ${boot-url}/service/ipxe/refind_x64.efi',
            "\n"
         );

Copy it and paste it just below as shown here

         $refind = sprintf(
            'imgfetch ${boot-url}/service/ipxe/refind.conf%s'
            . 'chain -ar ${boot-url}/service/ipxe/refind_x64.efi',
            "\n"
         );
         $refindx2 = sprintf(
             'imgfetch ${boot-url}/service/ipxe/refindx2.conf%s'
             . 'chain -ar ${boot-url}/service/ipxe/refind_x64.efi',
             "\n"
         );

On the inserted code change $refind = sprintf( to $refindx2 = sprintf(

Around or after line 165 you will see this section of code. Insert 'refind_efix2' => $refindx2, just after 'refind_efi' => $refind, as below

         self::$_exitTypes = array(
             'sanboot' => $sanboot,
             'grub' => $grub['basic'],
             'grub_first_hdd' => $grub['basic'],
             'grub_first_cdrom' => $grub['1cd'],
             'grub_first_found_windows' => $grub['1fw'],
             'refind_efi' => $refind,
             'refind_efix2' => $refindx2,
             'exit' => 'exit',
         );

Save and exit this file.

Now edit this file

vi lib/fog/service.class.php

Around line 207 you will see this code. Insert 'refind_efix2', after 'refind_efi', as in the code below

         $types = array(
             'sanboot',
             'grub',
             'grub_first_hdd',
             'grub_first_cdrom',
             'grub_first_found_windows',
             'refind_efi',
             'refind_efix2',
             'exit',
         );

What we’ve just done is added a new exit mode to FOG.

Now we just need to clone the original FOG refind.conf file.

cd service/ipxe/

cp refind.conf refindx2.conf 

Now you can edit the refindx2,conf file to make it look exactly where you grub boot efi boot strap is found. You can also exclude specific boot strap files (like windows).

Finally in the FOG UI change the EFI exit mode for a test computer in the host definition to REFIND_EFIX2

This is a bit of an advanced subject, but if you are loading grub to dual boot windows and linux you should have the skills needed for this specific hack.

@robertkwild If you can access the file via a web browser then you should be pretty confident that the centos linux kernel can get it when its time. As for directory browsing of the apache docroot that is turned off. The redirect asking for no specific file and then being redirected to the fog web ui is by design. You would need to do some changing in the web configuration if you wanted to do that. I would advise against changing the web configuration in apache because it may stop fog from operating.

@mperriello That code looks from a very old post. There has been an improved post download script here: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

I have not tried the post install script on 20h1 or 20h2 yet but this updated code should find the proper partition for windows.

@robertkwild Again I would confirm if you can download the config file via a browser first. If you can and you are on the same subnet as the pxe booting computer then the problem is elsewhere. I see you’ve taken the minimalist approach to the kernel args. If that’s kind of working for you, I think I might just tack a few on for good measure since some kernels get cranky without the initrd line.

Using your ipxe menu config.

kernel tftp://${fog-ip}/os/centos/7/vmlinuz initrd=initrd.img ip=dhcp ks=http://${fog-ip}/listing/ks.cfg
initrd tftp://${fog-ip}/os/centos/7/initrd.img
boot || goto MENU

And since we don’t know if it can’t pull the config file because of the http server or the client lets add in ip=dhcp for good measure.

FWIW imgargs command should do the same thing as appending the values after the kernel call, but I’ve seen some kernels not accept the imgargs line but take the kernel parameters the way you have presented them.

EDIT: I just noticed the certificate error. Your fog server is running configured under https:// but your curl call is using http:// This might also cause the error. Its not clear if all you need to do is change the kernel call to the ks file to https or have to do something different because fog is using a privately created certificate for https.

@alomarh on the fog linux server console run this command df -h to see if you are out of disk space on your root volume. Post the results of that command here.

@nasmod OK we have a bit of confusion in your post. We actually have 2 linux machines in this picture. The first is the FOG server.
The second is FOS Linux running on the target computer. The target computer gets its network settings from YOUR network not the FOG server. So its IP address is assigned by the DHCP server. Now if FOG is your dhcp server for this target computer we can talk. If its your enterprise dhcp server doing this then you need to talk to your enterprise group.

The order the dns entries are added are also part of the dhcp server settings. FOS Linux is only adding them in the order they are defined in your dhcp server.

I don’t want you to think I’m saying its not a FOG issue as a matter of deflection, but in this case your infrastructure is telling the FOS Linux about the network, not the fog server.

You made reference to the resolv.conf file, that is on the FOG server. Changing that order or name servers will only impact the ability for the FOG server to look up and ping the target computers, when referenced by name. It will not have an impact on the target computer at all.

@tesparza Your problem is simple and complex at the same time.

It is true only real fog servers can multicast. Storage nodes can only send images via unicast images.

If you want to multicast images at each location you will need a full fog server there. The issue is that there will be a separate fog database at each campus, so the computers at campus A will have to register with the FOG server at campus A and not any other campus.

Now you can configure FOG in a non supported way (don’t get mixed up with the words), in that you have a full fog server at each campus, but you can use the FOG replicator from a master (root) node replicate its images to all of the remote fog server. The only gotcha here is that it will only replicate the raw image files to the remote fog server. You will need to manually export and then image the image definitions from the root fog server to each remote campus fog server via the web ui.

@florent said in How to secure postinstall/postdownload/sysprep scripts folder (NFS) ?:

In the next FOG version it will be NFSv4 ?

Only if the developers accept my edits. I do have instructions to upgrade FOG 1.5.9.x to support nfsv4. That is how I’m working on it in development.

@utpalgiri143 Well I got as far as your first picture and I know the problem you have. Your dhcp server is not nice to you. If you want to really debug the issue I can tell you want to do and where to look. But the simple answer is that your dhcp server is not sending a NULL character at the end of the text string so the client is seeing undionly.kpxeB the B is the junk at the end of the text string. If the dhcp server was working correctly it would send a null character 0x00 after the e in kpxe.

Anyway, the way to fix this is to not use your dhcp server to send out pxe boot information. Use dnsmasq instead. I have a tutorial here. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server I suggest you install it on your FOG server.

If you have a flat network (one subnet) then installing DNSMASQ is all you need. If you have multiple subnets, then you need to update your core network router where the dhcp-relay/helper agent is running. Add the FOG server as the last dhcp server in the dhcp-helper list. No worries FOG/DNSMASQ will not give out IP addresses only supply the PXE boot information for you network. Be aware that DNSMASQ will override any settings you have listed in the dhcp server for dhcp options 66 and 67.

@tesparza ok we can take a few steps to debug this issue.

first lets ensure you are running the latest kernel. I don’t doubt that its running 5.10.50, but lets at least confirm it.

if you have not done so manually register this computer with FOG. You will need the network adapter’s mac address to register it.

Now schedule another capture/deploy (doesn’t matter) but before you tick the schedule task button select the debug option.

Now pxe boot the target computer, after a few screens of text that you need to clear with the enter key, you will be dropped to the FOS Linux command prompt.

first lets check the kernel version with uname -a that will list the running kernel version.

Next lets get the hardware ID of the network adapter with lspci -nn | grep -i net

Lastly let see if there is any messages about missing firmware drivers with grep /var/log/syslog | grep firmware (note i can’t remember if the log file is syslog or messages off the top of my head)

Lets see what comes of these commands. These are three areas where we might have a problem.

@raymond-bell This answer really depends on how you installed fog. If you used the git method then change to the fogproject directory, in there is utils/FOGiPXE/buildipxe.sh Run that script and it will rebuild ipxe with the current version. The FOG server WILL need internet access to download the latest build of iPXE source code.

Once the build is complete the quickest way to copy the files over is to rerun the fog installer script OR search for snponly.efi with find / -name snponly.efi This will find the location of the just compiled files. Copy the ones you use from this location to /tftpboot When you pxe boot once again pay attention to the iPXE version and build number. Your picture sows 1.20.1+ with a build version of [g4bd0] I suspect the build version will change. If it does not then the iPXE files didn’t get updated correctly.

@raymond-bell said in Lenovo M70a Pxe boot:

Ok tried a dummy switch and same issue but after reboots couple time it goes to fog screen the click full host reg and it hangs on
bzImage . . . 0%

OK this is a new one. It can’t initialize the network adapter but after several reboots it does but then fails to transfer bzImage.

Have you checked to see if the firmware is up to date on this computer including the nic driver firmware (this would be a hardware thing not related to any OS level driver).

Do all of this model act this way or only this one unit.

What kind of network adapter are you using? Is it built into the mobo or is it an external usb attached network adapter?

If this all fails to give us results we can always get it imaged form usb booting right into FOS Linux. There are some caveats to this, but we CAN still get the imaging job done.

@x23piracy said in Lenovo E15 Gen2 won't PXE boot (bzImage):

Hi @Nate-Baker can you share the kernel please?

What Nate is referring to is rebuilding ipxe and using those new ipxe boot code. The link he referred to tells you how to do this on your FOG server assuming you used the git method to install FOG.

Not really connected to ipxe, but make sure you are running 5.10.x version of FOS Linux kernels to have the latest hardware support.

@tesparza If you get this message before the ipxe menu is displayed lets see if this solves your problem too: https://forums.fogproject.org/post/141618

In that we may need the latest iPXE boot loader for the latest hardware. The link above shows how to compile the latest version of ipxe.efi and snponly.efi

Then moved the new copies to /tftpboot directory.

@michaeloberg said in Issues with USB Type C NIC Adaptors:

the version of the OS on my FOG server is Ubuntu 16.04.6 LTS

I don’t want to be quick to judge but ubuntu 16.04 was marked end of life Apr 2021. The error in your previous post is staying the certificate for the http request failed verification. I don’t know if that means your ubuntu version is to old to with with current certificates, or the protocol used by the web site is not understood by ubuntu 16.04. (i.e. TLS 1.0 vs 1.2 [guess])

@sebastian-roth The OP has some things inconsistent in his dhcp settings. I’m working with him on chat. Its not currently a fog server issue.

@michaeloberg OK first of all well done updating your fog server to a supported OS build. You probably should take the installation up to the current dev branch to address a disk resizing issue with Windows 20h1 and later. BUT for right now yo have the current build to do what was originally suggested. The version of iPXE that comes with FOG 1.5.9 may need to be updated to support this mac passthrough function.

I don’t know if I posted this link before, but just recently I created a tutorial on how to (re)compile the latest version of iPXE with your FOG server. I think this is where you got stuck before: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

Before you go through this process, pxe boot a computer and on the iPXE banner screen quickly note the hex values in the square brackets right after the version number. That is the build number. Now rebuild and install the latest version of iPXE. The pxe boot the computer once again and pay attention that the build number changes.

I do have to give you the caveat here that even the latest version of iPXE might not address the issue with this network adapter. I know it seems like you went through a lot of pain to get to this point and maybe it still doesn’t work. Your efforts have not gone to waste even if this IS the conclusion of this issue. You understand the FOG system a bit more and are now running on a supported OS for many years to come.