@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

@MarkG said in Image files and Snapin files not deleted:

Bug in 1.5.0?

Possibly. 1.5.0 is long away and I don’t have all the changes in the back of my mind… 😉

So updating to the latest will fix the issue, that’s good!

@Jim-Holcomb Yes, you’re on working-1.6 and I’ll be helping with that here shortly.

@Sebastian-Roth I wish this was the case, but unfortunately, it isn’t. I just booted up a machine to give it a try, because I’m willing to try anything and it did not work. I typed my password in the username box to see how it was coming out and it was correct. I was wondering if there was some permission we need to set up for a user to be able to use this. I even tried using the defaulted fog user that is listed and that password, but again it didn’t work.

However, I just tried using the account we set up in Linux and it worked, although I was sure I tried it last week and it didn’t work, but maybe our system admin rebooted the server while I was out to make the changes take effect. It is now working.

Thank you for your response. I am enjoying FOG so far, it is much faster than the KACE 2000 client we were using before. In today’s IT world speed is necessary.

@BenR Don’t know from the top of my head right now as I have not coded the fog client. Could be registry setting. Probably easiest way is to purge and re-install the FOG client on that machine. Sorry but that’s the quick solution.

i have finally figured out how to get vm workstation working with no problems. My computer is plugged into real network at the time. I have to plug into the isolated network. When it pulls an IP address I then go and disable the adapter and enable it again. it then gets the ip address again. I then run ipconfig /flushdns.

After i do that and only then will i start VM workstation. i will go to the vm and go back to my snapshot. before i open it i always make sure the settings are showing bridged. I then power on the vm to the saved stated and run a ipconfig to make sure the computer and vm have actual same IPs in the subnet. Then run a flushdns on the vm. Then i sysprep and then boot to firmware on the vm. Then i pick network boot.

This has worked 7 times with no issues. I am sure i could cut out some steps but it is real easy for me to do all of it real quick. I only check to make sure it is bridged mode once.

Once i started to do this vm workstation work everytime and even on VM reboots.

I hope this helps someone else out.

Oh and i disable wireless first if you are using that.

@leonj said:

The repos that we have internally …

This would have been a very valuable information right from the start. 🙂

Good to hear you got it solved.

Oh yes, I forgot about it. You recommended it to me the last time too. This time I’m going to save it on my deployment server desktop, to have it there for debugging.

I remembered something about FOGMulticastManager. Here is were I red about it.
Thanks again.

I’ll be back with feedback after my next deploy.

@jahilton2002 said in Issues importing /images since new fog server build:

But it hasn’t worked, same error

Which error do you mean? I can’t believe you are seeing the same “Attempting tp expand/fill partitions…awk:…” error.

After talking to my tech team here, we’ve decided to “take the hit”.

Probably a good idea!

That works, thanks!

I’ve found the issue and the resolution:
https://bugzilla.redhat.com/show_bug.cgi?id=1582672
support for TCP wrappers isn’t compiled in vsftp binaries found in SLES and Redhat.

The installer must be modified to not output tcp_wrappers into the vsftpd.conf
This has resolved this issue in SLES.
I’m guessing ntcp_wrappers=$tcpwrappers\n$seccompsand is configured to output disabled if certain versions redhat? but that didn’t trigger for SLES

Thanks very much for your help @Sebastian-Roth

@Quazz Thanks again for your work on this! I’ll add this soon but have one more question about it, see on github.

What are your thoughts on https://forums.fogproject.org/topic/12428/win7x64-golden-image-partitions-problems-again/29 as an alternative system, by the way?

Good you reminded me on this! I moved the issue from repo fogproject to fos#18 where it belongs now that we have those things separated a while ago. Please let’s try to collect information and ideas there.

@Jonathan-Cool Nice you got it working! We’ll add Quazz pull request anyway for the time being. Should be in there in the next couple of days. I’ll mark this solved now.