tight system partition
-
I can’t seem to search the forums (404?) so I’m, just posting today’s fun.
edit: search works again, yet I’m not sure I want to delete the postI tried to upgrade a deployed drive image from win10: 1803 to 1809 today. It told me my system partition was too small. Well it was quite small at 37MB. I’m guessing it was shrunk from the typical 100MB on capture and not inflated at deployment, but I can’t be sure. At any rate, the ensuing resize/raw FS/convert-to-NTFS fun landed me back at a redeployment of the same image that produces the small system partition.
Maybe I’ve missed the setting, or I’m using FOG in an A-typical way, but this could be an issue for quite a few.
If anyone has any thoughts on how to avoid/remedy the issue, I’d be happy to hear it.
-
Edit the images d1.fixed_size_partitions and add
:1to the line. -
Just to be clear, as I’ve not fiddled with these files directly before, we are talking about image files from a host previously captured? Further, entering “:1” in this image file means that, upon deployment, it will inflate the first partition to it’s original (at time of capture) size?
-
@geardog whatever image you’re seeing the problem with, and yes. It won’t “inflate” per say but will use the original partition size when the sizes are being checked and adjusted.
-
@geardog said in tight system partition:
I’m guessing it was shrunk from the typical 100MB on capture and not inflated at deployment
FOG detects this kind of system relevant partitions and doesn’t resize those usually. Not saying that this cannot happen but in case of FOG shrinking a partition I cannot see why it wouldn’t grow/inflate that partition unless you modified the image information manually (as suggested by Tom).
As we don’t know which FOG version you currently run and which version was used to capture the image in the first place it’s more or less guessing in the dark. Up until now we have not had any reports on this and I can’t see this being a general problem for others as well. Not that it’s impossible but we haven’t heard of it at all yet.
If you can give us more information on where exactly this happens and which FOG version was used we are surely able to help and fix this.
-
@Sebastian-Roth
Good points.
I haven’t kept logs that would detail which version of fog I was on. It could be that the drive was initially that size when captured, but that is an odd number (37MB). This particular image has probably been deployed, updated, used, and recaptured meaning it has been passed through various versions of fog. This is surely asking for it, but I’ve yet to find a workstation backup method that gave me the fuzzies. -
@geardog So is there anything we can do for you? I don’t want to sound like “this is not our business” but it’s very hard to try and dig up what was causing this.
-
@Sebastian-Roth
No no, you’ve made clear that it is a lost cause trying to sort this out. If I had a clean capture and deploy on this version showing the system partition shrinking it would be different. Your comments made that clear. Thanks for the help.
