@jj-fullmer This is the only option I see about storage nodes in the webUI:

As far as testing the node goes, im confident everything is working, the error specifically (and thankfully) states its trying to contact the image repository at the old .131 address, id take a picture of it if I could, but my phones camera suffered an untimely death due to a freak washing machine accident…

Most of the exact error im receiving is in my OP, I just need to know where the variables storageip, ftp, and storage are stored. I havent come across them in any of the system files ive looked through.

Not going to lie, I just found out what ^f means, apparently ^ is somehow supposed to mean control, which apparently moves vi foward one page…ive been working out of the first page of everything apparently

Just checked my /var/www/fog/lib/fog/Config.class.php settings, all are pointed to the new IP. Im going back now to check my .fogsettings file

EDIT - Ya maybe if I had any clue at all what I was doing I could have figured this out sooner. Definitely not a linux guy…I just found the exact field I missed, I didnt know there was a whole storage managment section of the webUI, but if I had payed attention I would have seen this in the article I read about 500 times:
https://wiki.fogproject.org/wiki/index.php?title=Change_FOG_Server_IP_Address
“Update the IP address for the storage node on the FOG system where you changed the IP address Web Interface -> Storage Management”

Changing the IP now, im assuming itll be all set after that. If you dont hear from me, assume im all set and wearing a dunce cap…

Thanks for the replies.

@george1421 I followed this guide: https://wiki.fogproject.org/wiki/index.php?title=Change_FOG_Server_IP_Address
and took bits and pieces from other threads to fill in the blanks. I believe I have performed all the steps you suggested, I can confirm with 100% certainty that all the IP addresses in the webUI are pointed to the new one, as well as in my .fogsettings file (I modified it last week when we changed IP’s)

The new IP should be 10.10.10.22, and the old one ends in a .131. Ive checked a lot of the config files already, and I used this guide to verify that the exports file was fine:
https://wiki.fogproject.org/wiki/index.php?title=Change_NFS_location
I ran a exportfs -a afterwards, even though the settings were fine in the file. I also rebooted the server for good measure.

I dont have any other linux servers, and I have seen that script before, but to be honest once I step out of my nice safe windows environments im mostly lost. I do not know how to transfer that script to the server to run it, a painfully simple process for sure, but without a nice fancy GUI it might as well be in chinese and upside down. If someone could walk me through the steps of actually making that file run on my server I would really appreciate it, or if there are any other places to check that I missed let me know too. When I changed the IP’s last week I did re-run the installer, so whatever settings that changes “should” be correct.

EDIT - @george1421 After re-re-reading your post, can you cllarify step 2 please? Should the storage node definition be part of the web UI, or is that located somwhere else?

Hello, we recently transitioned our VM’s to a more standardized IP scheme and now im having a couple lingering issues with fog. I changed the IP from the old one to the new one in every place I found, read all the articles on it, then re-ran the fog setup. My web UI is working fine, I can PXE and get to the main fog splash screen, I can even register new hosts just fine. The issue comes when I try to deploy an image to a computer, I get the error:
"Could not mount images folder (/bin/fog.download)
Args Passed:
Because: Mount: Mounting <OLD IP ADDRESS>:/images on /images failed: COnnection timed out

Kernel variables and setting: <BUNCH OF STUFF, INCLUDING THE OLD WRONG IP> (storageip, ftp, and storage variables all set to the wrong IP)

Ive been reading a bunch of posts online trying to narrow this down, but ive got 50 computers to image by the end of the day so its kinda getting to be crunch time. Any help you can provide is appreciated.

@Sebastian-Roth So I did create a VM on my farm, and ran a deploy to that. The image process took under a minute and was very smooth, no issues at all. I have not modified any NFS configs, I assume theyre all default/auto managed. I have a copy of the exports, would you like me to re-run the tcpdump with the new syntax?

https://ufile.io/fpcep - Exports file

@Sebastian-Roth I appreciate the quick response, just sent the dump off to your email. THanks for all the help, hopefully we can get this issue tracked down and resolved quickly.

@Sebastian-Roth Thank you, yes I am still able to ping clients even when the transfer looks like its stopped. I let a capture run all night, and it took almost 18 hours, but did eventually complete. I captured the log, but dont exactly know how to extract it for upload. If this was a windows server I could just xcopy it Whats the best way to get the dump off the server and onto another location?

@Wayne-Workman All drives have between 98 and 100% free space, plenty for storing an image. Is there a way I can check on the server to see what information is currently being transferred? Ive tried with multiple hosts, multiple images, multiple cables etc… I dont think its a duped IP, or the port on the switch, though I am looking into a possible network config issue. Tomorrow im going to try and create a VM on my farm and see if capturing it directly from there solves this issue.

@Tom-Elliott Ran the capture with partclone zSTD and a compression of 19. Things started off slowly (Averaged 1gb/min for the few few minutes compared to 7gb/min normally) but then shortly afterwards speeds began to fall off fast. The first 10 minutes got me to 30% captured, the next hour was spent getting to 42%, and after the speeds started dropping below the 50mb/min mark, I killed the task. A buddy I know who also uses fog suggested I change my fog_boot_exit_type setting from sanboot to grub, running a new capture now but its looking identical to the last one I ran.

@Tom-Elliott Im setting up a new client to be captured right now, I will be using partclone gzip with a compression of 7 (unless you think there are more optimal settings). I dont believe its a space issue on the server, it has a 500gb partition on it and im capturing the image as single disk resizable, it says its a 7.9gb image. The drive im pulling off of is a 320gb drive, so even if it did capture the whole drive as raw, it still should have enough room for at least 1 image. I will report back once I test this new client capture out.

Thank you

Currently set to a compression of 7, but ive tested most of them between 0 and 22. Im using partimage right now, but ive tried partclone Gzip, and Partclone zstd, as well as using the 200mb split options.