Imaging from large drive to small drive

DBCountMan

I think this has been talked about before but I am trying to understand something. This is how I have my image set up on FOG:

This image was created from a 500GB drive and we are trying to deploy it to a 256GB drive. The error message that pops up says that partition 4 is too large, and the actual file size for that partition is 140KB. Now when I use Acronis for example, I have been imaging smaller drives using images that were created from larger drives. Why can’t FOG do the same?

george1421

@brakcounty If I had to guess, is that Microsoft moved the recover partition to be after the “C” drive partition. The recover partition is marked non resizable, so its starting block is beyond the end of the 250GB disk.

As a test on your golden image computer, remove the recovery partition on the end, capture the image and then deploy. I also think the developers have fixed this issue in the dev branch of 1.5.9. It was a change that MS did after 1.5.9 was released.

DBCountMan

@george1421 Ah okay makes sense. I have a secondary FOG server to test the 1.5.9 dev branch. In the meantime I will my staff know about this. Thanks!

DBCountMan

@george1421 So I updated to the latest dev branch on my secondary FOG server using these instructions https://github.com/FOGProject/fogproject/tree/dev-branch and got the same error:

Guess it wasn’t fixed.

Sebastian Roth

@brakcounty It is fixed in dev-branch.

Did you re-capture the image on the dev-branch server?

If you did, then we need to see the contents of d1.minimum.partitions from that freshly captured image.

DBCountMan

@sebastian-roth Oh I have to recapture the image? I thought the dev-branch version of FOG would take care of the resizing?

Sebastian Roth

@brakcounty Well it does need to do the right things in capture to be able to deploy the new Windows partition layout to a smaller size disk. What’s the issue with deploying the image to a large disk and re-capturing it?

DBCountMan

Well capturing may be an issue since we don’t really have “golden hdd’s” with master images. We’d have to recreate the images from scratch OR find same size HDD’s as the image to deploy then recapture. We’d have to do it to 20+ images which time consuming.

You said the issue was fixed in the dev-branch, and that we’d have to recapture every image for the fix to be useful. Correct? I just want to make sure I understand what to do and how to move forward.

george1421

@sebastian-roth Can the OP, by hand, tweak the d1.minimum.partitions file to fix/work around the issue? Or did the update make structural changes to the files?

Sebastian Roth

@george1421 said in Imaging from large drive to small drive:

Can the OP, by hand, tweak the d1.minimum.partitions file to fix/work around the issue? Or did the update make structural changes to the files?

From the top of my head I would say it’s possible to manually adjust the files. Though I have not tried that yet! One very important thing is the images need to have a GPT partition layout. MBR layouts would break I reckon.

@brakcounty As requested before, please post the contents of the d1.minimum.partitions file from one image you want us to try out.

DBCountMan

@sebastian-roth
cat /images/DOHWIC_7450AIO/d1.minimum.partitions

label: gpt
label-id: 665ED030-2751-4506-B81A-D098A006B220
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 976773134
sector-size: 512

/dev/sda1 : start=        2048, size=     1024000, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=93F996F2-F2D7-4086-87CD-765BF2355148, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=     1026048, size=      262144, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=7A4B87F6-F8A8-4A6B-A90E-3445738EC128, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=     1288192, size=    45294648, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=30391013-A07B-4662-8088-8082ABF79A72, name="Basic data partition"
/dev/sda4 : start=   967014400, size=       96256, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=9F46892D-941F-430E-BA27-F56630C6B02F, name="Basic data partition", attrs="RequiredPartition GUID:63"

Sebastian Roth

@brakcounty Didn’t say it would be easy, did I??

FOG uses text based partition layout files (e.g. the one you posted) as well as a binary copy. Messing with the text file is easy but less so with the binary file! Unless you are keen to use hexedit to change the binary file I’d advice you follow the steps as outlined.

Make a backup copy of d1.minimum.partitions and d1.mbr of that image you want to mess with!
Edit d1.minimum.partitions, remove that line starting with last-lba: ... and also change /dev/sda4 : start= 967014400, ... to /dev/sda4 : start= 46583808,. Note: This is not in general for all your images as each partition layout is different. I will give more general instructions later.
Copy that changed d1.minimum.partitions to /images/dev/ as we need it there too in a moment.
Schedule a debug deploy task for one host that you want to deploy this image to and PXE boot it.
Hit ENTER twice to get to the command shell and manually mount the /images/dev directory on your FOG server via NFS: mkdir -p /mnt && mount -o nolock,proto=tcp,rsize=32768,wsize=32768,intr,noatime x.x.x.x:/images/dev /mnt (use your FOG server IP instead of x.x.x.x)
Find out what the local disk is named on this computer by running lsblk (usually /dev/sda or maybe /dev/nvme0n1) and use that with the following commands.
Clean the current partition table on that computer: sgdisk -Z /dev/sda
Deploy the modified partition layout: sfdisk /dev/sda < /mnt/d1.minimum.partitions
Grab a binary copy of that new partition layout: sgdisk -b /mnt/d1.mbr /dev/sda
Leave that machine for now and go back to your FOG server. Move the created /images/dev/d1.mbr file over to the correct images folder (the one you started with backing up the two files).
Ok, now once again back to the machine and start deploying as usual by issuing the fog command.

DBCountMan

@sebastian-roth Nor did I assume it would be!
I haven’t tried any of this yet, but I am assuming that this would have to be done for each image.

Sebastian Roth

@brakcounty said in Imaging from large drive to small drive:

I am assuming that this would have to be done for each image.

Correct.

Imaging from large drive to small drive

162

12.0k

17.3k

155.2k