Posts made by george1421

@greg-plamondon Hint: When you get the http 500 errors, inspect your apache error log file so see if apache or php threw an error.

@poizzon said in BIOS and UEFI boot, in VMware WinPE boot:

What would be the best place for a WinPE folder ?
I also noticed that after the upgrade, the WinPE directory is moved to the backup, and I always have to manually move back to it.

This might get you going here: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/7

As for the chatty cortana, this article will give you a quiet deployment. https://community.spiceworks.com/topic/2100746-cortana-talks-to-me-durring-sccm-task-sequence

Follow my guidance on the naming and location of your unattend.xml file.

Here is my sysprep command. I have it in a batch file that is placed on the reference image during MDT reference image build.
c:\windows\system32\sysprep\sysprep.exe /quiet /generalize /oobe /shutdown /unattend:C:\Windows\Panther\Unattend.xml

The timezone and language are set in your unattend.xml file. That works well.

Understand that the unattend.xml file and setupcomplete.cmd files will only run if you have VLK media. If you are trying to customize Win10 OEM media deployment you will have a difficult time.

Also, look at your chat icon in the FOG Forums, I have some additional information there.

I don’t have time at the moment for a complete response, but there are a few things you need to fix. Starting with the no-ip.org unattend.xml is a really good choice. But your file should be called unattend.xml and it shall be placed in C:\Window\Panther.

Somewhere I have the fix for cortana during oobe. It scared the hell out of me every time I images until I muted her.

If you are using FOG for imaging you will want to remove the disk commands from your unattend.xml file.

@arainero said in FOG 1.5 Fresh Windows 10 Pro can't go past PXE menu:
Some people where reporting

scanfor internal,hdbios

and

scan_delay 5

Were causing problems. In the Scanfor line, if you don’t have the legacy firmware enabled the hdbios value was causing refind to hang. And others have reported that scan_delay 5 was causing an issue, where setting it to 0 fixed.

But in either case you are not getting that far, iPXE is giving a chain load failure to launching refind.efi.

I wanted to know what computer you have, in your case it sounds like a custom job. So you have a gigabyte motherboard. What model.

The second part is making me scratch my head. That works perfectly. We need to edit the refind.conf file to stop the scan. With the FOG delivered refind.conf file in place you should not get the selection menu. What is confusing the hell out of me is if you set the UEFI exit mode for this computer you get a chain loading error, but if you key in the same exact command as FOG is sending you get the refind menu ( i.e. it works). The question is why, what’s different.???

@fernando-gietz said in How increase the FOG server performance?:

We are talking about the same check time This check time, what means?

What this means, it tells the client “Check back with the server every XX seconds to see if there is something for you to do”. So the clients will query the FOG server every XX seconds to see if there are snapins to deploy or system rename events, or what ever you can schedule with the FOG Server. This I feel the FOG server and MySQL are busy servicing these client check ins to do much of anything else. As I suggested change the check in time to 900 (15 min) and see if this resolves your problem, or makes it easier on the FOG server. If not, you can change it back.

Normally with that much ram, swap is never used. 800MB does seem like a lot. 1.3GB of ram for mysql process does seem to be a lot too. Again drop your check in time and wait 30 minutes to see if the resources free up on your fog server.

@paulman9 said in Hyper V and Pxe boot to Fog problems:

iPXE 1.0.0+ (47849)

This is the number I was looking for. OK going to the rom-o-matic site, if you scroll down to the bottom (after picking .kpxe) there is a which version section, and the default is master, if you pick the drop down the top entry is 47849, so that is the latest version.

So the question is why did the ipxe file I created work?? All I did, was picke .kpxe file type and pasted in the ipxe script and hit proceed button. What in 1.5.0 stable appears to be the same release.

I just looked at the ipxe kernel in my google drive and its 546dd (a previous version)

@paulman9 Well I seemed to have forgot about this too.

Can you do one thing for me, when iPXE boots, the version you have. You will see a iPXE banner line. There is a hex code between two parenthesizes. Can you tell me the hex code on the version you are testing?

Also the developers just release 1.5.0 (stable) this week. That should have the latest version too. But again the hex code will tell us what version you have.

Here is the bit I referred to as not completely true.

This script if used in the post install script give you an example of updating a registry key using FOS.

