@Wayne-Workman

Sure,

I follow the steps in the wiki for the most part, except for the ipxescript I use:

#!ipxe ifclose ifopen && goto bootme || goto netstart :netstart dhcp || shell ifopen || reboot :netboot chain tftp://192.168.1.20/default.ipxe || goto shell

Where of course 192.168.1.20 is replaced with your FOG IP.

But, reading back over the wiki the section labeled Custom ipxe script has a way that bypasses default.ipxe entirely.

@Fritch94 I ran into this exact problem after upgrading FOG to the latest svn. It took me a while to track it down, but this solution worked:

https://forums.fogproject.org/topic/3433/unable-to-upload-first-image/5

It was a suggestion Tom made a while ago to another user with similar issues. Replacing pxelinux.0 with a sym-link to ipxe.kpxe did the trick for me. Hopefully it will work in your case.

Fog is a multitude of packages, but those packages have their own controllers. These controllers are designed in such a way that they handle their own startup and shutdown. Of course you can also start or shutdown or restart them as you see fit as well. The simplest way to shutdown is to type the command:
sudo poweroff or sudo shutdown -P now

To restart type:
sudo restart or sudo shutdown -r now

does that computer have 32 gigs of ram, by chance?
by default, i believe windows creates a pagefile equal in size to the amount of ram in the computer.
btw, fog automatically deletes the pagefile and hibernate files before uploading the image to the server, since they will automatically be recreated and they consume a lot of wasted space.

@Kiweegie said:

Thanks Tom,

I did move it myself. Uploading a new image ended with the same result though. I’m happy to continue manually moving from /images/dev/macaddress to /images/imagename if necessary just wondered if this was down to something I’d done wrong…

regards, Kiweegie.

The only reason that FOG wouldn’t move it itself would be due to FTP credentials…

Knowing now what credentials are set on the master storage node, try to connect via CLI using FTP with those credentials you have set. If it doesn’t work, there’s your problem.

i would add a note that it’s only specific versions of Ubuntu

if you’re still having issues with the “vista” setting, your best bet would be to upgrade to a trunk version of fog where it’s already fixed.

I have similiar issue, trying to join Windows 7 machine to AD.

I’ve tried different variations of parameters, in different ways I give administrator name and password and nothing, all the time error 1326.

But I noticed today that when HostnameChanger try to add machine to the AD, password in the database is changing as if it was encrypted again. Is this normal?

On the machine is installed FOGService 0.9.4 and on server FOG 4586 from git

@Wayne-Workman said:

if we could ever get the forum’s search feature to actually work. 🙂

😈

@jeffzimmm So from what I’m gathering - duplicate MACs need to be allowed in the DB. So the “unique” requirement needs removed - and any web code amended to prevent deletion. And - perhaps even a little area added that shows you the hosts with duplicate MACs (just so you can easily see without having to find them via MySQL manually).

@Tom-Elliott , what do you think?

@frenk Can you verify that your storage node’s “interface” setting is set correctly?

Storage Management -> [your storage node] -> Interface

You can get a listing of the interfaces available with this command:

ip link show

For example, in the previous output you supplied, it would appear that the “eth0” interface is the one that should have been set for the PREVIOUS build.
Can you get us some logs for the multicast manager? they should be here:
FOG Configuration -> Log Viewer -> Multicast

Tom is right, we need more details.

Is this setup at home? Are you using a consumer grade router combo-device ?

Are you in a private network? 172.16.x.x is a reserved range for private networks… So I’m assuming you’re either working for a very well established employer - or this is a home setup and you chose that range just to be slick 🙂

@moto_ryan Comment out the exit code for that line in the script code - for debian.

trunk/lib/ubuntu/config.sh

(or is there a directory in 1.2.0 just for Debian, I have no clue)

Search for “exit 0” where the failure code is and just put a hashmark in front of that line, like this:

#exit 0

Be sure to comment out the correct exit line.

This will allow that part to fail, but the script to continue.

Might I ask why you’re using an off-the-beaten-trail version of Linux?

@dustindizzle11 This is a well known issue with 1.2. I fixed it almost two revs after releasing 1.2.0, but had many other bits that made it unfeasible to come out with another fix (and it was mid imaging season.)

@Wayne-Workman I checked that, but I’ll check @tom-elliott’s suggestion next time I’m working with it.

@Wayne-Workman yes, as long as I set the local server storage node to master, the create new image page works.
I also have my fognode1 server, in a different storage group, set to master.

Can you be more specific on where to enable the “size on server” setting? I’ve looked in the FOG settings and am not seeing it.

EDIT: Nevermind, found it! FOG_FTP_IMAGE_SIZE. Thanks!

@Raymond-Bell Is anything not working?

@kverkiss Good !!! The next time I see a jumble of nonsense errors such as this I’ll recommend trying a different drive.

@Tom-Elliott
Yes all the nodes are on the same version as the main server. They had the files/folder in the path /var/www/html/fog/service/ipxe, but the clients booting from one of the storage nodes would not display the menu until we copied over the folder from the main server. We did make some modifications to the main server’s FOG_TFTP_PXE_KERNEL so that is why I had to copy it over to the clients.