Saving original partition table



  • Hello there, and thank you for FOG. It’s been a life saver in our district.

    We’re having some trouble lately with getting new images captured to the server, and after quite a few forum searches, we’re coming up at a loss. Everything seems to go smoothly with the capture process, right up until it gets to ‘Saving original partition table’ and then it just hangs and never goes to ‘done’ for that step.

    Since we’ve been on the git version for quite some time, we did a new pull to try to see if that resolved the issue, but sadly we’re still having the same trouble. Hopefully this is something obvious and easily fixed.

    I should probably point out that it is correctly reading an NTFS partition count of 2, so it does appear to be able to read the partition table prior to trying to save it.


  • Senior Developer

    @george1421 I already do.


  • Moderator

    @Tom-Elliott said:

    The “hanging” is most likely due to GPT structures left on the disk.

    Is there any way for the system to detect this an just issue the commands for the IT tech? Is there any harm to automatically doing this just for consistency sake?


  • Senior Developer

    @SCSJBlake It shouldn’t have to be done all the time.

    The problem is from windows. You’re adjusting the layout to be an MBR layout. Windows handles this part fine, but the partition table’s aren’t updated properly.

    That said, of course you can add it as a part of your process.



  • That did the trick! Thank you sir!

    Now we’ll just add fixparts (or maybe a dban) to our regular process for new machines.


  • Senior Developer

    The “hanging” is most likely due to GPT structures left on the disk.

    Please boot the system in debug (Schedule an upload task like you normally would, but before confirming the tasking check the box for “Schedule as debug”).

    Then boot the client that’s got the “master” image on it.

    It will bring you to a linux prompt.

    Run:

    fixparts and confirm and save the changes (if it finds any).

    Then run:
    fog

    The system should work like it normally would only stopping every so often to show you what step it’s on and waiting for you to press enter.



  • We’ve tried 2 different models. Later today I can try some older ones that previously worked as well.

    The two models that are definitely failing are a Probook 11 G1 and a Probook 340 G2. We turned off EFI and went to legacy on both of them, and they are running Windows 7 (64-bit). The image type is single disk - resizeable. As for FOG, we’re on 6509 right this moment.


  • Moderator

    Lets get a little background information to help the devs here.

    What is the version number shown in the cloud on the management gui? It should be 4 digits.
    What device make and model of the device are you trying to upload?
    What is the OS on the device you are trying to upload?
    Is this device using efi or legacy bios mode?
    What type if disk layout are you trying to upload resizeable, fixed, raw?


Log in to reply
 

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.