All disk capture unable to deployed to two larger disks
-
I took the capture of a Windows 10 system with a 40gb primary hard drive and a 10gb data drive. It appears that if I deploy this image to a machine that has the same sized disks, the deployment is successful. However, when trying to deploy this image to a machine that has larger disks (50gb/20gb), the deploy fails.
When capturing an all disks image, is it only possible to deploy to a machine with the same size disks?
-
So does this system have multiple disks? I’m seeing references to sda and sdb in the picture. In theory you can setup a single disk non-resizable and deploy a 40GB to a larger disk no problem, you will just not be able to use any of the space beyond the 40GB of the original disk (said knowing you can extend the partition in Windows after the fact).But I think what is getting mixed up is either the source or destination system has multiple disks. On the source are you capturing more than one drive? Does the destination system have the same number of drives and all of the drives are the same (exact) size or larger?
-
In my case both the source and destination systems have multiple disks.
Deploying the image to a destination system with multiple disks that are the same size as the source system works.
Deploying the image to a destination system with multiple disks that are larger than the source system fails.
The source system for the image has a 40gb disk and a 10gb disk. The error in the screenshot occurs when I try to deploy to a destination system that has a 50gb disk and a 20gb disk.
-
@samdoan said in All disk capture unable to deployed to two larger disks:
Deploying the image to a destination system with multiple disks that are larger than the source system fails.
From the error message you posted I am not sure it’s fails because of the disks being larger.
Please check the files in your images directory on the FOG server
/images/2DriveTest
to see if you have files named.size
in there.ls -al /images/2DriveTest
EDIT: Taking a closer look at the scripts I see that we have a bug in those. The size information of the disks was added to the “multiple disk” mode because we were trying to help someone using two NVMe drives that would swap position on every boot (just a thing with NVMe drives).
Let me see… I think as a quick fix you should be able to make it work by removing the size information files.
mv /images/2DriveTest/*.size /tmp
Then try deploying the image again.
-
@samdoan I’ve worked on fixing this issue in our FOS scripts. Works great in my test environment but would be good if you could give it a try as well. The problem is that our build server is down at the moment.
Maybe @george1421 can build an init.xz binary from the latest fos repo for you to test?
-
@Sebastian-Roth I pulled the latest FOS files from the github repo and built this: https://drive.google.com/open?id=1eHF9HlTEGlWPYXpfcmvuV0CcqCIV1pyr
I confirmed that the bin files were updated. One note, you have to remove the 0.2.89.x patch or partclone.0.3.12 will not build correctly (it could have been residue from a previous build too). Once the patch was removed and the build restarted it completed without error.
@OP Download the new init and save it as initFIX01.xz (watch your case, because it is important) and move it to the fog server in
/var/www/html/fog/service/ipxe
directory. Go into the host definition for the one in question and enterinitFIX01.xz
for the init field parameter, save the host definition and then schedule a new capture/deploy task. PXE boot the target computer, if you look quickly you will sett it transferbzImage
and theninitFIX01.xz
to the target computer then start FOS Linux. As long as you seeinitFIX01.xz
being downloaded then it should be running the updated scripts that Sebastian created. -
Ok, build server is back up and I finally got to update the official init files on https://fogproject.org/inits/…
@george1421 said:
One note, you have to remove the 0.2.89.x patch or partclone.0.3.12 will not build correctly (it could have been residue from a previous build too). Once the patch was removed and the build restarted it completed without error.
The old patch was removed some time ago (ref) and I guess this was a hickup in your build environment.
@samdoan Any chance you can test the new inits?
-
@Sebastian-Roth said in All disk capture unable to deployed to two larger disks:
The old patch was removed some time ago (ref) and I guess this was a hickup in your build environment.
Yes I found out a bit after that post, I just over laid the new files over the existing path because I’m building the inits using a different method than the build script. Sorry that was my mistake.