@DJ Amazing we found this after such a long time of intense digging in packet dumps and testing. Thanks for posting the information on the switch so people can find this here in the forums.

I have though about this but don’t really see why we should “fix” NFS mount to use high source ports. I might be wrong here but from what I have seen in the packet dumps it seems like this is general behavior and changing this would need a fixup deep down in the NFS client libs code - something that we would need to maintain over a long time since I don’t see this change making it into the official code line. What do you think?

@dustindizzle11 Thanks for the heads up. Possibly I need to revisit what I said. Possibly there is a huge difference and it does make FOG run much faster in your case (and possibly for others as well). What I could think of is the php-fpm issue we still have in FOG 1.5.4 (see George’s post here). What is yours set to on Debian?

@CJR_ie Here you go. FOG detects your windows system partition to be fixed as well and therefore does not expand it on deployment. Edit the file d1.fixed_size_partitions by hand using a text editor and make it read

:1

Then schedule a new deploy task for your host and it should expand to the full SSD size properly.

I’ve found that there are a couple of things to do with the configuration.
I’m running 1.5.4 version and I’m experiencing the same issue.

To put this in context, I’ve installed the fog server and then the IP of this machine needed to be changed, originally it had 192.168.27.40 and now it’s 10.0.0.1

With this in mind, I found the same error than you.

As @Tom-Elliott stated I haven’t created the /home/fog/images neither /home/fog/images/dev, using his advice I created them and also created the .mntcheck files.

Then I modified the /etc/exports to reflect the changes, updating the paths to the new ones.

After that, as @Kiweegie wrote I executed exportfs -a, please notice that in the second line he proposes to modify the line of the /etc/exportfs adding an async modifier that nowadays is in place out of the box.

After all that changes, my client started but gave me a NFS timeout, looking at the error message I’ve noticed that the IP of the NFS export and the path weren’t correct yet.

Looking at file /var/www/html/fog/lib/fog/config.class.php I found that there are two values that should be updated
STORAGE_DATADIR
STORAGE_DATADIR_CAPTURE

I added the right path in both.

Tried to reboot the client but I received the same timeout.

So I ended up checking the configuration of my storage nodes at the UI.

I found that, in the storage node definition form there were a couple of fields where still had the wrong values:

IP Address Image Path FTP Path

I updated them and now it seems to be working properly, at least the image capture step.

I hope this can help anyone.

@Sebastian-Roth Very nice.
On a side note do those inits also address the intel raid-1 monitor application too? That one was related to a bootroot issue. Disregard, I see you answer the question in that thread too.

@Robert-H As we have the mdmon included in the official inits I deleted the special ones now. Find the official inits here:

https://fogproject.org/inits/init.xz https://fogproject.org/inits/init_32.xz

@george1421

Perfect!! Thank you George and Sebastian for your help and hopefully this helps others in the future.

-Joe

It works now! Thank you for all your help!

@Sebastian-Roth Thanks, I will have my Network admin redeploy the FOG client. Then entire environment was lost to a bad upgrade. This solved my problem

The wiki page you linked earlier should allow you to log into the web console. You might have to reboot he FOG server after you reset the password in the database because of the way FOG cache’s recent activity.

https://wiki.fogproject.org/wiki/index.php?title=Reset_WebUI_FOG_password

From the wiki this command should do it for you.

UPDATE users SET uPass = MD5('password') WHERE uName = 'fog'; exit;

I do have to say FOG 1.2.0 running on ubuntu 12.04 is really old. Unless you really need access to the images stored on that server, I (personally) would just spin up a new FOG server using a current build. FOG 1.2.0 doesn’t support win10, uefi firmware, nvme disks, or current hardware. If you need the images from the FOG 1.2.0 server you can copy them over to a new fog server and use them.

@John-L-Clark This is out of FOGs scope as we find WIFI not to be a reliable connection for deploying or capturing an image to/from a PC. So years back it was decided to ignore WIFI adapters altogether. We don’t have drivers for WIFI enabled in the iPXE boot nor have we included drivers in the Linux kernel that we use in our FOS imaging environment booted on the client machines.

Would be a huge task to add this and make it work reliably in most cases (thinking about different WIFI standards, driver issues and encryption stuff).

Why do you want WIFI to be the default/primary MAC?

@sapeurorca Try to reset encryption for that host, try to re-install the fog client on that host.

It is a fresh install, on that part.
I did mess with settings on the Imaging section (changed the DefaultMember to /images/FOGimages) I did not change the FOG settings

@Fernando-Gietz said in Multicast data address not change from one task to another one:

Se añade esta linea para que asigne direcciones IP diferentes a cada tarea multicast

I’ve added the patch, but a little more checking involved. This has been added to both the working and working-1.6 branches. It tests the set value for the $address variable. If this variable is set, it will calculate the address. Here’s the snippet of lines:

if ($address) { $address = long2ip( ip2long($address) + ( ( $this->getPortBase() / 2 + 1 ) % self::getSetting('FOG_MULTICAST_MAX_SESSIONS') ) ); }

Hopefully this will address the problem people have been seeing and allow the use of multiple sessions.

Just in the fwiw bucket, we recently found out that if you have 2 or more simultaneous multicasts streams going at one time, the trasfer rates drop off quite a bit. I do remember seeing someone create a patch to change the multicast base IP address with each new stream. That seemed to resolve the issue.

[edit] Updated info: https://forums.fogproject.org/topic/12300/multicast-data-address-not-change-from-one-task-to-another-one/16

@tesparza Which version of FOG do you run? I know we have a fair amount of users doing Win 10 with FOG and don’t see all of them reporting this issue. Not saying that FOG isn’t doing this but I guess it’s more likely something with your image.

Is bitlocker turned off?

manage-bde -status manage-bde -off C:

@fogmania @ykarami Good news to all of you, we have figured out what is causing the slowness and fixed it. It’s been a longer story [ref] - thanks again to @Quazz for doing lots of testing and finding very helpful stuff to figure this out!

As we have not had enough time to push for a new release yet you can simply update to the latest kernel and inits like this:

sudo -i cd /var/www/fog/service/ipxe mv bzImage bzImage.orig wget https://fogproject.org/kernels/bzImage mv bzImage32 bzImage32.orig wget https://fogproject.org/kernels/bzImage32 mv init.xz init.xz.orig wget https://fogproject.org/inits/init.xz mv init_32.xz init_32.xz.orig wget https://fogproject.org/inits/init_32.xz

@Dee Updating to the latest version is a good idea in general but as you seem to not have much experience with FOG and possibly Linux yet I am wondering if we better try to fix your issue before diving into a full upgrade.

I’m hoping that updating it will fix the issue of it not capturing images.

Please explain in more detail what’s happening. Error messages? Please take pictures and post here.

@mckayj @Quazz Great this has turned out to fix the issues on those CPUs. Thanks heaps!!

Will add x2apic to the official FOG kernel build. Let’s hope this is not going to cause any trouble for other devices. 😉

Edit: Added the option, will be in the official binaries soon: https://github.com/FOGProject/fos/commit/34967bf3f42fe56d835e1e179cdea78213ab3b6b