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.123

    Image Info
    fixed_size_parts

    1:2
    

    minimum.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 ntfs
    

    Error

     * 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=down
    

    Debug
    sgdisk

    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.
    

    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=ee
    

    gdisk

    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  Name
    

    Getting 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


  • Moderator

    @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.



  • @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).


  • Senior Developer

    @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 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)


  • This post is deleted!

  • Senior Developer

    @drumnj By the way, I may phrase point about UEFI more directly. Is your image UEFI based?


  • Senior Developer

    @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.



  • 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?


  • Senior Developer

    @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?


Log in to reply
 

285
Online

7.4k
Users

14.5k
Topics

136.5k
Posts