Posts made by ProfDrSir

My workaround that has worked so far was to make the source image drive small, 28GB in my case, and it seems to always work now so long as the target drive is bigger, a complication with the last partition not wanting to be any closer to the beginning of the drive as it was on the source disk (i think), but it can be further away with no issues:

https://forums.fogproject.org/topic/14571/imaging-windows-10-v2004-with-uefi-gpt-partitions-onto-31gb-or-smaller-drive-and-failing/3

Alrighty, so my work-arounds for this issue were to use a virtual drive of 28GB to make the original image, alternatively you can delete the 4th partition to make imaging completely compatible, but you lose the ability to do an OS reset in Windows.

If you move the partition to where it used to be in v1909, Windows can’t find it and that also loses the ability to reset, so if you have to move it, just delete it i guess…

another alternative if using clonezilla you can image and use gparted to first move the 4th partition to the end of the drive, then resize the 3rd partition, this seems to work fine without losing the option to reset, tested on 2 different machines, a Clevo Laptop and an HP All in One.

Otherwise typically just make sure the drive you are imaging to with FOG is generally larger than the source disk you imaged from and everything should be fine… generally speaking…

@george1421 interesting, Your setup sounds great for support of a large company with varied users.

@george1421 which fat standard are you using? and what other benefits come from using it?

@george1421 I’ll be excited to see your results! if we can just remove / ignore that 4th partition it makes imaging slightly more tedious, but functionally should be the same as before I’d assume.

I also noticed that upgrading older v of Windows 10 on Dells with the new Bios sometimes breaks Windows… X-D which has required me to image the SDD in another machine before v2004 will run on the newer Dells… FYI.

Well one experiment I’ve done with clonezilla seems to work for imaging, I restored the image onto a bigger drive, which ofc leaves all the extra unallocated space after the partitions.

I then move the last partition, telling it to leave 1MiB after

Then resized sda3 to take up the remaining space:

Seems to leave a random 1MiB after sda4, but this still works sometimes and windows loads up without issue, I think it’s because the positioning of sda4 is taken seriously by Linux, but microsoft / windoze has always been lazy with how it uses it’s partitions, especially concerning location, (ofc other than the boot partition) leading me to think the positioning of this partition as George suggested might not be all that important, but I still have to wonder what the hell it’s purpose is… I have seen GParted fail when trying to move this partition to other locations though, specifically when I was trying to manually build a smaller image, the apply steps would fail when manipulating that 4th partition.

I don’t know if this’ll help anyone or anything, but it gives me a path forward on the thumb drive image side of things anyway. Maybe I’ll prep as small a drive as I can get away with then use that and see where it gets me with FOG.

@sudburr Yeah it’s definitely all connected to the same issue pertaining specifically to Win10 v2004. I do wonder about the thinking behind this change… the “why”.

@george1421 Yeah it has been problematic, that last partition also seems to be custom sized by win10 2004 and places it purposely at the end of the drive, almost like it’s written backwards from the end, which gparted doesn’t like. I was trying to manually copy partitions to a smaller drive but gparted habitually leaves 1 MB of unused space after the last partition, which seems to ‘break’? this goofy tacked on partition.

But I’ll test what you posted and see what happens.

The golden image in this case was created on VMware workstation 15.5, but I’ve done a few test installations on a Clevo P157SM-A, the weird thing tho, the new windows v2004 iso will install a v1909 on a lot of older hardware. The new v2004 has been an odd duck of an update insomuch as how it installs.

In reference I had an old AiO that wouldn’t upgrade to 2004 and had this to say about it:

The update from an older v to 2004 also has 2x phases, I assume 1 is to place that partition on the end of the drive.

One thing I did notice, was the VMware Virtual drive is 60GB, so like you said that partition, if attached will require it be stuck somewhere specific on the drive… meaning the 60GB was because the golden image was built on a 60GB? … so basically whatever image I author will always require that size as a minimum to be able to image it properly…

I did make a test build on a virtual 30GB drive, but it failed to image to a 32GB SSD…

So here’s what the Windows 10 v2004 HOME - Non-UEFI partition looks like in GParted:

3 partitions, images and fits snugly on a 28GB HDD.

Then here’s the HOME - UEFI version:

4 partitions, but through FOG requires a 60GB+ HDD.

Other additional info:

I am currently using Virtualbox to pull the FOG image onto the virtual HDD then using PartedMagic + Clonezilla to create the final image. This could be an issue with this new image + FOG + VirtualBox, but it still only affects the UEFI images of v2004.

I will try with larger Virtual Drives and report back the results.

=>

So I was wrong about the UEFI partitions, it doesn’t add a partition to the UEFI, but it does move a 4th partition AFTER the main one. I do know it adds a partition to the non-EFI image tho. Here’s a screenshot from Gparted from a successful image to a 64GB Virtual Drive, I’ll keep testing and see how small the drive can get before it trips over itself:

Notice ~54GB isn’t used of this 64GB drive, suggesting we’d only NEED 12ish, (I know win 10 wouldn’t function in such a small space, but I’m just pointing out the issue is with the imaging, not the size of the HDD itself.)

I’ve found that this works with a virtual HDD of 60GB+ but anything less than 60GB has that error, even a Virtual HDD of 59GB won’t work, suggesting FOG could possibly be incapable of deploying a Win10v2004 UEFI image on any drive smaller than 60GB in size unless some code tinkering is done.

@george1421 info incoming, it is perfectly possible, this is just a new issue pertaining to v2004, this still works with Non-UEFI Win 10 v 2004, and with UEFI on any v1909 or older Windows 10 release, so this suggests HDD size can’t be the issue. I’ll get some images up shortly tho, thank you for the quick response!

Ok, to set the stage:

Using FOG Stable 1.5.8, I have 4 Windows 10 v2004 Images: 2x HOME 2x PRO, 1 of each Legacy / Non-UEFI and 1 of each UEFI.

They were created using the Microsoft Windows 10 v2004 iso (current image as of this typing) and they image perfectly fine to larger drive computers without issue.

The issue I have is a portable image I make for use on thumb drives with Parted Magic / Clonezilla, I’ve been making these images since Windows 10 v 1809 onto VM drives that are 28 GB in size. (So I can image onto drives that are 32GB etc on machines without an Ethernet Port or for other situations, then just use Gparted to resize the main partition)

This actually still works with the Non-UEFI Win10 v2004 images, but not with the UEFI versions. I am fairly certain this is due to the v2004 adding a partition to both versions, Legacy up from 2 partitions to 3, and UEFI from 4 partitions to 5.

The error I believe comes in when FOG has to re-juggle the new partition in with the mix then accidentally overlaps another partition. Since the new version just haphazardly adds a partition it is probably mucking up some FOG code that could normally handle it, but the smaller size HDD just causes it to give up, but I’m still certain <31GB is plenty space for the UEFI image, but how to make it work? Or will this require some sort of adjustment in later versions of FOG?

Now I know my situation is unique, but it still spells incompatibility with FOG and imaging win 10 UEFI v2004+ onto devices with drives =<32GB in size.

In other news I know I can use the advanced clonezilla menu to work around this, but I’d love to hear any other suggestions for rebuilding a working UEFI image onto a drive <32GB with parted magic or other tools that will allow the same functionality.

Thank you guys in advance!

@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…

@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.

@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…

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,