Error trying to restore GPT partition when deploying Image to smaller drive, Error Return Code: 4
-
I’m having trouble getting my resizable image to work on smaller drives. It’s about 45GB total and setup on a VM with a dynamically expanding HDD set for 500GB (~465GB base-2).
It only shows up when deploying on smaller drives (even those labeled as 500GB, but I think the usable (base-2) space is a little less). I’m testing it on another VM with a 128GB dynamic HDD.
--------Here’s my info--------
Golden Image
- Windows 10 ver2004
- UEFI/GPT
- Fresh install (windows installer/or through Windows Update/grade)
- 4 partitions (EFI, Reserved, Windows, Recovery)
FOG Installation
Ubuntu Server 18.04.5 LTS
1.5.9-RC2.11
bzImage Version: 4.19.123
bzImage32 Version: 4.19.123Image Info
fixed_size_parts1:2minimum.parts
label: gpt label-id: 60C1AD92-592D-4318-B576-C3591A345666 device: /dev/sda unit: sectors first-lba: 34 last-lba: 977272798 sector-size: 512 /dev/sda1 : start= 2048, size= 1021952, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=981988EA-AC00-40AF-BA82-EE611393B7F5, name="EFI system partition", attrs="GUID:63" /dev/sda2 : start= 1024000, size= 262144, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=83F97CA4-C157-4F04-85F7-5A8444119211, name="Microsoft reserved partition", attrs="GUID:63" /dev/sda3 : start= 1286144, size= 74770610, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=627BF0E9-B41A-4554-B3EB-E116897D7073, name="Basic data partition" /dev/sda4 : start= 967507968, size= 43370, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE6D871E-AD70-41AE-8986-698E993FE369, name="Basic data partition", attrs="GUID:63"parts
label: gpt label-id: 60C1AD92-592D-4318-B576-C3591A345666 device: /dev/sda unit: sectors first-lba: 34 last-lba: 977272798 sector-size: 512 /dev/sda1 : start= 2048, size= 1021952, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=981988EA-AC00-40AF-BA82-EE611393B7F5, name="EFI system partition", attrs="GUID:63" /dev/sda2 : start= 1024000, size= 262144, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=83F97CA4-C157-4F04-85F7-5A8444119211, name="Microsoft reserved partition", attrs="GUID:63" /dev/sda3 : start= 1286144, size= 966221824, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=627BF0E9-B41A-4554-B3EB-E116897D7073, name="Basic data partition" /dev/sda4 : start= 967507968, size= 9762816, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE6D871E-AD70-41AE-8986-698E993FE369, name="Basic data partition", attrs="GUID:63"fstypes
/dev/sda3 ntfs /dev/sda4 ntfsError
* Restoring Partition Tables (GPT)..................Failed * * Press [Enter] key to continue * Creating new GPT entries in memory. * Warning! Current disk size doesn't match that of the backup! * Adjusting sizes to match, but subsequent problems are possible! * * Warning! Secondary partition table overlaps the last partition by * 699115915 blocks! * You will need to delete this partition or resize it in another utility. * * Problem: partition 4 is too big for the disk. * Aborting write operation! * Aborting write of new partition table. * Find the detailed error message above this line. Use Shift-PageUp to scroll upwards. * ############################################################################## * # # * # An error has been detected! # * # # * ############################################################################## * Init Version: 20200517 * Error trying to restore GPT partition tables (restorePartitionTablesAndBootLoaders) * Args Passed: /dev/sda 1 /images/VAGMaster 9 all * CMD Tried: sgdisk -gl /images/VAGMaster/d1.mbr /dev/sda * Exit returned code: 4 * * Kernel variables and settings: * bzImage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://10.99.199.22/fog/ consoleblank=0 rootfstype=ext4 nvme_core.default_ps_max_latency_us=0 mac=00:15:5d:e9:47:06 ftp=10.99.199.22 storage=10.99.199.22:/images/ storageip=10.99.199.22 osid=9 irqpoll hostname=PXE_test chkdsk=0 img=VAGMaster imgType=n imgPartitionType=all imgid=4 imgFormat=5 PIGZ_COMP=-4 hostearly=1 isdebug=yes type=downDebug
sgdiskCreating new GPT entries in memory. Warning! Current disk size doesn't match that of the backup! Adjusting sizes to match, but subsequent problems are possible! Warning! Secondary partition table overlaps the last partition by 699115915 blocks! You will need to delete this partition or resize it in another utility. Problem: partition 4 is too big for the disk. Aborting write operation! Aborting write of new partition table.fdisk
GPT PMBR size mismatch (977272831 != 268435455) will be corrected by write. Disk /dev/sda: 128 GiB, 137438953472 bytes, 268435456 sectors Disk model: Virtual Disk Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sda1 1 268435455 268435455 128G ee GPT Partition 1 does not start on physical sector boundary.sfdisk
GPT PMBR size mismatch (977272831 != 268435455) will be corrected by write. label: dos label-id: 0x00000000 device: /dev/sda unit: sectors sector-size: 512 /dev/sda1 : start= 1, size= 268435455, type=eegdisk
GPT fdisk (gdisk) version 1.0.4 Partition table scan: MBR: protective BSD: not present APM: not present GPT: not present Creating new GPT entries in memory. Disk /dev/sda: 268435456 sectors, 128.0 GiB Model: Virtual Disk Sector size (logical/physical): 512/4096 bytes Disk identifier (GUID): D595642A-3893-4A85-B4A6-CDDCEC1CD04F Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 268435422 Partitions will be aligned on 2048-sector boundaries Total free space is 268435389 sectors (128.0 GiB) Number Start (sector) End (sector) Size Code NameGetting it “working” (not ideal)
The solution, or workaround, I have found is to delete that 4th partition. The recovery volume, and merge it with the primary C volume. Then no GPT error on any smaller size drive. However, I don’t think is a great solution. I would prefer not to delete the recovery partition as it can be useful. Plus Windows apparently re-adds it with major updates. I had to do this before as it’s been happening since I believe FOG 1.5.6 (https://forums.fogproject.org/post/124538)
Refrence
https://forums.fogproject.org/topic/13220/error-trying-to-restore-gpt-partition-deploying-an-image-to-smaller-disk -
@drumnj The only option I see from a FOG’s point of view is that we ignore the “won’t move the starting point of a special partition” restriction for those Recovery Partitions. As far as I know this will definitely break recovery on legacy BIOS systems unless we do some really fancy and error prone boot loader re-writing which I am not fond of at all.
UEFI based installs are a different story. Those might work without boot loader manipulations. Though I am not sure. Would need testing.
@george1421 @Quazz @Tom-Elliott what do you think?
-
I’m sure you guys have noticed a lot of these posts showing up. Any thoughts on doing like an announcement pertaining to this issue or some kind of mega-thread to address those having problems?
-
@drumnj I am sure you have read all those posts top to bottom and seen that quite often they are not all describing the exact same issue.
Sure the Recovery Partition thing might be a common one but I don’t think a mega-thread with everyone posting details will lead us to a general solution unless we have a full unterstanding of this.
-
@drumnj By the way, I may phrase point about UEFI more directly. Is your image UEFI based?
-
This post is deleted! -
@Sebastian-Roth said in Error trying to restore GPT partition when deploying Image to smaller drive, Error Return Code: 4:
@drumnj I am sure you have read all those posts top to bottom and seen that quite often they are not all describing the exact same issue.
Sure the Recovery Partition thing might be a common one but I don’t think a mega-thread with everyone posting details will lead us to a general solution unless we have a full unterstanding of this.
If it’s the only solution that is consistently given out, is there really a difference?
So it’s a negative having multiple data points in one location where you guys can potentially say…“Everyone with this problem post your d1 parts file(s).” Giving you a lot of data where you could see a trend. Could even use it to seek out those with successful images (who may have a recovery partition) and get their info.@Sebastian-Roth said in Error trying to restore GPT partition when deploying Image to smaller drive, Error Return Code: 4:
@drumnj By the way, I may phrase point about UEFI more directly. Is your image UEFI based?
@drumnj said in Error trying to restore GPT partition when deploying Image to smaller drive, Error Return Code: 4:
--------Here’s my info--------
Golden Image
- Windows 10 ver2004
- UEFI/GPT
- Fresh install (windows installer/or through Windows Update/grade)
- 4 partitions (EFI, Reserved, Windows, Recovery)
-
@drumnj I have to say sorry! Have been flat out jumping between jobs and not following this to the point.
Sure collecting the data could be helpful, if we know for sure this data (d1 files) is actually providing all we need to know. As well someone needs to sit down and sort through all the data and find a solution and I can’t see me doing this these days. While FOG Project is not just me, I have to say that the dev team is very small at the moment as very little people join in to work on this project. We can only do as much as time provides.
Be assured this topic is present and we are discussing things already. Though I can’t promise you a quick solution yet.
-
@Sebastian-Roth Overall the current solution isn’t bad, so no real rush to figure out. I just think it isn’t the best solution. I suppose another option for people is to always make a golden image on a drive smaller than any other drive they plan to deploy to. Doing this I have found does allow the recovery partition to be used (did this with 2004 to make a clean OOBE Win10 image…with Chrome included).
-
@drumnj said in Error trying to restore GPT partition when deploying Image to smaller drive, Error Return Code: 4:
@Sebastian-Roth Overall the current solution isn’t bad, so no real rush to figure out. I just think it isn’t the best solution. I suppose another option for people is to always make a golden image on a drive smaller than any other drive they plan to deploy to. Doing this I have found does allow the recovery partition to be used (did this with 2004 to make a clean OOBE Win10 image…with Chrome included).
That works, but I believe you run into the problem of being unable to expand the size of the Windows partition itself since the recovery partition is blocking it.
I’m not sure how to resolve this at the moment, personally I don’t use recovery partitions, they don’t really offer that much in my experience, though of course in some environments they may be desired or needed, so a solution would be ideal.
-
@drumnj I know it’s been a long time but have not found enough time to work on this earlier. We now have a first version of init.xz capable of capturing and deploying a Windows 10 2004 UEFI/GPT install with recovery partition at the end. Would you give that a try.
Please be aware this is still in kind of a pre-release phase. Make sure you have a backup of your original image as well as the machine you pull the master from, just in case!!
-
@sebastian-roth Sebastian, I’m having this same issue and would like to try with the init.xz. How would I go about doing so?
-
@Brendan-Clemente Here are the steps I recommend when testing with this:
- Make sure you have a working backup copy of your master (just in case something goes wrong when capturing) or deploy your current image to an identical machine and use that as a test capture machine for this.
- Download the init file and put that in
/var/www/html/fog/service/ipxe/on your FOG server. - Create a new image definition for testing
- Decide which hosts you use for testing capture and deploy with this new init, edit their hosts settings in the FOG web UI and set **Host Init" to
init-201114.xzas well as the newly created image. - Schedule a capture task and pay attention to the boot process where it says
bzImage..okandinit-201114.xz..okto make sure it actually uses the new init file. - Schedule a deploy task for a machine with a smaller size disk and deploy to it. Again make sure it says
init-201114.xz..okwhen booting.
-
@sebastian-roth Great, that seemed to have worked perfectly. I was able to capture and deploy my image now and confirmed that it used the new init-201114.xz. Thank you very much.
-
@Brendan-Clemente So were you able to capture from a larger disk and deploy to a smaller size disk? Is it Windows 10 2004 you use?
-
@sebastian-roth Yes, I was able to capture and deploy to a smaller disk but it was Windows 10 20H2, the newest version, that I used.
I am currently building a 2004 master machine though as we are having issues with our exchange server on the new 20H2 build. I will be capturing and deploying that image today. I’ll let you know the results.
-
@drumnj said in Error trying to restore GPT partition when deploying Image to smaller drive, Error Return Code: 4:
Current disk size doesn’t match that of the backup!
Was this issue ever fixed? I am having the same issue with 20H2. I don’t want to have to delete the recovery partition.
-
@UWPVIOLATOR Please open a new topic and post all your details there. FOG version currently used, contents of partition layout files as seen in the Initial post, installation of the client being UEFI or legacy BIOS?
I think we might have a solution for you but want to make sure it suites you.Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@sebastian-roth I missed the part where I had to reupload the image after updating the Init file. I am good now.
-
Hello there, any news about this problem ?
