@andrewg78 it’s because of the huge history. There is no fixing that can cure it beyond cleaning it out. With 1.6, however, it will be somewhat alleviated to the use of proper sql pagination. This isn’t a leak persay, it just can’t store the amount of information in the memory space.

@tlyneyor Glad I could help. I’ve seen duplicates a lot, so I’m really familiar and very weary of them.

An easy way to detect rogue DHCP services is to do a packet capture on a linux box while issuing the commands to release the current lease and get a new one:
dhclient -r; dhclient. In the packet capture, you would see the rogue DHCP server’s address and MAC address.

Also, there is a way on Linux to check a specific IP address to see if there are duplicates: arping -D -q -I eth0 -c 2 192.168.1.250 ; echo $? If you get a 0 back from that command, it means there are no duplicates. 1 or anything else that isn’t 0 means there are duplicates. Note that eth0 in the command is the name of the interface you are using to send the request out of and 192.168.1.250 is the IP being tested. This does not need to be run on the affected computer, and probably should be executed on a normal-functioning system.

Can you tell me (sorry a bit too lazy to look) when you quick register a host, does it ask you for a group assignment? If so you could use the persistent group (hack) to create a host template with all of the settings you want by default for new hosts, then when you add the system to a template group, those settings will be copied to the newly registered host.

The other way I can think how to do this is create a mysql database trigger, to when a new host is added to the hosts table in mysql, the check box is checked in the database. I’m not really in favor of the second part, but it will work if all other choices fail. The template host/persistent group plugin it a bit cleaner approach.

@reese I am having the same issue. How did you safely downgrade back to 1.4.4. I had no issues there but can’t image an entire lab anymore. Just locks up. Hints on the downgrade process would be appreciated!

I figured it out!

I’m using Meraki as the router and setting option 66 and 67 doesn’t work (well… 67 does but 66 isn’t enough)

Under DHCP, the appropriate boot options need to be set.

0_1533836669297_Screenshot 2018-08-09 13.43.37.png

This can be marked as solved. I updated to 1.5.4 and everything is confirmed to be working once more. Thanks!

@gnichols I am sorry but we can’t help if we don’t know more details about your setup and what exactly goes wrong. Most situations/setups are more or less different and we need to know all your details to help. Start by opening a new thread and answering the following questions: FOG version? Has it ever worked for you? When did it break and why (update…)? Can you take a picture of the exact error on your screen and post that too?

If I understand your question correctly, your source computer only has a single hard drive, but your target computer has 2 hard drives. Can you deploy to this? Yes. in the host definition for the target computer update “Host Primary Disk” field to point to the correct disk.

@stucraster I have a tutorial around moving your imaging files off the root partition here: https://forums.fogproject.org/topic/11048/moving-fog-s-images-files-off-the-root-partition-2017-edition

Usefull commands are lsblk to show block devices (i.e. storage devices) and df -h to show mounted disks.

@leonj So try to go to the web interface, and then immediately check the apache error log file. Post the last 20ish lines of that, sanitized if necessary. Also - we need to know what versions of MySQL and PHP and php-mysqlnd you are using.

This message is telling me that either you change the password of the linux user fog’s password on the storage node or the settings in the storage node configuration on the master fog server is incorrect.

Understand this is the FOG service account called fog not the web ui’s default administrator account also called fog

@tom-elliott Hello, sorry, I did not understand what I had to try?

@UFR Thanks for letting us know. Should we take a deeper look at why this might happen with Fedora 28 you think?

@vince-villarreal Possibly someone capture an image over the original one. Run ls -al /images/<imagename> (put in the name of your image instead of <imagename>) to see the date of the files. Does that make sense to you?

Other than that could it be you are trying to deploy this image to a computer with a smaller disk?

@cmale What do you see in the apache error logs when you get the blank page. See my signature…

@snaggel I’ve run into this issue quite a lot in my environment. It took a ton of work to figure it out. I sometimes copy images from one fog server to another, and in the process the permissions on the folder/containing files were getting changed. In my case, running <code>sudo chmod 777 -R /images</code> fixes my issue.

@china-boy There’s not enough information in your post.

@kagashe The integrity plugin is not code-complete, I think. You can use md5-sum or sha256-sum to check the hashes of your image files manually though.

@zach-garner You can use it as often as you want.