Failing to create Win 10 v1909 with new cumulative updates image
-
Windows 10, 1909, 2020 update, fail to image, possible MBR issue
So I’ve made a fresh install of Windows 10 v1909 on a UEFI machine (so GPT partitions) and updated it with the cumulative updates that got pushed out this past week, also using the UEFI PXE boot for the imaging.
But when i go to make an image of it I see 2 issues come up, first is FOG resizes the MBR stating that it is over-protective 0xEE something code, (I’ll try to update this with pictures later),
Then begins imaging the separate partitions, Recovery etc, which get imaged properly, but when it gets to the main partition about 16+ GB it tears text into the partimage interface screen, supplies a code which I need to type in here when i get a chance, and then asks if the fog server has run out of space, which it hasn’t because it has nearly 2 TB of space on its drive. then reboots.
some info:
The FOG Project Server I have is fully installed on the machine instead of a VM. The OS is Linux Mint 19.2 Mate, which works and has worked perfectly otherwise until this imaging attempt…
The FOG project build has been upgraded to trunk but it is older than the absolute current build, will upgrade it later when i dig into it, but it was upgraded about 2 weeks ago.I am however posting this to see if this is a general or known issue before really digging into it.
The server currently has 5x Win 10 v1909 images on it that work fine and are current with updates from early January 2020. 2x new cumulative updates came out this week for v1909, one is a .net updater, and the other is general cumulative updates.
I try to keep 4 of those images very simple and clean having only updates from microsoft and some basic applications like chrome / firefox.
Does the new Win 10 cumulative updates fiddle with the MBR? or cause windows 10 to not be imaged properly via FOG?
Next steps i plan to try are updating one of the older images instead of making a clean image and see if that images fine.
Then i can see if installing and imaging via Legacy (Non-UEFI) works any differently.
And at some point I can ofc upgrade to current Git Trunk and see if that affects anything.
I also realize the issue could be with the possible space issue, or permissions issue, but I did create that 5th image just last week a non-uefi image for a batch of 50x old dell E5420s, which works perfectly,
-
@ProfDrSir you will also get this behaviour if the permissions and/or ownership on the image share are incorrect. was the error “segmentation fault. possibly due to run of disk storage?”
if so, on server/node you’re capturing the images to
try:
chown -r fogproject.root /imagesor
chown -r fog.root /imagesdependant on what version of fog you are on.
then re-run capture
-
This post is deleted! -
We often see images failing to capture after installing certain updates. Though typically these are version point upgrades.
Do you use sysprep for your images?
Sometimes it can be resolved by cleaning up the system and such.
(eg
dism /online /cleanup-image /startcomponentcleanup) -
@Quazz I used to use sysprep, but started to use fresh installs and a simple guide to clean up the system, the biggest cleanup parts are just in using the cleanup drive tool, the resulting win 10 images on fog are only 16 - 17 GB, and it only takes a few minutes at most, seemed faster and simpler than sysprep. But I’ll check out your link, always fun to learn or re-learn other methods.
I’ll try out your CLI suggestion though, and see how that goes…
-
@ProfDrSir Ideally you’d use both! Sysprep does more than what the cleaning tool can do.
-
@Quazz is it going to make that big a difference for a fresh install though? the guide I’ve been using is this one: http://web.sas.upenn.edu/jasonrw/2016/03/01/how-to-create-a-windows-image-for-mass-deployment
But just the capturing image segment.
Additionally I want to keep the newly installed app links on the desktop.
If sysprep doesn’t result in much of a smaller image overall than a fresh install + update then it won’t be a priority for me anyway, just extra work.
I used sysprep for my images up until Windows 10 v1809, then just started using that guide as it takes less than 3-5 minutes to prepare the environment post update and the image size has been within 1GB difference.
-
@ProfDrSir you will also get this behaviour if the permissions and/or ownership on the image share are incorrect. was the error “segmentation fault. possibly due to run of disk storage?”
if so, on server/node you’re capturing the images to
try:
chown -r fogproject.root /imagesor
chown -r fog.root /imagesdependant on what version of fog you are on.
then re-run capture
-
@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…
