Resizable Image won't deploy to smaller HDD
-
I have an image that was created on a 500GB HDD, uploaded as a resizable image. I was under the impression that a resizable image had the ability to be deployed to smaller drives than that of the original drive/ partition that it was created on. Yet, one laptop out of thirty happens to have a 320GB HDD and will not accept this image; I receive the error “Target partition size is smaller than source.” It is not random and happens every time I attempt to deploy the image to this specific machine. I do not have any spare drives to replace it with, so I’d like to just be able to image to the current 320GB drive.
Image was created on stable v1.4.4. I have updated to stable v1.5.0 since, but the issue has not changed.
I have read other threads about this issue. One thread stated that adding a 1 to d1.fixed_size_partitions could help on smaller drives, but I’m not sure where the file is, but the image is also not a fixed size image.
-
@zpoling Cool. Often times a re-capture fixes these mysteries. FOG is fairly consistent in it’s behavior, so most times - the mysteries are user error in some way or another. Let us know how it goes.
-
@zpoling For an image to be resizable, it has to be captured as resizable. Also, the used space on the resizable image must be able to fit on any disk it is deployed to.
-
@wayne-workman The image was captured as resizable, as far as I know. When I created the image, I chose single disk-resizable. As far as used space, this is the size of the image, right? It is only ~18GB.
I have no idea what happened to the image. It is now reporting on the GUI that there is no data for the image, but I imaged with it this morning. I’ve even imaged with it since I first had this issue… I am at a loss. I haven’t tried any reuploads to that image.
Maybe the image was just jacked up. I have a similar image, it’s the same exact one without Microsoft Office, and it images fine on the 320GB. Both images were made on the 500GB drive, both were created and uploaded as resizable, but only one works while the image in question still gives that error (assuming because of the 0.0GB of data). Not sure why the image data would suddenly disappear.
-
@zpoling said in Resizable Image won't deploy to smaller HDD:
As far as used space, this is the size of the image, right? It is only ~18GB.
No. There’s image size - which is the amount of space the image is using on your FOG Server - this is it’s compressed size. When I say used space, I’m referring to the amount of used space on the golden machine’s disk before capture. That used space has to fit on any destination disk you try to deploy it to, or the process will fail.
-
@wayne-workman So ideally, an original image should be created on the smallest possible HDD?
-
@zpoling said in Resizable Image won't deploy to smaller HDD:
@wayne-workman So ideally, an original image should be created on the smallest possible HDD?
Nah, it shouldn’t matter. Best practices is to defrag 3 to 5 times before capture though. It makes resizing a whole lot faster.
As far as this image is concerned though and your problem, did the image previously exist, and you captured over the old one?
-
@wayne-workman Ah, so used space isn’t the size of the original drive/partition, but literally the used space. That makes much more sense.
I’m still not sure what happened to the image :/. I haven’t captured at all, I’ve only been multicasting. The 320GB failed but the other four laptops imaged just fine. I tried deploying to that specific laptop a few more times just to see if it was a consistent issue or not. Once we started talking, that’s when I noticed that the image suddenly showed 0.0GB of data.
I’m going to rebuild it off the other other image I mentioned. I’m building it again on one of the 500GB, but then I’ll upload it and try to deploy it to the 320GB and see what happens. Thank you for clearing up those terms for me.
-
@zpoling Cool. Often times a re-capture fixes these mysteries. FOG is fairly consistent in it’s behavior, so most times - the mysteries are user error in some way or another. Let us know how it goes.
-
@wayne-workman A re-capture did indeed fix the issue. I guess the biggest issue was just not understanding the verbiage.
Thanks for your help explaining things.Onto the next issues!
-
Before this thread dies, I just want to mention how much better the newest Fog Client has been. The version offered with v1.4.4 always gave us issues of not restarting the computers correctly after imaging, resulting in needing a few manual restarts. Sometimes it wouldn’t join the domain or change the hostname properly either. v11.15 has been not shown any of these issues and has worked flawlessly for us so far!
