@george1421 No unfortunately I dont have an available to me to test.

@cary1102 For that to work you need to push the router/gateway information to the clients in the 10.10.222.0 subnet. Add the following line so your config looks like this:

subnet 10.10.222.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; option routers 10.10.222.XXX; ...

Put in the gateway IP address instead of XXX. I suppose you have a router/gateway that is making communication between the two different subnets possible?!?

You need to know that there might be other obstacles still in front of you. The clients use a couple different protocols like HTTP (easy), FTP and NFS to communicate with your FOG server and so the gateway needs to forward all those for the clients to be able to work properly.

@andre_x said in Clone PC and change product key:

Isn’t there a way to pass a field (for example “Other Tag #1”) to a script passed to the host?

There is probably a way. I know during image deployment with a post install script you can have access to this variable.

How about the drivers? How can he find them for a new hardware?

I have examples of how to create a post install script to copy over device specific drivers. I have to admit the examples are only for Dell systems, but you could adapt to other hardwares as long as you have the inf (not exe) based drivers packages. https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

I use this method to seed (set) some unattend.xml settings to avoid having to use the FOG client to rename and activate the target computers. The word avoid is a bit strong, I have some unique OU naming conventions that are not supported by FOG, so I need to set then via scripting.

@ethan7888 said in error creating epoll fd: Function not implemented:

You confirm that the snapin, we can not put deployment programs of more than 3MB?

This is a setting in php.ini that limits the upload size of files. If you increase this value then you can upload larger packages. I have to tell you if the package is too large (like autocad), its better to install autocad on a hidden network share and then configure a snapin to call that network installation point instead of copying all of those files to the PC then installing the software.

Thanks @george1421 , the reason I wasn’t using sysprep oobe generalize was because it was causing my system to lock up at “Please Wait”. I found that un-joining and re-joining it to the domain “generalizes” the system enough so that everything works for us.

Anyway - I re-built the image and integrated the FOG Client (agent) into it. Now it appears the domain joining is working. Bad news is I’ll need to do another round of manual deployment, but that is the last time - after that I will have a full hands off deployment system.

Thanks for your help so far!

Your post is a bit unclear. Are you having an issue capturing the image or deploying the image?

When you say it reboots before its ready to deploy, is there an error message? Is this reboot happening in FOS image push or in/during WinSetup/OOBE? if the error is in FOS then capture a clear screen shot of the entire screen with a mobile phone and past the results here. The context of the error is almost as important as the error message itself.

@george1421 thank you for your responses. The timeout is fine the way it is, as long as I understand how it functions. Just need to turn it up while I join 100 clients to it. 😉 Though, since you say it’s probably a layer 8 problem on the group based multicast, I’ll try to find the time to run a few experiments on my side and see if it’s now working. I have a fairly simple network (air gaped single subnet educational lab), so that shouldn’t be the issue.

The repeating multicast would be handy but, as you say, there are certainly potential issues there as well. Again, as long as I understand the mechanic I can work with it! Thanks again for your answers(and all your help in the past as well).

Philip

Yes, what you say helps. I am new to fog and coming from using other device management programs so I am learning how fog works. It’s just a little new way of thinking for me right now. Not that this is a bad thing, I’m truly liking how fog works.
Thank you

My recommendation is as always when jumping OS versions like this. Spin up a new FOG server and then migrate your database and raw files. This does two things. First it gives you a clean OS and a clean install of FOG to build from. Second, if something happens with your upgrade your fog imaging is down. Yes I know you can always restore from a snapshot, but that still doesn’t address the first issue of having a clean OS (not upgraded).

Here is the process to migrate your fog install to a new server. https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG The only gotcha is don’t change the IP address of your new FOG server after FOG is installed (you can but its a bit of a pain to do so). With your new FOG server at a new IP address you will also need to update dhcp to point to your new fog server. On a plus note you can always fail back to your old fog server by just resetting dhcp back to your old fog server’s IP address.

@gaconvn1106 How is this related to FOG and what’s exactly your question?

muchas gracias!!! me servira de mucho y voy a realizar pruebas

@lambdacalculus Typically, this error is not caused by accessing certain pages… Generally speaking, your database connection is totally busted, or is intermittently working. And when it’s intermittently working, it’s usually load related problems. I have some questions for you:

How many hosts do you have running the fog client? How much ram/cpu do you have allocated to your fog server? What OS & version is your fog server running? What version of FOG are you running? Give us a screenshot of the output produced by the linux top command on your FOG server while the problem is occurring. Check for a duplicate IP address concerning your FOG server’s IP address using these instructions.

@george1421, great stuff! How couldn’t I see this before?
lol!!!
Well, I reinstalled it, and already applied what Elliot said. Let’s see if it will take things easy. Thanks!!

The intent of the following tutorial is to show you how its possible to use FOG to pxe boot a live environment with FOG: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images
Again creating a disk-less boot environment is not the intent of FOG, its just a proof of concept.

@ylber you can get the code from from working_dev branch in git repository.

@agray said in Issues with copying software configs?:

here are 13 people that will be using that PC. All accounts where set up, including IBM Notes, on the PC before Cloning.

Was this system sysprep’d? I know Lotus Notes (been a Domino admin on and off for almost 10 years). LN creates is config file in the user’s home %appdata% directory. Its possible that sysprep is cleaning out these directories where LN lives. I know post install you can just copy the notes data directory over from one computer to the next without any problems or needing to reactivate the account. With Notes 7, we were running the notes data directory from the user’s home drive without issue. That allowed users to roam between computers without needing to mess with local directories. Since then I understand LN now supports roaming profiles, but I digress.

@Wayne-Workman Interesting, I found our problem was the initial setup of the Ubuntu server that hosts FOG was set to allow auto-updates. This will come in handy for future installs, thanks!

@anhphuong all assigned to that host. i agree that being able to select what snapins you want at the time of deploy would be nice, but the logic is tricky and there hasn’t been a lot of demand for it.

@meobeou Hi, i am using it and it‘s easy to use, google for create pushbullet api key, create it in your pb account and paste it into the fogs pb config. After that it should work.

Bild Text

Bild Text

Easy 🙂

Regards X23

@sampsont I guess you could come up with a solution where you add our FOS linux system to your clients and boot from it. I don’t know anyone who’s done this but I reckon it’ can be done. Surely Ubuntu 12.04 had grub installed. So you’d copy bzImage and init.xz to the clients and modify grub.conf to boot exactly that as first boot option. The problem I see is that you only have one go (old Ubuntu and FOS being wiped from disk as soon as imaging starts) and if things do wrong…?!

And you’d need to prepare all the clients so why not just using clusterssh and do a normal dist-upgrade 12.04 - 14.04 - 16.04 - 18.04? Probably not trouble free either but not much involved to try it out with the first batch.

What kind of hardware do you have? As George said, some manufacturers like Dell and HP might provide command line tools that let you change boot options.

Would be real interesting to see if FOG would image properly while wiping itself from the disk. Should work as it is loaded to RAM but I never tried that before.