Error trying to restore GTP partition tables (restorePartitionsTablesAndBootLoaders)

[Tom Elliott]

@stormbyte when you get a chance, can you please update again and let us know if things are the same or fixed? I’m fairly sure they’re not fixed, but I’m not certain either.

Another “trick” we could try is to add to the d1.fixed_size_partitions with a :1 to the end of the line in the file.

[stormbyte]

@Tom-Elliott Tom, I’ve updated but the problem is exactly the same … I’m ready to try your other suggestion!

[stormbyte]

@Tom-Elliott You’re the boss Tom I’ve added a :1 at the end of the d1.fixed_size_partitions and it’s working! Installation is OK, no problem for partition anymore.

BUT your solution is throwing an error just before the partclone (I didn’t catch it, it’s really fast on screen - if you need it I can record a video). Due to :1 … any chance to include this into a future FOG release or do I need to manually change my file for each capture?

Also, this solution is working for both resizable / not resizable captures ???

[Tom Elliott]

@stormbyte I don’t know.

I think the intent of the fixed_size_partitions is supposed to allow for a menu entry on the GUI, which just hasn’t made it yet.

We do some rather rigorous attempts to detect fixed_size_partitions autonomously though but it’s mainly dependent on size and old installs. For now, manually editing the file should do fine.

If you can capture the error (probably best if you do the install via Debug so you can have it pause before partclone begins) would be best.

Can you upload the d1.fixed_size_partitions file here so we can take a look? I think it’s just looking for the partition number but for whatever reason, my code isn’t expecting it.

[stormbyte]

@Tom-Elliott Error message is: "Attempting to expand/fill partitions…awk: /usr/share/fog/lib/procsfdisk.awk:280: fatal: cannot open file ‘1:’ for reading (No such file or directory)

By the way the d1.fixed_siez_partitions already have a 1: inside… I just added a new one that created the error message above and it’s working fine

Here is the d1.fixe_size_partitions used:
0_1455648147461_d1.fixed_size_partitions

[mr626]

Just want to confirm I’m having the same issue as described in the OP.

Have created a new image in Fog web interface of type “single disk, resizable” and re-captured my base image. However on an attempt to image a machine I get the ‘error trying to restore GTP’ error.

Running Fog truck build 6303

Anything I can try as a workaround?

[Tom Elliott]

@mr626 What is the exact error

[mr626]

@Tom-Elliott

Sorry, was posting from mobile before.

The exact error is as per the OP:

ERROR TRYING TO RESTORE GPT PARTITION TABLES (restorePartitionTablesAndBootLoaders)

And just prior to that, it is attempting to restore a GPT partition table but can’t find one (and has the message du: cannot access ‘/images/<name of image>/d1.grub.mbr’ : no such file or directory)

Happy to run any tests / debug etc if that is helpful. I am re-reading this thread as when I was viewing on mobile I missed a whole bunch of posts somehow, so there’s a few suggestions on here I haven’t tried yet. Will update as I do

[Tom Elliott]

@mr626 what version of fog are you running, it should show in the cloud.

[mr626]

@Tom-Elliott

Hi, Fog is 6303 as per my first post

[mr626]

Ok, I’ve got a workaround that seems to do the trick (for me)

1. Create an image of type ‘single disk, resizable’
2. Capture image
3. In options for the image, select ‘partition 1 only’
4. Deploy

This works for me (tested on one machine so far- Dell optiplex 790, will test on more this afternoon). I should note though- when I created this Windows 7 image originally I made sure that everything was on one partition (ie there isn’t a separate 100mb system partition, just a single partition with everything on it). So the above may not work for everyone.

Hope that helps someone

[Oleg]

I have the same issue with all images on the fog server.
If i try to deploy them, I got the error
Restoring Partition Tables (GPT) … du: cannot access ‘/images/*****/d1.grub.mbr : No such file or directory
and so on…

This file doesn’t exist in the images and now I’m not able to download the images. Still waiting for a fix or solution.

[Wayne Workman]

@Oleg What version of FOG?

[Sebastian Roth]

@Oleg Please upload the d1.mbr file of one of your images that causes the error. I will have a look and hopefully we will find out what’s going on here.

As well please tell us you FOG version. Did this issue come up after updating to a newer version or has the error always been there (and you just didn’t use resizable images…)??

[Tom Elliott]

@Sebastian-Roth this sounds to me like the error we had with improper file sizes .

[Oleg]

@Tom-Elliott @Wayne-Workman 0_1455880449753_d1.zip
The last version I tried with was 6321.
The images were made with an older version of FOG - 32##. Could this be a problem? And all the images were always made with the option “Multiple Partion -single disk”

[Sebastian Roth]

@Oleg The MBR file looks ok to me:

$ file d1.mbr 
d1.mbr: DOS/MBR boot sector
$ /sbin/fdisk -l d1.mbr

Disk d1.mbr: 1 MiB, 1048576 bytes, 2048 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0832de2d

Device     Boot    Start       End   Sectors   Size Id Type
d1.mbr1    *        2048   1953791   1951744   953M 83 Linux
d1.mbr2          1953792  21485567  19531776   9.3G 83 Linux
d1.mbr3         21485568  25391103   3905536   1.9G 82 Linux swap / Solaris
d1.mbr4         25391104 486524927 461133824 219.9G 83 Linux

Definitely no GPT or unusual start sector. So I really wonder why this failed. Can you please update to the very latest version. Tom has changed some of the GPT detection code and I hope this should fix things for you as well.

[Tom Elliott]

@Sebastian-Roth It looks like the filesize is 52k. So I do hope/believe an update would fix this issue as well, as I’m completely moved out of the way of using filesizes .

[Sebastian Roth]

@Tom-Elliott No, filesize is 1048576 (1 MB) so I still wonder why it failed. But anyway I’d hope your changes would fix this now!

[Oleg]

@Sebastian-Roth @Tom-Elliott
After an update to the current subverion it’s working again. Thanks.