@jemerson93 said in Assistance with unattend script:

I also no longer need to have separate unattend scripts for Windows 7 and Windows 10 MBR and Windows 10 GPT.

Excellent!! There are a few new options in Win10 unattend file but you can bypass them and as you found you can make the unattend file almost universal. That’s one less bit you have to constantly manage.

Hi Sebastian,

With all of the other posts I had up, this was related to my unattend script and completely unrelated to FOG. This is resolved!

Thank you for the help.

@Sebastian-Roth ok done 😉
https://forums.fogproject.org/topic/13329/1-5-6-small-local-disk-and-the-rest-unallocated

@Junkhacker

Thank you for the assistance. This issue was resolved. I’m not sure how to mark this as resolved though.

@Sebastian-Roth said in Partclone Upload Stalling:

@jemerson93 Please test the newly compiled 4.15.2 kernels you find here: https://fogproject.org/kernels/new/

Let us know if those help in speeding up the process and still don’t have the other rcu_sched stall issue.

Hi Sebastian,

It may take me a couple of days to get a response back to you. As soon as I can, I’ll do another upload and update you.

@Sebastian-Roth Let me test it with a machine and get a specific model. I will verify the UEFI firmware is up to date as well.

@jemerson93 The mbr/gpt issue needs to be resolved, period. The truth may be this slow creation process may be a ‘feature’ of 4.17.x kernel and not a bug. I can tell you this issue is still on the developers plate (which is getting overloaded at the moment). Please give them a bit to get back from holiday and back in business.

@jemerson93 Have you already tried using kernel version 4.15.2 as opposed to 4.16.6 and 4.17.0?

@quinniedid Sure!

Base steps were I created a new image in GPT format.

Afterwards, on the FOG server itself I edited the config file located at /var/www/fog/service/ipxe/refind.conf

Below are what I have the values at. This was after some troubleshooting so some may be back to their default values.

timeout -1
scanfor internal,external (I also have both lines commented out at the moment)
uefi_deep_legacy_scan is uncommented
scan_delay 5

From my memory that is all that is changed. After the imaging is completed in UEFI, it will boot straight to the OS instead of pushing itself through FOG and/or rEFInd.

Hope this works for you!

@george1421 George, thank you. The issue has actually been resolved. For some reason, checking what was using .1.25 did not cross my mind. As soon as I did a scan of our network, I found that someone had booted up our old imaging server which was located at 1.25. Once I turned it back off, Fog returned back to normal.

Issue has been resolved!