@tom-elliott said in After update to 1.5.3 node offline and unable to PXE boot.:

selinux is set to permissive or disabled

well that was it. it was disabled before never thought of looking at that. i turned it to permissive mode. i was able to boot to my fog Server. we had a power outage it must of defaulted back to enforcing. thanks appreciate it.

Take a look at https://wiki.fogproject.org/wiki/index.php/FOG_Client#FOG_Client_with_Sysprep

If I’m understanding you right, that is.

Couple of things to check:

Is the original machine in BIOS or UEFI mode? Is the target machine in BIOS or UEFI mode? If both are in UEFI mode, you may have to manually add the boot option in the UEFI of the target machine.

Thanks for the reply. I never noticed it before.

@tthurston said in Unable to boot to Fog to capture image UEFI:

We were able to get past this stage.

From my understanding this is not the case. In the picture you posted first we see a client booting up going straight into a task (probably because one was scheduled for this ethernet adapter’s MAC address) instead of showing the FOG menu. It hangs at this stage.
Now you switched to a different ethernet adapter (new MAC address) and get the FOG menu. Now when you select the inventory it tries to go ahead bit possibly hangs just at the very same stage where FOS (FOG OS, essentially a Linux kernel) is loaded.

Again, please tell us the exact model an make of computers and ethernet adapters you have.

Please try using the adapter you had when taking the first picture and add debug loglevel=7 to the host kernel parameters for this client (see that you have the correct host entry with that MAC address we see in the picture). Then boot up the client. If that does not show more information on screen we might provide a kernel with CONFIG_EARLY_PRINTK enabled to see if we can get any printout from the kernel at all.

By the way, which version of FOG do you use?

I remoted into Joe’s system and looked about for a bit.

What I found was there was/is 3 versions of php and php-fpm installed and all were trying to run at the same time.

I stopped, php-fpm v5, php-fpm v7.0, and left php-fpm 7.2 running.

I could not find a handy copy of the official fog configuration for the www.conf file so I hand edited the distro’s version setting max processes to 50, start, min to 5 and spares to 6. I also set php max memory size to 256M.

After that I asked Joe to multicast deploy an image. He reported that he deployed to 24 systems. I watched the process status screen and the number of active php-fpm processes never went above 6 workers (where 50 is the max). Joe stated that all 24 machines deployed to completion.

So at this point I’m pretty sure the issue with this system was having multiple versions of php installed as the root cause. I’m not ready to rule out a www.conf file setting that is not right, but I’m happy with what I saw from the performance of php-fpm service in this multicast deployment.

@uwpviolator I’m not sure if such a file/key exists. We should ask @joe-schmitt about that. You could just do a wholesale - uninstall and reinstall for all your machines.

Ok found the issue grabbed the wrong windows image and the answer key is for the latest windows 7 build which is what caused all the issues its now working.

@joe-schmitt
I see. I did discover a BIOS/UEFI setting on this lab model that does not allow the computer to completely go to sleep. This may at least let me invoke shutdown or WOL. We’ll see. Otherwise, I can always use CRON to set the shutdown settings after things have been updated.

Thanks again!

@sherder For me I had similar troubles with Windows 7. I came to 2 conclusions. sysprep + unattend is very finicky. If things are not perfect you get all kinds of odd behavior. The other was that many parts of it seem to not function as they should, the computer name being one of them. The CD key is another, many sites/articles say to use 00000… or XXXXX… repeated, but mine would fail unless I put a valid key in (ended up using the Windows generic install key that MS provides on their site, doesnt activate just gets install done).

Are you making your unattend by hand or using a tool to generate it?

@sherder said in Windows 10 Unattend file issues:

It skips the setup but doesn’t implement the changes that I put in with sed

Not clear on the above, could you elaborate what you mean here?

When the syspreped image boots back up, are there some things that have been applied by unattend and some that have not, or does it appear to not have applied any changes specified?

Based on the information given I’m guessing that you’re missing a driver for the storage controller. Which simply means you need to get the driver and put it on loadable media and load it with the load driver button in the windows install wizard.
What are you installing windows on? As in what computer and model (or what the make and model of the storage controller if you know) or if it is a vm, what brand of vm (vmware, xen, hyperv, virtualbox, etc) and what kind of storage controller do you have configured for the vm.

For example:
If you use Vmware and set the storage controller to SCSI with vmware paravirtual that controller’s driver is not included in windows installers and has to be loaded and would give an error like what you’re talking about. In this case I would add a second dvd drive (you can just use one and swap a driver disk for loading the driver and then swap the installer back, but I find it simpler to just have two drives on a vm) and mount the vmware tools installer iso. If you’re lucky the inf file will be available on the disc, I believe the filename is pvscsi.inf or something of that sort.
(I’ve actually exported just the driver infs from a vmware tools installation to make this easier since the infs aren’t always on the install disc. To do this, Install vmware tools on a windows vm with all features of vmware tools selected then use pnputil /export-driver * C:\vmwareDrivers Then copy that folder to a remote server, sort through it to get just the vmware drivers, and turn it into an iso and put that iso in your vmware iso store)

