@george1421 so far it’s only 2 out of the 12 I’ve done. If I hit boot from hard disk it will go to the drive, but otherwise nothing happens. Tried it multiple times.

Yes, the Dell Latitude 3189 are laptops that do not have internet ports and we had to use USB adapters. At that time, the version of FOG didn’t like same MACs for multiple machines. So the way I got around that was deleting the hosts since it was tied to a MAC from a USB and I was more concerned with just getting them imaged. I guess I deleted them prematurely. Unless I just overlooked something completely and did something wrong.

As for the deploy task ones, I’m not sure why they were stuck in there. They may have been ones that seemed to be giving me imaging problems and I turned off the machine before canceling it in the task menu.

@jhumpf Any news on this? What sort of task is this? Capture, deploy, multicast, other?

@TaTa I am wondering if you have any news on this topic or if we can mark this solved.

@EduardoTSeoane Just wanted to see if you are still buried in work…

@JulianC Well then we are missing some vital information here! What device is 10.229.9.50 and what is the IP of your FOG server and the NAS? Please post a picture of your storage configuration.

@John-Sartoris Sorry for the long delay. Took me a while to get other things done and find the time to look into this. I have not played with this myself and so I needed some time.

The topic linked mentions the Task State plugin (named taskstateedit). You need to enable/install it as a first step. Then define new task states that you want to have manually.

I have not been able to fully replicate the update of task states using the mentioned URL yet but I suppose we can figure this out if you are still keen to get this work. Let us know if defining the new states manually is something you consider to be usable in your case. I don’t think there is any other way. You can’t just call the URL as ...&stateid=This%20is%20my%20new%20state sort of thing.

@Sebastian-Roth Yes, the update resolved the disk partition issue thanks.

Final update:
Replacing the hardware solved the issue.
So it was either a hardware defect, or a bug in the firmware.

@bricktop135 said in Every time I deploy an image it tries to write to my USB Boot Disk:

next set up the PXE boot on the server.

?? All you need to do is update your dhcp server. There is nothing really to setup. Just set dhcp options 66 and 67 and your are done. If you want to dynamically boot between bios and uefi mode then you will need some more configuration. But if you have the fog server the hard part is done with pxe booting.

Anyway I’m glad you have it worked out with this computer.

@jramos76 Good to hear things are working for you with 1.5.9-RC1. 🙂

I’ve updated to 1.5.9-RC1 after a bit of work, I think I’ve gotten everything working now.

I have my Public signed wildcard cert working.

I’ve got ipxe configured to Trust the godaddy root cert. This was important as our content filter was again blocking what I think to be the validation attempts. This time it was not showing up as OCSP, but simple “web-browsing”.

edited /tftpboot/default.ipxe to use hostname, and added parameter to change screen resolution. Some of our newest machines have 4k monitors that make the menu tiny.

And lastly, Replication services, Image and Snapin, both are working. It final magic seems that the Replication services use “Fog Configuration -> Fog Settings -> Web Server -> Web Host” and cross reference it to the StorageNode names. It then takes the IP address and Interface configuration from there to determine if the nic is “UP”. It seems DNS resolution is not done on the IP address field here. I had the names and not the actual IP addresses. After setting “Web Host” to the FQDN, and adjusting the StorageNode name to match, and setting the StorageNode IP to the ip, and finally restarting the replication services, things started to all work. Sorry, that one was wordy.

@Sebastian-Roth Thanks for your help. I’ll post new topics if I find anything 1.5.9-RC1 related.

We’ll need a bit better picture of how your network is constructed.

Is the 192.168.9.x subnet just a dedicated imaging network, or is it a general business network with printer and an internet connection?

Is the 192.168.10.x subnet your general business network? Does it have a connection to the internet?

Where is your upstream router? From that upstream router can you get to the internet?

Sebastian is right about configuring the fog server as a router to forward packets between the interfaces. Its not the best solution since all of the data between the nas and the target computers will flow through the FOG server. Its totally possible to do, I just want to make sure there isn’t a better way to go about this.

Is your FOG server a physical box or is it a VM?

@j00k4 I suppose you use FOG 1.5.8, right? When we released this version Ubuntu 20.04 wasn’t out yet and while I have tried to get it right, Ubuntu decided to switch to a different PHP version just a few weeks before the final 20.04 release.

So please download the latest release candidate version of FOG and give that a try: https://github.com/FOGProject/fogproject/archive/1.5.9-RC1.zip

@Sebastian-Roth Yes it was on the iPXE side. During testing we booted FOS Linux off a usb flash drive and it imaged fine. Well with some clarity, it imaged fine once we added nvme_core.default_ps_max_latency_us=0 to the usb/grub boot parameters. SO that kind of points to ipxe/hardware/uefi firmware that had a conflict with this specific nvme disk.

I’m so confused.

I see 2 posts now with:

1923168.1.10...... One @Sebastian-Roth brought up, and the post directly after that also has the same typo.

Is this a typo, or is this literally what’s being displayed on the Host machine?

@fogusnew We are working towards a next stable FOG version by pushing out release candidates (RCs). FOG 1.5.9-RC1 is out since a few days and you might want to update to that to see if the issue mentioned is really fixed. If it’s not we can still look into it before the final release comes out!

@Jeff-Findley said in kernel interface not working:

Just an FYI - according to Netgear none of their unmanaged switches do any sort of STP. But who knows.

Yeah you never know. But beside STP we have seen a few cases where ethernet energy efficiency (EEE) stuff kicked in and caused such things. While it is possible to be EEE I still suspect George is right with STP…

@Greg-Plamondon another suggestion. We had enough issues with pxe boot compatibility acorss different devices that we embed a custom bootloader that has an option for booting directly to a local copy of the ipxe.efi file. We use grub2win and just have its installation as part of our provisioning scripts that are started by sysprep firstlogon. Found this to work better than trying to get custom nvram type settings, this way you get it individuallized per hardware but also using a universal config file.

@lewisreid01 Thanks for the update and good to hear that you were able to fix it this way. I was hoping we could figure out what happened to your install and try to fix it “a less invasive way”. But possibly this is the quickest way to solve this issue anyway. Well done.

For anyone reading this: The installer option -C should be used with great caution! It will reset all the pinning you have made when installing the fog-client on your hosts. So as described by @lewisreid01 the second step is to re-install fog-client on all hosts!