@fog_newb said in Strange formatting when selecting host. Dev Branch1.5.9.207 Ubuntu 22.04.1 LTS:

I saw Partclone 3.20

Yes that is the version that contains the updated code for apfs support. So it should clone apple based computers beyond getting access for the T2 chip.

Transferred to github to we don’t loose track of it: https://github.com/FOGProject/fos/issues/48

@danboid said in Removing MACs from multicast task without starting over:

I also seem to be having an issue with machines not changing their hostname to match what they’re known as to the FOG server. We’re using Windows 10 on the clients. I’ve installed the FOG client, set the address of the FOG server for the client and it has worked for most of the machines but not all. They’re all on the same network / switch but there are two types of PC with different network adapters if that could make a difference?

Just figured this part of your request is still open. Not a great idea to ask for several different things in one topic. As Wayne said early on we need the fog-client log (usually in C:\fog.log) to be able to help. Probably best if you open a new topic if this is still an issue for you - and post fog-client logs as well.

Cross linking the GitHub issue: https://github.com/FOGProject/fog-client/issues/72

@sebastian-roth Ok i test again with [] for mac but yesterday i probably write mac nots mac. Thx for help it’s working

@YaidenCR Which version of FOG do you use (lower right corner on the FOG web UI when being logged in)?

@george1421 Really appreciate the help, so turns out it was secure boot, after turning it off everything worked great.

In case anyone else has this question, the Reports tab serves this purpose. Once an AD user logs into FOG and starts doing things, the history report will log it.

@WT_101 Currently FOG does neither store the error message nor does it stop the task in case of a failure. Probably a nice feature to add if you are keen to get into it.

You wanna start by looking at the FOS script code. Pretty much all errors cause a single function to be called: handleError() in /usr/share/fog/lib/funcs.sh (code reference). This function could be extended to report back to the FOG server and even cancel the task.

@kureebow in windows, once the fog client is installed AND you have the correct AD settings in fog:
d308c21c-4d1f-4814-9db8-d0d82b071ccf-image.png

it should work without issues. Correct settings are make sure “join domain after deploy” as well as "name change(ad join forced reboot) are selected,as well as a domain username credentials with privilege to join the domain. You may have to “reset encryption data” for fog to get the correct token, that is if you keep getting the below errors over and over:
9/27/2022 10:48:41 AM Middleware::Authentication ERROR: Could not get security token
9/27/2022 10:48:41 AM Middleware::Authentication ERROR: Could not find file ‘C:\Program Files (x86)\FOG\token.dat’.

@Greg-Plamondon Sorry for the really long delay. Hope you got this solved!

Just for the record, fog-client auto registration currently works (FOG 1.5.9.200 - fog-client 0.12.2) and I don’t think it was broken in the versions you have.

Found a bit of time to look into this. Just in case anyone comes across the Middleware::Response Invalid MAC address format on unregistered clients again. This happens when a MAC address filter (FOG Configuration -> FOG Settings -> FOG Client - Host Register -> QUICKREG PENDING MAC FILTER) is defined so that a newly registering client’s MAC matches the filter.

Just for the record, fog-client auto registration currently works (FOG 1.5.9.200 - fog-client 0.12.2).

@sniffski OK that bit looks good.

So since you are comfortable with wireshark that will make the next bit easier. Since the FOG server and target computers are on the same subnet, lets use tcpdump from the FOG server perspective. (or wireshark on the fog server if that is where you are currently doing the capture from). Using wireshark on a witness computer will pick up the broadcast dhcp messages but it won’t the unicast messages. After the dhcp process the target computer reaches out to the fog server (dhcp option 66) and requests the file (dhcp option 67) and then transfers the boot loader (ipxe.efi) to the target computer over tftp. This is done over uicast messaging. So the witness computer won’t see it.

I have a tutorial here how to do this with tcpdump: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If you want to use wireshark on the fog server then use this capture filter port 67 or port 68 or port 69 or port 4011 Right after the DHCP DORA process it should ask the FOG server twice for the file defined in dhcp option 67, the first will be to check the size of the file the second to request the file.

Also be aware for uefi that safeboot needs to be disabled on the target computer or it won’t boot the nbf (network boot file) if it does transfer it OK.

If you can’t get a solution then post the pcap to a file transfer site and either post the link here or use FOG DM to chat the URL to me and I’ll take a look at it.

Just figured this has been added already thanks to @Piotr86PL’s pull request in August (which I had obviously forgotten about, nevermind).

@mn_19105 said in Can't create working api request for multicast sessions:

So if you want i can write a wiki with a bit of examples and clarification about the API.

Great! The documentation is managed on github. Syntax is pretty simple. Please let me know your github username (e.g. via a private message here in the forums) so I can arrange access for you to push to that repo.

@george1421 I was able to rebuild iPXE with the latest version and re-run the Fog installer. Worked like a charm! The new laptops now get to the Fog menu. Your help was fantastic! Couldn’t have done it without you! Thanks a ton!

Thks , so yes it was not booting in the correct format so i added the extra uefi file names to pfsnese and it works flawless now. Thks guys

@fairoozfarhan The gui route is the recommended method.

If that doesn’t work you can manually download the kernels from here https://github.com/FOGProject/fos/releases and then bzImage and bzImage32 (watch your case because it is significant) to the path I provided earlier. Use the file command to ensure the kernel is correct.

@george1421 We just ran the engine update. Thanks for those links. We’ll watch it for a bit to see how it looks. The GUI is a bit slow at the moment, hoping that clears up.

On a side note, while working with this issue, we ran .installfog and during the install it picked a new STORAGENODE MYSQLPASS password that had a closing bracket in it. It broke the node’s connections to the master even with the password updated in all the spots it should be. Once we created a new SQL password (on a whim to test, without special characters) and updated it in .fogsettings, reran the .installfog file, the nodes started talking to the master again.

I think we are in much better shape. We need to fix our node password issue and start imaging again to know for sure.

@rtarr said in 2 NIC Host: Set 1 NIC to Remote Management/Replication and 2 NIC to Imaging:

I am using two NICs because I want all the imaging to happen on a segregated network and any repo updates or image replication to happen over the LAN NIC. This prevents imaging from happening over our firewall tunnels.

Having a second nic and dedicated imaging network may not be necessary to avoid imaging over the vpn tunnel.

(connect both master node and storage node to your business network)

At the remote site set dhcp options 66 to local storage node IP address and dhcp option 67 to ipxe.efi. -OR- use either dhcp profiles or dnsmasq running on the remote storage node to point to the remote storage node for pxe booting. This will keep from downloading the ipxe boot loader over the vpn tunnel.

At HQ again setup dhcp option 66 to master node ip address and dhcp option 67 to ipxe.efi. On the master node installed the Location plugin. Create your two different locations and assign the storage nodes to those locations.

Now assign the target computers to the proper location, either via the web ui or when you do a full registration.

So at this point you have a local and remote location defined. You have the master node assigned to the local location, the remote storage node to the remote location. You now have the target computers assigned to the proper location.

So now you pxe boot a computer at the remote location. I will pull ipxe.efi from the storage node. The target computer will then make a http call to the master node to find out where its storage node is located. Then if the storage node is local to the pxe booting computer it will image all at the remote site. There will be small update http calls to the master node to let the FOG server where it is in the imaging process.

The only thing you can’t do in this setup is multicast imaging, that can only happen from the master node in any storage group.

@junkhacker

Thanks for your response. I admit I am inexperienced with linux configurations.

Do you have a suggestion on the best way to deploy fog as a VM, with a physical freenas system (with a NFS share)?

Sorry for the ignorance on my part.