Oops!
I deleted from CLI. But I just did that again and the image did not appear in the list and the storage number increased accordingly.

-Jim

@george1421
For the 7080 it doesn’t have CSM mode unlike other Dell hardware I’ve had to image. I’ll give the latest 6.x kernel a shot and see how it works with one of them when I’m back in the office tomorrow.

@FGeyer

I know this is an old topic, but it looks like you don’t have a solution. I have this exact problem. It looks like @Tom-Elliott may consider this unnecessary (which may very well be true for other use cases), but for the sake of using @george1421 's awesome driver injection solution, it would be really nice to have. My workaround was to utilize OS type 4 for Windows 11 as I am not using it for anything. I updated the following line in “fog.custominstall”

case $osid in
5|6|7|9)

to

case $osid in
4|5|6|7|9)

Then I updated the following line in “fog.copydrivers”

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

to

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

Mark you image as OS type 4 and it works as it should. Hope this helps.

@DBCountMan I suggest to verify the checksum (sha256 file on github). If the checksum is wrong, then re-download init.xz. But if it’s right then try another init.xz version, e.g. https://github.com/FOGProject/fos/releases/download/1.5.10/init.xz

@DBCountMan Yes if you are using the location plugin. Using the location plugin you assign the storage node to a location and then when you register the target computer with FOG you assign the target computer to a location. Then when the computer pxe boots it learns who it needs to communicate with. So a storage node would work in this case to spread the load.

One caveat with storage nodes is that they can’t capture images. Only the master node can capture images. Then all storage nodes (including the master node) in the same storage group can deploy the image.

@george1421
Finally the problem lies within the next lines of the script:

choose --timeout ${menu-timeout} --default ${menu-default} selected
set menu-timeout 0

Or to be more precise, the problem is their order. ${menu-timeout} is used before it is defined and therefore, the choose command fails since it received an empty string instead of an integer.
Thanks a lot @george1421 for your support, I really appreciate it.

@george1421 Thank you for the guide link. The FOG is able to mount the external NFS as a storage node. However, there were errors that appeared after the end of the cloning. It doesn’t seem stable to me. Also, understand that the storage node might break if the FOG version is upgraded to the next version.
Therefore, at this moment, I have set up a physical machine instead of a VM to eliminate the issues.

@Tom-Elliott Yeah, that’s about the only other thing I can think of too. It’s a brand new Dell PowerEdge Server with a new HD though, but maybe the HD is just a lemon. I’ll swap out the HD and reinstall FOG and see if that works.

Thanks again for all your input!

@george1421
Hello, it seems that the problem came from the configuration left over on the workstation, which still contained snappins that were no longer needed and no longer applicable.
.

@george1421

I can create the OUs under the Active Directory Settings. From there I get the drop down like I want. I am also running the FOG client to add to domain.

I just need to figure out the changing of devices from one OU to another. Anyway I could use the name? Computers are named after the OU essentially.

For anyone with this issue in 2023 and beyond, the user is now “fogproject”
So the final command should be:

chown -R fogproject:root /images

@george1421 That would be the next step. When I said “replicate” I meant that I have a cron sync from primary to secondary every night, not instantly. So lets say I set up both servers to accept ipxe req’s and a field tech loads a new image on the primary at 10am and wants to deploy them to 20 PCs in the field. Primary FOG server takes a dump. The secondary FOG server won’t have the image until midnight. So there’s one issue. Unless I set cron to sync every hour or 30min. Another issue I found with rsync as much as I love it, is that if the primary server goes offline, the secondary, which has the /images nfs share from FOG1 mounted, will appear empty, and rsync will sync an empty dir to its own /images, thus wiping out that folder. I read that rsync can be tuned to not sync if a directory is empty but I have to research and test.

@greichelt said in PXE Boot - File not found:

dnsmasq is undionly,kpxe.0

You need to update dnsmasq to version 2.75 or later. Most modern linux OS already are past this version wit dnsmasq. I have a tutorial on compiling a supported version of dnsmasq if you need it. But my suspicion is that you have an old version of a linux OS that will cause you pain in the future.

@User_wds So I have to question if sysprep is working correctly because it should prepare the system for cloning and resetting of SSID.

This is the command I use to sysprep my image.
c:\windows\system32\sysprep\sysprep.exe /quiet /generalize /oobe /shutdown /unattend:C:\Windows\Panther\Unattend.xml

The unattend.xml file must be in the Panther directory and it should contain all of the settings you need to lite touch your image during automated imaging process.

Understand your issue is not a FOG imaging issue but a windows imaging preparation issue.

@dellborg82 What was the issue? This way somebody else who may be having a similar issue can also be helped?