Error trying to restore GTP partition tables (restorePartitionsTablesAndBootLoaders)
-
@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 -
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?
-
@mr626 What is the exact error
-
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
-
@mr626 what version of fog are you running, it should show in the cloud.
-
Hi, Fog is 6303 as per my first post
-
Ok, I’ve got a workaround that seems to do the trick (for me)
- Create an image of type ‘single disk, resizable’
- Capture image
- In options for the image, select ‘partition 1 only’
- 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
-
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.
-
@Oleg What version of FOG?
-
@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…)??
-
@Sebastian-Roth this sounds to me like the error we had with improper file sizes .
-
@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” -
@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.
-
@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 .
-
@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!
-
@Sebastian-Roth @Tom-Elliott
After an update to the current subverion it’s working again. Thanks.