Error trying to restore GTP partition tables (restorePartitionsTablesAndBootLoaders)
-
@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.partitionsand also the files you asked for:
1_1455366016116_d1.partitions 0_1455366016115_d1.mbrFirst 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
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!
-
@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.
-
@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.
-
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.
-
@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.
-
@stormbyte What is the chunk size of each sector expected to be?
-
@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.
-
@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??
-
Or maybe sfdisk does some magic when creating the partition table and does not want the first partition to start at sector 8…??
-
@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.
-
@Tom-Elliott Thanks!
-
@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).
-
@stormbyte init’s are reuploaded, please rerun the installer to get them with the “fresh” changes.
-
@Tom-Elliott OK I do this from now. Just give you a feedback in some minutes.
-
@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.
-
@stormbyte I didn’t push to git. Just rerun the installer.
-
@Tom-Elliott ok sorry result in 2mn
-
@Tom-Elliott unfortunately, same problem same error during partclone… what’s the next step?!?
-
@stormbyte Can you put the system you uploaded from back into upload but with debug?