Some other cases where this can happen are trying to install windows 10 on older computers where there’s a legacy RAID controller. There can also be legacy chipsets/cpus (if you’re trying to install on something like a Intel Pentium D or older) that would need extra drivers. I can help you find the driver you need if I have more information on what you’re trying to install windows on.

@allan0027 Excellent! Glad to hear it worked and happy it was something simple.

Thanks for the advice, it was an error. Sorry !

@ofh I am not exactly sure if that is the right spot to find what’s wrong but that was the first thing that came to my mind. Please check and let us know what you find.

@amerhbb Please look inside of the FOG Client’s log file on one of your hosts - it’s generally here: C:\fog.log Look through the log, do you see any errors? Feel free to post (enough) of the log for us to help.

@dawidh From your description so far I don’t think this is an issue with iPXE or the DELL laptops in particular. I reckon the switch you are using is not configured to work nicely. As a quick test grab a dumb mini switch and hook it between the laptop and you other switch. Give it a try again and see if you still have the same issue.

Here is what my unattend.xml looks like. I have made some redactions and comments to help out. I made mine using Windows System Image Manager. This is one of many webpages I used to learn about building my unattend file (and lots of trial and error): https://www.tenforums.com/tutorials/3020-customize-windows-10-image-audit-mode-sysprep.html

<?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="specialize"> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ProductKey>Your key</ProductKey> <TimeZone>Your TimeZone</TimeZone> </component> <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <!--I had to add this as FOG wasn't expanding my OS partition all the way after OOBE ran--> <ExtendOSPartition> <Extend>true</Extend> </ExtendOSPartition> </component> </settings> <settings pass="oobeSystem"> <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <InputLocale>en-US</InputLocale> <SystemLocale>en-US</SystemLocale> <UILanguage>en-US</UILanguage> <UserLocale>en-US</UserLocale> </component> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <OOBE> <HideEULAPage>true</HideEULAPage> <HideLocalAccountScreen>true</HideLocalAccountScreen> <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen> <HideOnlineAccountScreens>true</HideOnlineAccountScreens> <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE> <ProtectYourPC>1</ProtectYourPC> </OOBE> <UserAccounts> <!--If you skip account creation in OOBE, you need to enable local Administrator account or create another admin account in unattend file --> <AdministratorPassword> <Value>Your AdministratorPassword==</Value> <PlainText>false</PlainText> </AdministratorPassword> </UserAccounts> <StartTiles> <PromoteOEMTiles>false</PromoteOEMTiles> </StartTiles> <AutoLogon> <Password> <Value>password again</Value> <PlainText>false</PlainText> </Password> <LogonCount>1</LogonCount> <Username>Administrator</Username> <Enabled>true</Enabled> </AutoLogon> <FirstLogonCommands> <SynchronousCommand wcm:action="add"> <CommandLine>reg add &quot;HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon&quot; /v AutoLogonCount /t REG_DWORD /d 1 /f</CommandLine> <Description>Set AutoLogin count back to zero</Description> <Order>1</Order> <RequiresUserInput>false</RequiresUserInput> </SynchronousCommand> </FirstLogonCommands> </component> </settings> <settings pass="offlineServicing"> <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DriverPaths> <!--If you are using the postdownload script for driver injection, you will need this --> <PathAndCredentials wcm:action="add" wcm:keyValue="1"> <Path>C:\Windows\DRV</Path> </PathAndCredentials> </DriverPaths> </component> </settings> <!--don't think the offline image part is needed, but it's part of the one that get's made when I use Windows System Image Manager --> <cpi:offlineImage cpi:source="source" /> </unattend>

@joe-schmitt Have tried that, actually just used a different username and password entirely and it worked. Not sure why the other password was being sent incorrectly after re-populating the field with the other credentials.

The stop code error I got was “Critical Process Died”, Tried sysprepping, with and without an answer file and neither of those options have worked. I have verified in the bios that storage drivers are the same on all of these models. Sorry for the delay in responses I only get a couple of hours a week dedicated to this project.

So far our other 3 models, Dell OptiPlex 9020, 7040, and our Dell Lattitude 5580 have not had any issues. It is just when we get to these older models that we have problems.

@george1421 Ok so not an issue with the network, R620 works just fine off the same switch.

I am gonna chalk it up to the Dell 3620’s firmware (which is the latest) being problematic. Its not the first time it proved to be, likely wont be the last.

I guess I can live with the issue as it always eventually runs setup.exe. As long as its not a wide spread issue and limited to that model machine I am gonna move on and just live with it.

Thanks for the help though, always good to have another person to bounce ideas off and to get other ideas from.