@martinm Using postdownload scripts might be an option (depending on what things you wanna change). Just give it a try, it’s not hard. Search the forum and you will find an example. Regarding IP and hostname change you can look into this or give it a couple more days till the new client will be available on linux (which would give you even more options like running snapin tasks on the clients!).

@Sunks said:

they should all get DHCP during the PXE boot…

Definitely if your network setup is fine. Maybe give us some more information. Spanning tree? VLANs? Clients in different subnets?

As well, please let us know which errors you see on the clients when they fail to PXE boot! Post a picture or send us the exact error code you see.

@Tom-Elliott Yes, it is
00:0c:29:bf:57:4a
If you don’t mind, could you teamviewer and check ? Thanks!

@Sebastian-Roth
Yeah, i understand. Trust me i tried to do a lot of times, analyse logs and permissions and work on issues with an unix professor but we don’t found for NFS…
No problem, still working!

@Wayne-Workman Thank you!! That modification worked.

Good news, I have my 1.2.0 Fog server up again. After building my own ipxe kernel most of my machines can pxe boot properly. I used the bios and uefi @Sebastian-Roth made in that post and both seem to work. Its not asking me for the tftp IP any more and just registered/imaged/deplayed a few machines 😄

Download kernels pre-made just for FOG.

I would not advise replacing the inits - as the new inits would likely break everything in 0.32.

There is a guide on how to do that here:
https://wiki.fogproject.org/wiki/index.php?title=Kernel_Update

@Wayne-Workman It already is, if you update.

A cool little way I track what is going on for the clients when that is happening (That @Tom Elliott showed me )

Open powershell and type: get-content -wait C:\fog.log (or wherever you have the log stored.)

this will let you see what it is doing while it is doing it. Depending on the error it can lead you in the right direction.

@Wayne-Workman

Hi,
I tried to follow this procedure 3 or 4 times, it never worked… 😞
i got blocked when trying to access /images2, IO error everytime!

So i wanna try everything else to export fog storage…

@steveballantyne said:

I have not modified any php files.
…
I had to do some ugly hacks in several PHP files

Did you mean you didn’t modify php.ini files in your first statement? To be able to help you best we need to know exactly if you use the code provided by us or a modified version (which would be a lot harder to debug as I don’t know your modifications). Possibly installing LAMP did modify the php.ini file? Just a wild guess. Take a look and see if it has those options set (on Ubuntu that should be in /etc/php5/apache2/php.ini - restarting apache is needed if you change php.ini settings).

In the past I have connected to a NAS that has all my images on it. To make this work though…

There are a few articles in the wiki on how to connect NASs to your FOG server. Please give that a shoot!

One thing I wanted to ask — when I am installing the Debian/Ubuntu OS, should I NOT check LAMP server?

It’s not needed but should not hurt either as FOG still tries to install those and therefore would update the packages if needed. Although I have to admit that we cannot actually test all those different setups (like pre-installed LAMP). I have done it with pre-installed LAMP a couple of times in my auto installer setup! So I think this should be fine…

@jayphizzle Use a group, as you said. That’s how I do it.

@Sebastian-Roth Yeah thanks got it now pffft. its not in /var/www/fog but in /var/www/html/fog. Weird thing is these two maps are duplicates. I’m dumb lol.

Thank you everyone

@Sebastian-Roth i will do that
thanks a lot for help 🙂

@Mentaloid said in Multicast from second storage group:

I have already written a bit of a bodge script that checks multicast tasks on my main FOG server, and starts the UDPCAST process on the storage server if the image is found locally (storage group and image = local)

Now you have to share the script.

@moses Groups have never had persistent settings. Whatever you seen before, you’re mistakenly thinking it’s a group - it was not. Maybe it was your browser’s auto-filll, maybe.

Not trying to be harsh, but groups in fog are not persistent - at least from the pending 1.3.0 release and earlier.

2.0 WILL have persistent group settings though.

-edited. replied to wrong person lol.

@couldcareless there’s always a reason and the simplest is usually the truth gotta love occums razor.

Remoted in. Found an error in the schema-page and fixed it. THen found that the DB connections weren’t operating properly and fixed that. All is updated in the codebase too.

@Arrowhead-IT said in Quick Question re Changing Fog 1.2 IP address:

I think that if you just change the ip in the fog settings it might just take care of the rest for you.

This is true for a new install. For existing though, the IPs in the DB are not touched. This is by design.