Cannot capture image- fails at 'Saving original partition table'
I have a functional FOG Server running version 689680. I am able to capture images with no difficulty throughout my organization, except for my personal system. Every time I attempt to PXE boot to capture the image I get an error at ‘Saving original partition table’
'The protection MBR partition is oversized! Auto-repairing.
The protective MBR’s 0xEE partition is oversized! Auto-repairing.
An error has been detected
Cannot determine partition type (getPartitionTableType)
Args Passed: /dev/sda
Computer will reboot in 1 minute.’
I have seen similar threads, but either I’m so bad with Linux I can’t follow the instructions or my issue is actually unique. I don’t know. My drive is SSD, 256 GB.
If I’m in the wrong place, please let me know. Thanks in advance!
Wayne Workman last edited by Wayne Workman
Is there a mailing list I should be on to get notified of new releases?
Release Candidates and Releases are in the Announcements area:
But currently news.fogproject.org is not working.
Latest version is also shown right on the FOG login screen, and in FOG Configuration area too.
Excellent. With your expert assistance I’ve arrived at Version 1.4.4, Rev 6077.
I’ll try a Single Disk - Resizable capture tonight.
git checkout dev-branch
That caused your pain. If you would have skipped that one step you would be on the current stable release.
Can you roll back? you should be able to. I say should because I’ve never did that between 1.5.0 and 1.4.4. The DB structure should be the same.
What you want to do to roll it back is
git checkout master
Then do a fog reinstall by just rerunning the installfog.sh script.
tandersb last edited by tandersb
I used the instructions here and I think I upgraded too far. What in this causes me to upgrade to bleeding edge rather than stable?
git clone https://github.com/FOGProject/fogproject.git /root/fogproject
git checkout dev-branch
Can I roll back to 1.4.4 from 1.5.0? (I’m on SVN 6080)
@tandersb 14.04 is not too bad, 16.04 isn’t either as long as unattended updates are turned off. There is a post in the announcements forum to help you unscrew your system from that too.
AFAIK there isn’t a mailing list for updates.
Just use git and do a git pull and then rerun the installer to bring you up to the latest stable. There was quite a few disk related fixes added between 1.3.5 and 1.4.1 that you will probably need if you use single disk resizable.
Wow, I didn’t realize I was so far behind. Is there a mailing list I should be on to get notified of new releases?
Also, I’ve read about so much bugginess with Ubuntu 14.04. Would you recommend I do a clean setup on a different distro?
@tandersb According to your fog home page you are on an older release. And since your version number is a bit crazy I’m going to suspect an RC release. Can we get you to update your fog version to 1.4.4 (svn: 6077). I’m not saying that your issue will be resolved with the update. But if we need to get the developers involved with your issue they will say you need to be on the current release any way.
Sorry for taking so long to respond. Here is my FOG version.
And here is the actual error.
I ended up getting the upload to work, but not as Option 1 ‘Single Disk - Resizable’, rather I had to select Option 2 ‘Multiple Partition Image - Single Disk (Not Resizable)’.
While I am glad I have an image, I don’t understand why I’ve been able to upload other images as Option 1 with no troubles. I will try the fix you described.
I have a functional FOG Server running version 689680.
I don’t think we ever released a version 689680. Can you please take a picture of the version in the web GUI and post here. As well take a picture of the actual error on screen and upload. Recent versions of FOG do try to fix this issue if and oversized protective MBR is found. So I am wondering which version you have.
You can simply try fixing this yourself. Schedule the upload task as debug (checkbox just before creating the task in the web UI) and run
fixparts /dev/sda(say yes and write changes to disk). Then start the actual upload task by runing