Each time I try, I take care to erase all active tasks.

I reinstalled smartInstaller on the master with the IP address of my FOG server rather than the FOG server name and now it works!

Problem solved.

Thanks for the reply 😉

@george1421 Using “tcpdump” we figured out that the DISCOVER packet was getting lost on its way to the DNSMASQ service. As you stated, we could reach HTTP/HTTPS between the remote location and here, so that wasn’t the problem.

We got it working by installing a storage node, and installing DNSMASQ in a server that we located in the remote location’s switch. As my original post said, we got problems trying this solution, but after copying the “/tftpboot” folder with all the PXE binaries from our FOG server to the second server, it worked well because it succesfully reaches the boot.php file and the chainload error doesn’t appear.

Your response has been incrediby useful, thank you very much for your support.

Gorka.

@Tom-Elliott i’ve tried this fog.custominstall

Create the following file named fog.custominstall in the following path on the FOG server /images/postdownloadscripts.
Copy the content into that newly created file
#!/bin/bash
. /usr/share/fog/lib/funcs.sh
[[ -z $postdownpath ]] && postdownpath=“/images/postdownloadscripts/”
case $osid in
5|6|7|9)
clear
[[ ! -d /ntfs ]] && mkdir -p /ntfs
getHardDisk
if [[ -z $hd ]]; then
handleError “Could not find hdd to use”
fi
getPartitions $hd
for part in $parts; do
umount /ntfs >/dev/null 2>&1
fsTypeSetting “$part”
case $fstype in
ntfs)
dots “Testing partition $part”
ntfs-3g -o force,rw $part /ntfs
ntfsstatus=“$?”
if [[ ! $ntfsstatus -eq 0 ]]; then
echo “Skipped”
continue
fi
if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
echo “Not found”
umount /ntfs >/dev/null 2>&1
continue
fi
echo “Success”
break
;;
)
echo " * Partition $part not NTFS filesystem"
;;
esac
done
if [[ ! $ntfsstatus -eq 0 ]]; then
echo “Failed”
debugPause
handleError "Failed to mount $part ($0)\n Args: $"
fi
echo “Done”
debugPause
. ${postdownpath}fog.copydrivers
# . ${postdownpath}fog.updateunattend
umount /ntfs
;;
*)
echo “Non-Windows Deployment”
debugPause
return
;;
esac

Save and exit your text editor.
Make the script executable with chmod 755 /images/postdownloadscripts/fog.custominstall **this part i get chmod: cannot * chmod 755 ‘/images/postdownloadscripts/fog.custominstall’ :No such file or directory please help!!!
fog.copydrivers

Create the following file named fog.copydrivers in the following path on the FOG server /images/postdownloadscripts.
Copy the content into that newly created file
#!/bin/bash
ceol=tput el;
manu=dmidecode -s system-manufacturer;
dots “Identifying hardware”
case $manu in
[Ll][Ee][Nn][Oo][Vv][Oo])
machine=$(dmidecode -s system-version)
;;
[Dd][Ee][Ll][Ll])
machine=$(dmidecode -s system-product-name)
;;
I[Nn][Tt][Ee][Ll])
# For the Intel NUC and intel mobo pick up the system type from the
# baseboard product name
machine=$(dmidecode -s baseboard-product-name)
;;
*)
# Technically, we can remove the Dell entry above as it is the same as this [default]
machine=$(dmidecode -s system-product-name)
;;
esac

if the machine isn’t identified then no need to continue with this script, just return to caller

if [[ -z $machine ]]; then
echo “Unable to identify the hardware for manufacturer ${manu}”;
debugPause;
return;
fi
echo “${machine} Identified”;

Removes Spaces in machine name, works better with path definitions machine=“${machine%”${machine##*[![:space:]]}“}”; 14-Sep-23 Jeffrey Boulais posted that the above code did not work for his install. He supplied this code as an alternative. If you run in to a problem using my code comment out my code and see if his code works better for your installation. The only right way is the one that works. Thank you Jeff for your input. machine=“$(echo -e “${machine}” | tr -d ‘[:space:]’)” 03-Jan-24 marsface posted that he could not get either of the two above machine clean up commands to work correctly so he provided this one below which worked for him.

machine=“${machine//[[:space:]]/}”

dots “Verifying we’ve found the OS disk”
if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
echo “! OS root Not found !”;
debugPause
return;
fi
echo “Found”;

dots “Verifying target Arch”
system64=“/ntfs/Windows/SysWOW64/regedit.exe”
[[ ! -f $system64 ]] && arch=“x86” || arch=“x64”
echo “${arch} found”;

debugPause

set osn path names based on the osid set in the FOG WebGui

case $osid in
5) osn=“win7” ;;
6) osn=“win8” ;;
7) osn=“win8.1” ;;
9) osn=“win10” ;;
esac

