Error trying to restore GTP partition tables (restorePartitionsTablesAndBootLoaders)

[stormbyte]

Hi all!
I’m using FOG on latest trunk release with a DEBIAN 7.9 since 1 week: it works well except on 2 computers I had to clone, which are similar to the others (I’ve 10 computers with exact technical configuration)

First computer I need to clone is having a W2K12 without other stuff. The other computer is a simple W7.
Disk are 120Go SSD. But before trying to clone I was obliged to made a change on them to delete a partition for cloning:
Before: (SYSTEM RESERVED 300Mo) (PARTITION#1 WINDOWS W7 80Go) (PARTITION #2 WINDOWS 7 40Go)
After: (SYSTEM RESERVED 300Mo) (PARTITON#1 WINDOWS W7 120Go) -->> this is what I’m trying to clone!
I kept only the first partition on the disk. (I used windows for this partition deletion/partition resize)
So each one has now its own first partition System Reserved and the rest of the 120Go SSD disk drive for the second partition (only 20Go of data used on the disk).

Uploading to FOG is no problem, I’ve checked the files and they are correctly located to /images.
I’m using Single Disk, Resizable partition and made also the test with Single Disk, multiple partition (not resizable).

When I’m trying to deploy those images to other computers I see this STRANGE error message: ERROR TRYING TO RESTORE GPT PARTITION TABLES (restorePartitionTablesAndBootLoaders) / Restoring Partition Tables (GPT): du: cannot access ‘/images/W2K12/d1.grub.mbr’ : No such file or directory
http://www.hostingpics.net/viewer.php?id=777518201602121815031600x1200.jpg

Why FOG is showing ‘Restoring Partition Tables (GPT)’ ?? I have no GTP on it! I’ve checked on many posts here, and I used the FOG debug mode to send a FIXPARTS command many times, without any success… I’ve tested also the REPAIR disk on Windows to send BOOTSEC /FIXMBR and so on, without success…

FOG is showing on the screen ‘/images/W2K12CEHbase/d1.grub.mbr’ -->> this file doesn’t exist in FOG files!! That’s weird? Why it’s searching for something that doesn’t exist??!

I’m lost on this error, I spend many hours trying to correct it… What can I do now?? (ok I can reinstall again my 2 windows with stuff on it, but if this problem appears again…

Thanks for your help, tips, etc…! I’m ready to test all solutions!
Have a nice week-end!

[Sebastian Roth]

@stormbyte From what I see digging through the code and reading your post (great description with lots of details! :-)) I think this might be a bug in the scripts. So I’ll move this to bug reports.

Can you please run ls -al /images/W2K12CEHbase/d1.mbr and post the output here? We seam to detect GRUB bootloader being installed on your system which is not the case I am sure.

[stormbyte]

@Sebastian-Roth

Thanks for your fast answer.

Here is the result of the command:
-rwxrwxrwx 1 root root 4096 Feb 11 15:06 /images/W2K12CEHbase/d1.mbr

What can I do now from my side?

[Sebastian Roth]

@stormbyte Getting a bit lost here in the script code…

Please show us the full content of that directory as well ls -al /images/W2K12CEHbase

You sure you tried resizable and non-resizable completely? Meaning complete new upload? The image structure is very different. Changing the image type does not change the image but needs to be uploaded again!

Are you sure you don’t have GPT but MBR? Please upload the d1.mbr file and I’ll have a look but I think the detection is pretty robust.

[stormbyte]

@Sebastian-Roth
Sebastian,
Here is the directory content:
-rwxrwxrwx 1 root root 4096 Feb 11 15:06 d1.mbr
-rwxrwxrwx 1 root root 210242095 Feb 11 15:07 d1p1.img
-rwxrwxrwx 1 root root 12707118330 Feb 11 15:26 d1p2.img
-rwxrwxrwx 1 root root 190 Feb 11 15:06 d1.partitions

and also the files you asked for:
1_1455366016116_d1.partitions 0_1455366016115_d1.mbr

First I made a clone with Single Disk/Multiples partitions(not resizable), then after many actions (fixparts/etc.) I then capture again the same computer using Single Disk Resizable. So I think that FOG has deleted the previous ones. Am I wrong?

I can delete everything and make again the test if you need the result!

Waiting for your orders!

[stormbyte]

@stormbyte
I’ve just made another clone from W2K12 with Single Disk/Resize from scratch (new Image and not importation from previous one) and it’s still the same. I’ve also tested to import to different computers, each time it’s the same error message…

please help to solve!

[Sebastian Roth]

@stormbyte Ok, your partition scheme seams to be MBR! What’s causing the trouble is that your first partition starts at a kind of uncommon place, sector 8. Mostly used are sector 1, 63 or 2048. This is not a real issue. FOG is just not aware of this yet. I don’t have the initrd build setup on my computer so we need to wait for Tom to fix this.

@Tom-Elliott Could you please add ‘4096’ to the mbrsize check in usr/share/fog/lib/funcs.sh (line 1822). From what I can see in the code this is causing the issue.

[stormbyte]

@Sebastian-Roth Excellent news Sebastian! thanks a lot for your time and investigation I’m happy to see the problem is not coming from my side (I was desesperated!)

@Tom-Elliott Hi Tom! Please could you tell me when do you think this fix will be available? Thanks for your help! Kind regards.

[Tom Elliott]

Please try to update again, or you can just re-run the installer.

Init’s have been updated with the 4096 model, though I really want to understand how this even occurs. I don’t know that it will actually work, but it’s worth a shot non-the-less.

[stormbyte]

@Tom-Elliott Thanks Tom for your really fast feedback and action. So I’ve updated my FOG. This error message doesn’t exist anymore BUT … there’s another problem…

I’ve taken last capture from W7 and W2K12: no more GTP/MBR problem.

BUT when FOG is trying to use partclone it shows:
'Calculating bitmap… Please wait… Target partition size(367MB) is smaller than source (367MB). Use option -C to disable size checking (Dangerous).

That’s weird because I used ‘Single partition/Resizable’ for capturing the computer’s image !!

What can I do / try / ? Waiting to read you, and again thanks for your fantastic work!

PS: some infos about the computers, they’re SHUTTLE XPC boxes (core i5, 8GB RAM, etc) BIOS is using standard parameters and disks are 120GB SSD (Samsung/Corsair). Nothing unusual.

[Tom Elliott]

@stormbyte What is the chunk size of each sector expected to be?

[Tom Elliott]

@stormbyte I ask this because we currently only default to 512 or 2048. If start sector is 63 the natural chunksize is 512, if the start sector is anything else we pass it with a chunksize of 2048. This, I think, is the problem.

Start sector is sitting at 8, so when we recreate the partitions, it’s starting chunk size is larger than what was setup for the original layout. That’s the best I can come up with for now.

[stormbyte]

@Tom-Elliott I’ve no information about the chunk size of each sector. Configuration is definitely by default. How can I check this and give you the information? (what tool to use?)

How do you think I can check/resize/change this strange sector behavior under Windows? (I’ve many tools by hand, but I don’t know which one to use!

Another infos: I’ve checked previsely all FOG messages during launch and import on client, there’s one showing at the first PXE beginning:
“EXT4-fs (ram0):couldn’t mount as ext3 due to feature incompatibilities
Populating /dev using udev: udev[2357]: error creating epoll fd: Function not implemented”
I read on other topics that normally I don’t have to take into consideration those messages, hope I’m right.

Here is the screenshot of the error I’ve just downloaded it: http://www.hostingpics.net/viewer.php?id=47018020160213180322.jpg

And another one: http://img4.hostingpics.net/pics/126443201602131803071.jpg

Thanks for your feedback and expertise Tom!

PS: do you think there’s a tool to change the start sector from 8 to 63??

[Sebastian Roth]

Or maybe sfdisk does some magic when creating the partition table and does not want the first partition to start at sector 8…??

[Tom Elliott]

@Sebastian-Roth Sfdisk is applying the sectors as the sfdisk dump shows up. It’s the resizing that’s causing our issues, and I think it’s because we’re expecting chunksizes of 512 and 2048. I can try to see if setting sector start 8 as chunksize 512 and see if that helps at all.

[stormbyte]

@Tom-Elliott Thanks!

[Tom Elliott]

@stormbyte building init’s with chunksize 512 if sector starts at 8, I don’t know if it will work (probably won’t) but if you still have the system you uploaded this with, please try putting it into an upload debug task (Create the task like you normally would, but in the confirmation screen select schedule as debug).

[Tom Elliott]

@stormbyte init’s are reuploaded, please rerun the installer to get them with the “fresh” changes.

[stormbyte]

@Tom-Elliott OK I do this from now. Just give you a feedback in some minutes.

[stormbyte]

@Tom-Elliott GIT PULL is showing ‘already up-to-date’ … do I need to wait some time before being able to catch your modifications? It seems there’s no modification of code (I already GIT PULL an hour ago to solve the GPT/MBR error). Thanks to tell me please how to proceed to force GIT PULL to catch your latest changes.