Error trying to restore GTP partition tables (restorePartitionsTablesAndBootLoaders)
-
@stormbyte Okay, so that is added, but i got many things to do this weekend. I’ll likely not be able to get to this until next week if this is okay.
I have added the code to make the sector size use 512, so it should work.
-
@Tom-Elliott no problem Tom, there’s a life outside FOG world! please just tell me when you will deliver a new release to solve this problem, and thanks again for your time. I’m ready to make new tests if you need. Kind regards
-
@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.
-
@Tom-Elliott Tom, I’ve updated but the problem is exactly the same … I’m ready to try your other suggestion!
-
@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 ???
-
@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.
-
@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 .