@Lee-Rowlett That is a sound route, I’ll keep it in mind while I dig into it.

Yeah, I was hoping it was some other reason than permissions, but somehow over the last week permissions changed on the server, so it is probably how I’ve got it setup.

The main system is installed on a 512 GB M.2 Nvme, and the images are stored on a 2TB HDD that I have mounted to the images folder. The permissions didn’t have a date last changed, so I’m guessing something happened with that mount at some point, maybe a power outage or brownout and maybe it reset the mount long enough to fubar the permissions?

Pure conjecture… but it was a permissions issue…

@Sebastian-Roth Looks good from this end.

@p4cm4n Good to hear it’s not caused by the fog-client. Keeping my fingers crossed that you find what broke the install on 1909 soon! Please let us know what you find.

@Fredorum We need more infos to be able to help. What software do you install? Have you tried installing this software manually (as well using the exact same parameters)? Do you get the desktop icon if doing it manually?

The fog-client runs as SYSTEM service account. This might cause the installer to act different to what you might expect. It might be easier to just create the desktop icon within a batch script that you run as snapin.

@Hartman4820 How was the image captured?

I’ve seen this issue with Zstd at compresison 19 (though it could be any form of Zstd) as zstd has a bug where just as it completes it doesn’t exit properly. Is this actually impacting the usability of the machine though? In my case it does not.

@astrugatch said in Adobe Acrobat Reader snapin not working:

If I recall correctly the Acrobat exe installer has an MSI baked inside of it.

There is two ways to grab the MSI.

7zip will sometimes open self extracting installers so you can grab the contents. Launch the .exe program but stop at the eula, possibly one later question. Then go to your temp directory The contents of the installer should be in a guid named directory in your temp. The alternate location might be in ProgramData\adobe path.

@marted That was a quick move. Your choice.

I am fairly sure enabling HTTPS in the settings file on the client should have fixed the issue if you don’t use custom SSL CA/cert. Did you restart the machine after changing the settings file?

@greichelt You can reply to this thread as long as its in the same concept as the title. Just be sure to tag me so I see it.

@thennessey said in Error Trying to Restore GPT Partition Tables:

I swapped out the files in the google drive link for the ones that are associated with the win10UEFItest image that I originally had questions about.

I see you swapped those out (numbers in the files are different) but I still cannot reproduce the issue as reported. The numbers seem ok and I can deploy using those files to a 100 GB size VM disk perfectly fine…

@Gilberto-Ferraz
Try this running this PowerShell script as a snapin. What it does is moves the first non-windows boot selection to the top, in your case it will move “IP4 Intel® Ethernet Connection I217-LM” to the top of the boot order.

Works for me…

Put the machines into a group. From the group, update the ad information as needed and save. That should update all your machines with the necessary information.

@hauser said in Issues using driver path in sysprep - Windows 10:

It may be that this method just doesnt work any more as I am fairly unfamiliar with the changes in sysprep of Windows 10, but I also was curious if this is even the best way to add drivers to the images.

You are rigth, M$ broke this handy feature of defining where the drivers are. What I’ve found to be reliable is using the pnputil command in the setupcomplete.cmd batch file to load in any remaining hardware specific drivers. So for my campus I have 2 golden images (one bios and one uefi) for 15 different hardware models, where the hardware specific drives are transferred to the target computer using a post install script, then I run the pnputil program to load the drivers.

ref: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed/4

@Gilberto-Ferraz said in Boot Option Issue (PXE booting):

Hello @Brendan-Clemente!
I have the same problem I tried to solve with the suggestion of @george1421 using Dell CCTK tool kit. But I could not. Are all your machines from Dell for this tool to work? Do you have any tutorials to follow?

Tools for working with BIOS configuration options are both manufacturer dependent and model dependent. Most manufacturers are moving toward some kind of wmi-acpi support, but each manufacturer has their own timetable for switching and that switch requires a new tool. You will likely want to consult the support pages for the manufacturer(s) of your machines as there is no universal solution.

@tech49 In this topic there is more than one issue being discussed. So “exact same issue” is not clear. As this was on FOG 1.5.6 I suppose things might be different anyway. Please open a new topic and post all your details: FOG version, Linux OS/version, error message (picture)…

@Joe-Gill Are you still around? Would be great to hear if you still see this issue on some of your machines. I have tried to replicate this problem but wasn’t able to. See here: https://forums.fogproject.org/topic/13902/fog-service-and-interventions

@Borega Try this file: https://github.com/FOGProject/fog-client/releases/download/0.11.16/Modules_SnapinPack_empty_dirs.dll

Should have the fix in it as well.

@mikeakin44 Please read trough this topic: https://forums.fogproject.org/topic/13922/dell-optiplex-aio-5270

@Mr-Pinguin777 Did you ever get this solved? Any more help you need from us? See George’s questions.

@Scott-Boucher This issue is definitely not fog related. I have seen this on multiple occasions and usually comes down to a UEFI machine with a SSD. either try disabling sleep is the advanced power settings, try disabling hibernation, Disable fast boot in bios, or theres a “turn off hard disk after” setting that you may want to see if thats disabled. I have linked this issue to usually the computers bios misidentifying the SSD as a HDD making windows use the wrong things to sleep/hibernate.

If you are using a HDD then try to see if there is a bios update for your machine and/or driver updates from the manufacturers website. Good Luck, this problem is proprietary to your type of device. Do some research in that and also look at disabling the settings.

I have also learned that 5400 rpm 2.5" HDD are absolutely horrible. If that is what you have within those machines, try to put in a SSD for a test and see if you get the same results.

@Gael et al.

I’m post a more descriptive post to summarize what the issue is. I don’t know how to fix (so I’ll start there.)

TL;DR;

Linux Kernel is putting a volatile Firmware on the NIC. This happens when FOS loads and the kernel begins associating the drivers. On restart, the firmware is still existing on the NIC from the Kernel. When Windows Boots, it re-flashes the volatile firmware so subsequent elements will work. Or a full power pull will do too (completely cold boot.)

Basis:

This particular issue, is due to Linux Kernel having a firmware defined for the NIC. This is volatile. This means when power is pulled, the firmware will no longer be present and normal actions will work properly.

While the machine is in FOS, the linux kernel hands it a temporary Firmware File and this is what’s causing the strangeness with the NIC.

Pulling the power cord causes the firmware to wipe. Similarly, if booting to Windows immediately after, and then powering off the machine, it should WOL. This is because Windows has a FW being applied when it loads, overwriting whatever the Linux Kernel pushed.