dots “Preparing Drivers”
clientdriverpath=“/ntfs/Drivers”
remotedriverpath=“/images/drivers/$machine/$osn/$arch”

debugPause

if [[ ! -d “${remotedriverpath}” ]]; then
echo “failed”;
echo " ! Driver package not found for ${machine}/$osn/$arch ! ";
debugPause;
return;
fi
echo “Ready”;

debugPause

[[ ! -d $clientdriverpath ]] && mkdir -p “$clientdriverpath” >/dev/null 2>&1
echo -n “In Progress”

rsync -aqz “$remotedriverpath” “$clientdriverpath” >/dev/null 2>&1

[[ ! $? -eq 0 ]] && handleError “Failed to download driver information for [$machine/$osn/$arch]”

debugPause

@professorb24 I can read your post a number of ways. Let me see if I understand the intent. Let me use my words to describe your issue as I understand it.

You imaged a computer with the same image that works with an HP laptop onto a Lenovo. When you boot through the FOG iPXE menu on the HP, it exits correctly and the target computer boots as expected. But when I boot through the FOG iPXE menu with the Lenovo it fails to boot saying inaccessible boot device.

If I understand the issue correctly, then if you changed the boot order on the lenovo so that it boots directly from the hard drive does it boot correctly? In my mind its not clear if it is an image issue (something wrong with the information on the disk) or is it an iPXE or refind issue.

@plyons7890 The error message about an unclean file system is typically related to the source computer not being powered off correctly and files are still marked open.

If the source computer is a ms windows computer I can understand this error. You must not use the standard “shutdown” command because it is not really a shutdown/power off command but more of an advanced sleep command, leaving files open.

You can/should do the following

Let sysprep power off the computer before cloning with FOG. Turn off fast startup in windows, this will switch shutdown into its traditional shutdown mode. Use the windows shutdown command shutdown -s -t 0 command to power off the computer before cloning.

@george1421 Okay, then to make it easier, I’ll just use UEFI boot to avoid any problems. Thanks!

@george1421 NBP is almost always the “label” of UEFI, but you’re describing PXEv4 MAC?

Similarly, hte 0.0.0.0 seems to indicate that there’s no IP address on the machine in question. Maybe there’s no DHCP server.

Without an image or more detail, we’re not sure how to help as @george1421 as suggested.

@switch_apoc You’re not an idiot. And yes, simply rerunning the installer would have been my first suggestion so glad you got it all working 🙂

@george1421 Thanks.

@tia-clark What is ifogsim?

what do you mean “scheduling algorithm”?

@Lukaz You could try doing a post download script that takes the hostname you set for that fog host and put it in the /etc/hostname file.
I think there may be other locations that hostnamectl sets on newer linux builds, but this could still work.

I haven’t done a linux post download script but you can see some other examples in these posts, mostly windows based, but I’m sure we can apply the idea to linux without too much trouble. Just gotta mount the client disk in FOS (Fog operating system that you boot into over the network for the imaging process) after imaging is done and inject the fog hots hostname variable (not sure what the var name is off the top of my head) into /etc/hostname on the client. It’s a bit of work initially, but once setup should just work from then on.

https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection?_=1682187993801

https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script

@footbolvova Can we get a clear and complete shot of the kernel variables?

We need to know much more to be able to help you. The message says the target computer can’t access the nfs share on the fog server.

Is this a new install of fog or did just this one client have this issue?
Is the client on the same IP subnet as the FOG server?
On the fog server linux console, what is the output of showmount -e 127.0.0.1 ?

@geardog I think I understand what you did. Let me say this with my words. You built a FOG server but did not have the space on the small VM, so you connected via NFS to an external NAS. You mapped the /images over to the remote NFS server wanting to borrow space from that external NAS.

If that is the case, then you can’t do that with NFS. Basically you are trying to reshare a network connected drive. This is akin to taking server A and mounting a directory from server B as the W drive, then trying to share the mapped W: drive to a third computer.

The only way to make the above scenerio to work is via mouting the remote disk as an iscsi LUN on the fog server. map that external iscsi lun over the /images directory. Then install FOG. That will work because the iscsi lun is a block device, and nfs is a file level device.

This was a weird one. I ended up reimaging my FOG server and now it works. I wasn’t able to figure out what happened, but it was some kind of local issue as far as I can figure.