#!/bin/bash
regfile="/ntfs/Windows/System32/config/SOFTWARE"
key="\Microsoft\Windows\CurrentVersion\DevicePath"
devpath="%SystemRoot%\DRV;%SystemRoot%\inf;";
reged -e "$regfile" &>/dev/null <<EOFREG
ed $key
$devpath
q
y
EOFREG

key is the keypath in hklm referenced by regfile. The devpath value is the value being changed. I personally don’t like poking about in the windows registry from the linux side. IMO its much safer to just leave bread crumbs and let windows make the changes to windows.

@palloquin We do something similar, but its two fold.

1. We use MDT to build the golden image. During MDT build, we create a hklm/software/version tag. Then we create keys under that like BuidRelease which is the date code that MDT created the reference image, BuildCode which is an floating point control number we use internally, plus a few other bits of information.
2. Then during imaging we use a post install script to update the setupcomplete.cmd with some “REG ADD” commands that include keys to ImageName and InstallDate.

You have to remember here that when FOG is deploy, the deployment engine FOS, is linux so it can’t really interact with the windows computer (that is not completely true) so all it can do is leave bread crumbs behind for OOBE to find.

@culture20 FWIW, The developers put this document together a while ago. https://forums.fogproject.org/topic/6162/firewall-configuration

There is also guidance on selinux: https://forums.fogproject.org/topic/6154/selinux-policy

I have not heard of any issues having ipv6 enabled with FOG.

Very nice, thank you for documenting this.

@arainero What hardware are we dealing with here? This is really strange response from iPXE.

I don’t understand why refind doesn’t at least display a message. I would focus on refind for the moment.

At the moment you see the hit ‘s’ for the iPXE shell. Lets go ahead and hit s so we can try a few things from the iPXE shell.

specifically

set fog-ip 192.168.1.3
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
imgfetch ${boot-url}/service/ipxe/refind.conf

chain -ar ${boot-url}/service/ipxe/refind.efi

@fernando-gietz I think maybe we are not talking about the same check in time.

Also your CPU usage doesn’t look bad (according to top).

@arainero In the post where you stated “With REFIND_EFI set it gets stuck on the following:”, That picture is of a bios (legacy) boot not uefi. I can understand why refind may not like that if you don’t have legacy mode enabled in refind.

Also what hardware are we dealing with here, both manufacturer and model?

@fernando-gietz It would be interesting to see what top had to say. With 6 vCPUs, it would be interesting to know how many cores your server has. If it has way more than 6, then 6 vCPUs is OK. Otherwise adding more vCPUs than necessary will slow down your VM.

My initial reaction is to take your client check in time to 15 minutes, in stead of 90 seconds. At 90 seconds you have 600 hosts hitting your FOG server (at an average lineralized rate) of 6 hosts per second. We all know host check in at random. So you might have 15 check in, in 1 second and 2 check in, the next second. So drop your check in period to 10-15 minutes.

Second I would surely enable php-fpm and memcache to see how well it improves your performance. I have only done this on a small scale and that really helped me with web server responsiveness.

Hopefully your vm host server uses more than one network interface to the building switches. For a university I might expect that they use 10 - 40GbE networking. Also look at what interface your VM is using to interface with your vm host server. If your hypervisor is ESX (vSphere) then ensure you are using the VMX3 network interface. That should give you 10G to your vSwitch.

Lastly, you may be at a scale (number of users) where you might consider removing the sql server from FOG and running an independent SQL server specifically configured to run MS SQL.

I think I might do the first 2 in the list and check on the 3rd one. Leave extracting mssql server out of the fog server until last.

@fernando-gietz Lets get a bit more details here.

1. How many vCPUs does your FOG server have?
2. Do you use the fog client? If so what is your check in interval?
3. How many network adapters do you have in this fog server?
4. Is this fog server virtual or physical?
5. What kind of disk subsystem do you have? (raid, single disk, ssd,??)

@arainero I’m not seeing anything in these that would cause a chain boot failure, unless you were enforcing https instead of http protocol for some reason. But if it was http vs https the boot.php would not have downloaded.

Which exit mode created the last picture with chainloading failed?

@scott-adams Did you happen to make the adjustment that jburleson posted about “php_value[session.save_path]”

If you have it setup correctly apache should be using php-fpm. I know its been a while since I posted that tutorial, it still should work. Also with only 2 vCPUs its ideal to keep the system load below 2.00 as I understand it.