Error trying to restore GTP partition tables (restorePartitionsTablesAndBootLoaders)
-
@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?
-
@Tom-Elliott of course Tom, I’ve launched the station with debug mode. What command I should enter then on the workstation?
-
@stormbyte run:
blockdev --getpbsz /dev/sda1
-
@Tom-Elliott answer: 512
-
@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