@thor_egil Just to add to what George said, find information on this in the docs: https://docs.fogproject.org/en/latest/reference/change_fog_server_ip_address.html

@robertkwild said in is it ok to make new dir in /images:

OK to create /images/backup

Yes it is OK. FOG don’t care or will ever see it.

@robertkwild Yes, it’s perfectly safe for you to manually deleted the image directory/files. You are the administrator.

@sebastian-roth

Update…
It appears updating the init.xy file AND adjusting the KERNEL RAMDISK SIZE setting was the key to get it working. Only have tested with 1 of the images created on the new 1.5.9 server, deploying on the 1.5.5 server. Looks like we can limp along doing this until we can get the other sites updated, which is in motion now.

I owe you guys a beer! Thank you again!

@robertkwild said in syspreping a vanilla windows golden image:

i found this, you can sysprep win10 up to 1001 times

Just to be a bit snarky, if you have to sysprep your image 1000 times, I think you might be doing something wrong or IT should not be your field of work.

But on the less snarky side its good to know the number and hopefully I’ll never personally need it. As I said we use MDT to build the golden image so I get a fresh from DVD image (with current windows updates) each time the golden image is recreated.

ok job done.

just renamed the images dir to something else, made a new images dir, in fstab mounted the raid6 in the images dir and re ran the setup shell script

i did a capture and a deploy and all is now good

thank you all for your help!!!

@quazz Too add on a bit,

If you find something that doesn’t work, let us know. We will most likely request some more technical information so that we can do the research to find out if there’s a way to add it, or a patch we can use to incorporate, or we will find there is nothing we can do currently.

The point here is, you’re absolutely correct: We don’t know what will or will not work. We have some good google fu and only a few developers and testers working to get information so we can be as hardware agnostic as possible. But we aren’t all knowing. We know a new version was released and do our best (granted I’ve been slacking lately I suppose) to keep the kernels updated and including anything that maybe missing that we can add.

If it works, YAY, if it doesn’t, and we say try this kernel, if it works YAY, if it doesn’t let us know. We’ll ask for information and probably even walk through what we need and how to get it. Then we’ll try to find out information and give back whether or not we can do anything, and if we were able to do it, to test out the new thing. If it works, YAY, if it doesn’t rinse and repeat.

@echophi The FOG installer will take care of package installs for you and it will error out if it’s unable to install the correct packages. Please run dpkg -l | grep php to see what you have still left installed.

I would suggest you just re-run the FOG installer and let us know to what point it runs.

Just wanted to follow up on this for anyone else in same situation. Essentially the VtoV works just fine. As we had changed hostname and IP we only ended up having to reinstall the FOG client on the desktops for them to become in sync with the new FOG Master server. All other things just worked.

Cheers Tom

@jonathanho92 said in no configuration method succeed dhcp fail please help:

this happen only when multicast we have no problem with unicast

I don’t think this is the case. The bootup for both multicast and unicast are exactly the same at this early stage.

I guess you are using different devices when multicasting?! Use the exact same physical for unicast and I’d be very sure you see the same error.

@dudenamedben What hardware are you booting on?

For your INFO
snponly.efi is to undionly.kpxe
as
ipxe.efi is to ipxe.kpxe

In the only boot loaders, snp and undi use the built in nic firmware drivers to talk to the nic card. Where ipxe. has all of the network card drivers built into the ipxe boot loader. In the early days of uefi the snp drivers were terrible, that is where the FOG developers recommend to use ipxe.efi. The problem is with very new hardware, the iPXE developers might not have included the drivers in the ipxe build just yet, where the snp nic driver will work.

@sebastian-roth Yes, you’re absolutely right! The original had a secondary MAC matching the clone. I deleted it and expect the clone to show up shortly. Thanks for your patience! 🙂

@sebastian-roth yes I believe that was the case. I don’t remember the record count as I already purged data older than 30 days. I set up a SQL event that runs daily.

DELETE from userTracking WHERE utDate < now() - interval 30 DAY;

I can now run the reports

@tom-elliott

The FOG Server was installed not special like 10 others in our enviroment…

Works now after running:
sudo chmod 750 /opt/fog/snapins/ssl/.srvprivate.key

Thanks a lot!

@sebastian-roth So I’m not sure what has changed, as I’ve had to focus on other things, but now it works. I didn’t follow the most recent direction, but I’m booting various boxes via pxe successfully. No idea. …

@george1421 So, I am an idiot.

What was happening here is I deployed the old BIOS image, which blew away the GPT designation, and then when I created and captured the new image, the Windows installer never re-applied the GPT. I manually went in with diskpart, wiped the drive, applied GPT, rebuilt the image, captured, deployed, and voila! It boots now.

Jokes on me for trusting the Windows installer I guess. 😛

Thanks for your input George! It actually helped a lot.

@peet Looking at the error message, I’m going to guess you have a SOHO router or network switch setup as your dhcp server. Many of those devices point to themselves as the pxe boot server and not the fog server. As Sebastian asked, what device is your dhcp server? There are a few ways to work in this type of environment, we just need to know how your network is setup.

I figured it out… I must have screwed up some permissions on the web_root so I removed /var/www/html/fog/ and re-installed fog and all is well…

Thanks!