Imaging from large drive to small drive
-
@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.
-
@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!
-
@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.
-
@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. -
@sebastian-roth Oh I have to recapture the image? I thought the dev-branch version of FOG would take care of the resizing?
-
@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?
-
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.
-
@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? -
@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. -
@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"
-
@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
andd1.mbr
of that image you want to mess with! - Edit
d1.minimum.partitions
, remove that line starting withlast-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 ofx.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.
- Make a backup copy of
-
@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. -
@brakcounty said in Imaging from large drive to small drive:
I am assuming that this would have to be done for each image.
Correct.
-