The fog user password is correct? What I mean, is while the Storage Management Page is showing the same settings, is it possible somebody changed the user password on the FOG Server itself? Or even yet, that the password never held or became corrupted on the server?

You can reset the fog user password on the fog server with:
[code]sudo passwd fog[/code]

Retype the password for the fog user twice and all should start working.

Ok. I will give it a try as soon as I can. Thanks.

Glad you got is sorted, sometimes, a fresh install isn’t such a bad idea (even if you JUST installed fog) 😉

his comment is a quote from the ipxe forums about the different options to compile ipxe with. we do have a .pxe but have not had any use for a .kkkpxe

if i am correct about it being fixed, then it is in the svn, yes

Thanks for letting us know, personally, I am like you, I don’t really use the Multicast features, just when someone says it’s not working so I can see what it is doing 🙂

Thanks for all the information it may help in finding the culprit and fixing it!

Of course if you troubleshoot further, feel free to leave some notes.

Moving the file should be fine. The reason the task isn’t completed is because it can’t link properly to the image. The fact that you’re seeing the “scrolling” asterix’s tells me that the image upload is complete, just it can’t copy the file from /images/dev to /images/<imagename>. Once it performs that feat, the task will complete from the DB. It’s just unable to perform the copy at the moment. You can safely power off the “uploading” machine, perform the move from /images/dev/<macaddress> to /images/<imagepathname>

It was. Debian creates that line by default. I fooled around with the localhosts file and DHCP config in order to get the isolated network running and in the process changed the former. Perhaps I was telling the computer there was only one machine on the network? I don’t understand enough about computer networking and how a PHP script creates a magic packet to fully answer the question.

Curiously WOL still does not work for uploading images, but since our technician computers are within 20 feet of my desk that is not a big issue.

UPDATE: Well WOL worked once for an image upload. Still not going to worry much about it though.

so I thought.

thanks Tom!

If you’re daring, are you trying out the latest SVN? I ask because with Mentaloid’s help, he created a setup to not startup certain services until FOG has a network device and mysql is running. I don’t know if this will fix mysql from starting at reboot, but you could try this version and see if it helps you out at al.

Another issue I’ve seen and written about on my github site is about a similar issue with FOG. [url]https://github.com/mastacontrola/fogproject/issues/1[/url]

This details one of the larger issues as well as a potential means to allow restarting mysql on reboots. i don’t know if it will work all the time, but it’s best I’ve been able to come up with.

You all must remember. I’ve added support for GPT and MBR since the release of 1.0.0. 0.32 and below only allowed MBR style disks to be imaged. Many times, I’ve seen now, that FOG is actually trying to create non-existent image files because the disk is setup in a particular manner but the partition table doesn’t match up. Meaning it’s creating non-existent partition where there really shouldn’t be any partitions. Because of this, fog can’t find the partition or write to it so it skips that partition and continue’s on in the process. In the case of GPT when expecting MBR, the data never has a place to be written to so it just “complete’s” while no information has actually been written. Please verify this by running a debug task and checking your system against fixparts, or in the case you intend to maintain GPT tables, make sure the data is where it is expected to be.

Go Team Venture!

PartClone is uploading as it should now with svn2250. Thank you very much.

Now to convert my image library from PartImage to PartClone.

You ask really good questions 😛

It looks as if a new tftboot directory was created as there is a tftboot.prev directory as well as the tftpboot one. That indicates to me that the new server was made from scratch, and the images that were common between the two were manually copied over.

That being said, in the pxe.config directory are entries aside from the default that carry the MAC addresses of my computers in question as well as a reference to the image 5800R2. I’ve removed these files and will try my luck with PXE again.

This is already progress from where I was, so even though you’re just asking me for more information you are indeed helping me so thank you very much.

Edit: That did the trick! Thank you!

It work well?
How had you distributed as partitions?
My HD one to W7 NTFS, ETX4 to Linux and Swat.

[url=“/_imported_xf_attachments/1/1331_sshot-2.png?:”]sshot-2.png[/url]

To OP I found that setting PIGZ to 0 actually slowed my transfer rate down significantly. I currently have it set at 3 and we’re happy with 5GB/min downloads. I can imagine setting it at 6 may also be slower than 3 though I haven’t tested that. I also know that NIC driver configs have everything to do with the speed though I know you said same OS so maybe there’s nothing there, maybe.

Any suggestion?

I would try by removing the current information on the disk and making sure a partition exists, follow the directions listed here please: [url]http://fogproject.org/forum/threads/quick-format-to-ntfs-with-fog-for-noobs.10349/[/url]

Any ideas?

If you’re Running Ubuntu, or Debian you can try the DNSMASQ service, it sometimes helps to alleviate issues and resolve to your tftp boot server with your correct file.

Instructions can be found here: [url]http://www.fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server#DNSMASQ_settings_for_iPXE[/url]

Use the section DNSMASQ Settings for iPXE.