@labanh This is strange indeed. You might want to take a look at the apache error logs. Might shed a light on what was wrong. See my signature on where to find the logs on your FOG server.

EDIT: Tom just suggested that this might have been caused by Ubuntu’s unattended upgrades! Good point. Keep that in mind.

@jim-graczyk said in FOG installed on small VM. Possible to drag and drop images when needed for deployments?:

Wayne is an expert, so maybe my approach is more work.

My suggestions take into consideration the present skill level of the person doing the operation. Adding a virtual disk would certainly work.

Fair enough.

Thank you for the response.

@thelostarc The error message sounds kind of weird. Although you have fixed it by using Chrome, could you please upload a picture of the error message here?

@sebastian-roth I finally got around to trying this out the other day and after running a check disk and recapturing the image it is now resizing the partitions correctly upon deployment. I didn’t have to modify the ‘d1.fixed_size_partitions’ again so I’m assuming that the capture process either worked correctly after running check disk, or else it just continued to use my modified version of that file.

Thanks for your help in resolving this issue everyone, much appreciated!

Repulled 1.5.0 RC 7 per Tom’s instructions and the fixes were applied (repush was done to RC 7 after I had already pulled it)

@george1421 Thanks everyone.

Great work, thanks 🙂

@DarkStorm007 This is a very old post you opened up again. FOG was very different and has changed a lot. Please open your own topic and leave this old one alone.

Start the new one by telling us what version of FOG you are running and maybe the names of the fields you ask about (I guess it’s about printers but why should I have to guess, just tell us!!). Maybe even post a picture if you don’t want to spend words on it.

@tom-elliott

Tom,

We’re good on the cancellation issue, but I’m still seeing a series of packets with the same start time and ever increasing durations times for each subsequent snapin.
0_1502401559812_8e8425e1-fa40-46a0-a798-24addf32556d-image.png

I didn’t get that you made a change. I doubt I can be of any help with the code, but I’ll look.

The screenshot above is a single deployment of an image with several snapins. There’s a reboot after 0-W7PostImageCleanup and another after 1-UACDisable. So there are 3 “series” of snapins in this deployment.

2017-08-10 12:24:36 (2 snapins)

2017-08-10 12:25:28 (1 snapin)

2017-08-10 12:26:14 (6 snapins)

All scheduled as part of the image deployment and all separated only by reboots implemented by FOG as part of a snapin.

Jim

@themcv

OK - so yeah, maybe it was a DNS issue on the client side after all. One of the snapins I’m working on dorked the DNS search list.

I determined this by examining the spanins deployed to the host - 100% alignment with snapin that dorks the DNS searchlist.

Go Figure…

Thanks and sorry for the trouble…

Jim

Trying using noapic as a kernel argument.

Fixed, we appear to be uploading now.

@tom-elliott
I just tested Host registration and deploying image. So I confirm. It works.

@caw001 If that is the process you followed then something is not right with either the fog server or the usb module. Let me look into it. The kernel parameters don’t look correct. There should be more info in the kernel parameters almost like the grub config file is damaged. It should list the web server and storage info.

@chris178 I was able to fix the issue. If you can do a git pull from the fog-community-scripts directory on your server, you’ll get the latest copy - then rerun the installer and everything should work.

If you’re curious about changes, you can see them here:
https://github.com/FOGProject/fog-community-scripts/commits/master

Hi,
Now it works, I forgot to change the IP address in storage management.
Thanks a lot.

Nvm. Fixed. Ran the following from the troubleshooting page.
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL

DELETE FROM `hosts` WHERE `hostID` = '0'; DELETE FROM `hostMAC` WHERE hmID = '0' OR `hmHostID` = '0'; DELETE FROM `groupMembers` WHERE `gmID` = '0' OR `gmHostID` = '0' OR `gmGroupID` = '0'; DELETE FROM `snapinGroupAssoc` WHERE `sgaID` = '0' OR `sgaSnapinID` = '0' OR `sgaStorageGroupID` = '0'; DELETE from `snapinAssoc` WHERE `saID` = '0' OR `saHostID` = '0' OR `saSnapinID` = '0'; DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC` WHERE `hmPrimary` = '1'); DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC`); DELETE FROM `hostMAC` WHERE `hmhostID` NOT IN (SELECT `hostID` FROM `hosts`); DELETE FROM `snapinAssoc` WHERE `saHostID` NOT IN (SELECT `hostID` FROM `hosts`); DELETE FROM `groupMembers` WHERE `gmHostID` NOT IN (SELECT `hostID` FROM `hosts`); DELETE FROM `tasks` WHERE `taskStateID` IN ("1","2","3"); DELETE FROM `snapinTasks` WHERE `stState` in ("1","2","3");

Thanks for your feedback.

Cleaning the databases didnt solve it, will wait for the change to come to one of the higher stable branches.

@gotesson I’m only recommending searching for any bugs you might run into with the RC-6. If you’re unsure go ahead and post, and I’ll likely let you know if it’s known about/fixed or not anyway.