what you’re talking about would require significant editing to php class files

so long as the file can be read anonymously, ownership doesn’t matter

try this file [url]http://mastacontrola.com/ipxe/f3d42-QUOTA_20-GOOD/undionly.kkpxe[/url]
note the extra k, you will need to make sure you dhcp option 67 is set for that (or rename this file to the same as the last one, but make note of this technically incorrect naming convention)

realtek cards are one of the ones having problems. from what i have seen so far, nothing appears to be configured incorrectly in your setup. tftp is operating and serving out the ipxe undionly.kpxe. it’s only then that it fails to pull a dhcp address and load the rest of what it needs.

can you verify that both the undionly.kpxe and default.ipxe are in the same directory and their permissions are 644

if it’s a simple standard image of windows 7 enterprise, there should only be 2 partition img files

we are still narrowing down the exact cause of these problems on some machines. here is another file to try
[url]http://mastacontrola.com/ipxe/f473-GOOD/undionly.kpxe[/url]

what does the fog.log file in the root of the client say?

if you’re certain your passwords are correct, you might check your vsftpd.conf file to see if there’s a line that says seccomp_sandbox=NO
if it’s there, try removing it and restarting the vsftpd service
if it’s not, try adding it and restarting the vsftpd server

try replacing your undionly.kpxe file with this one [url]http://mastacontrola.com/ipxe/f3d42-QUOTA_20-GOOD/undionly.kpxe[/url] and please report back

can you retrieve undionly.kpxe by tftp from another computer from command line?

you do not need to enable that to deploy images, but the code might still be trying to look in that directory, which probably doesn’t exist

are you trying to schedule a snapin deploy task for a host right after creating the imaging task?

ok, i think Tom has fixed this now. please update to the latest SVN version

check the password under storage management in the webgui

it has been moved to images

i think a few bugs with multicast are being ironed out for some environments at the moment. that said, i don’t use multicast. i don’t see anything in that log that would stop you from using fog for standard unicast imaging tasks

please check Fog Settings -> Plugin System -> FOG_PLUGINSYS_DIR and make sure it is set to
[CODE]…/lib/plugins/[/CODE]

it is used for multicast image downloading. without it, unicast still works fine, which is my preferred method anyway.

if upload speed is something you care about, you might try decreasing the compression rate. in prior versions of fog, the compression is set to 3. in the new version, it is adjustable, and set to 9 by default.