@lmorel12 It’s all good.

For future then, edit your /opt/fog/.fogsettings file.

If I had to guess, storageLocation='/images' currently.

Change it to read:
storageLocation='/home/fog/images'

If I had to guess, however, another way to prevent issues going forward would be to make a soft link to /images pointing at /home/fog/images. Of course only do this if you know the files are ONLY on /home/fog/images.

I’d go with my first suggestion just to be fully safe.

@FlareImp this is because the fundamental way replication occurs has changed. I’m working to add in auto replication of the postdownloadscripts directory though. Same for postinitscripts.

The exports don’t copy the “associations”.

Hosts have a type of association, but it’s not an accurate system there. The separation between images and the actual image table is not accurate.

When new data is being imported, the ID’s are not the same, so when you export groups, you can’t really export the host associations. This is because the groupID’s will change, and the hostID’s will likely not match either.

Your best bet, when migrating, grab the SQL from the original, and import that. This way all yoru data including associations are copied between systems.

I’d recommend looking at your disk space. It can’t write to the error log file.

df -h

You probably will want to clean up the /home directory. We store backups of every update/upgrade/install if/when possible. Likely this is using most of the disk space? We also maintain backups of the database before it runs any upgrade on it so you will want to look at /home/fogDBbackups just to be sure.

@lawrence1997 said in Issue with Database Crashing and errors trying to upgrade to 1.3.5:
Well, database crashing would most certainly happen if the volume is full.

Please output df -h /home is typically laid out on a separate volume from /, mysql usually resides on /.

Mind trying to run the installer after running sudo -i

@KeithDib I’m having a hard time understanding what the end goal is here.

We really are trying to help and it seems you’ve already all but thrown in the towel on this.

Port Forwarding is NOT pxe boot options. So I’d recommend removing those options from your router.

Port forwarding on a router is used to forward internet traffic to your designated place. Most routers don’t do native “loopback” which would be required in how you’ve setup your port forwarding. “Loopback” as I’ve termed it here means, internal sources are going to the “internet” source and being looped back in through the port forward just as normal internet traffic would flow.

Your PXE options are not port forwarding. I know I already said this, but I cannot stress that enough. You almost certainly are not wanting people requesting your internet IP address to be able to boot from your fog server.

@KeithDib While the ports you’re discussing are correct port forwarding is not how you address the problem. Port forwarding is NOT intended to handle internal requests for information. All port forwarding is doing is forwarding traffic from a designated part and source IP and forwards it to the defined system. Then that other system can handle the information to be returned to the requestor.

The dnsmasq stuff isn’t that hard and you don’t have to learn all new stuff. It’s pretty much a step by step guide. While there is the “off chance” you can learn something, I don’t think it would be overly time consuming, and I’m always willing to help when you run into issues.

We’re trying to help you get FOG working in your environment with as little work as possible based on the information we have. If you don’t feel the need/want to perform the actions, that’s up to you. Just know we’re still here trying to help you succeed in your project.

@TTellez I see some glaring issues in your config file.

First, you have Subnet mask of 10.1.10.0 network of /24 (255.255.255.0)

Second, your router is defined to 10.1.1.1? What is this router?
Third, your next-server appears to be 10.1.1.10.

Well if your FOG Server IS the dhcp controller, this would definitely be the issue. A /24 network can only reside in scope of itself. so your network is being issued an IP in the range of 10.1.10.x, but your server is on network 10.1.1.10. The pxe client’s can’t reach the fog server.

I’m confused here. NAS can do DHCP just fine, but what is doing this going to fix in regards to Capture having been broken until RC-3?

While I realize the issue of deployment was, as of yet, still broken for Windows XP/Vista, DHCP had no bearing on the capture/deploy process at all.

First I feel I should clarify, “Sectors 5-7” is always going to be in regards to the disk. I’m not aware of any system that refer’s to “Sectors” on a “partition” basis. Sector 5-7 will remain Sector 5-7 irrespective of the partition those sectors may reside in.

What is defined for FOG Web host?

FOG Configuration Page->FOG Settings->Web Server->FOG_WEB_HOST

Sorry for the delay in response.

Can you please run through https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

Of note:

Please make sure permissions and rights are all good on the “master” nodes?:

sudo -i
chmod -R 777 /images
chown -R fog:root /images

The FOG Client (and any of its files) have nothing to do with the “Ping”. Nor does the “Ping” have any effect on the hosts from functioning.

That said, port 445 on the Windows clients needs to be allowed. That should be all that’s needed.

FOG Configuration Page->FOG Settings->TFTP Server->TFTP_FTP_USERNAME and TFTP_FTP_PASSWORD

We did not need to do a full clean install or anything. I remoted in and helped out.

@keith75140 now has a fully functional fog server while using Ubuntu 17.04 as the base OS.

@dylan123 So the issue, if you’d like it fixed for now (I’ll relook at this code though).

Can you open the file, and add the /dev/sda components?

In other words make the file read as:

/dev/nvme0n1 dcfabb9e-4507-415e-b9a9-e437017df63b
/dev/nvme0n1p1 1:0C86C94F86C939CA 1:9c90a090-937d-4c9b-9a25-0381f463b590
/dev/nvme0n1p2 2:6CCA-8BF5 2:7e69ccb9-b499-4bf5-8528-293b71e42988
3:2de320a9-99b6-4191-aeeb-1c15e96fae1d
/dev/nvme0n1p4 4:CC34D93B34D9296A 4:b1911679-d848-4e8b-82fc-98616b55452e

@anthony.delarosa Did you remove all the hosts first?

Right.

You’re exporting to chagne the names.

Then you remove all the hosts are you changing. Reimport.

Essentially what you’re importing is failing because it already exists.

@anthony.delarosa said in Hostname Change on 700+ Workstations:

2017-04-20 2:32 PM Middleware::Response Invalid security token

2017-04-20 2:32 PM Middleware::Response Invalid security token

Please go to the hosts you reimported to edit, and click the “Reset encryption data” button for them.