Deployment Error: Restoring Partition Write Operation Failed



  • I have setup FOG using Debian. So far (im giving this info because I’m not sure if the problem is related at all) I’ve had a lot of troubleshooting I had to do just to get an image up. I’m storing the images on a separate internal drive that is linked to the /images folder and had a lot of FTP login issues. At the end of an upload session FOG couldn’t rename the folder. Manually going in and renaming the folder allowed the upload to complete.

    The problem now is on one of the images that was uploaded, when I try to deploy, it gets to the “Restoring Partition Tables Write Operation Failed” and then the computer restarts. If anyone has any info on how I might be able to solve this problem I would really appreciate the help. Thanks in advance!



  • [quote=“Junkhacker, post: 42426, member: 21583”]what you are describing is how single disk resizable works. it shrinks the partitions to as small as can hold the data before images are uploaded, and when putting the partitions on a new drive it expands the partitions to fill the drive.[/quote]
    OK great, I will try that out then and see how it goes. Thanks so much for all the replies, I really do appreciate everyone taking the time to help us new guys/gals out.


  • Developer

    what you are describing is how single disk resizable works. it shrinks the partitions to as small as can hold the data before images are uploaded, and when putting the partitions on a new drive it expands the partitions to fill the drive.



  • [quote=“Uncle Frank, post: 42420, member: 28116”]Hold on a second. I think you are mixing things up here. Let me explain. When you start deploying an image your client boots up via PXE and comes up with the FOG client. This small linux is made up of several shell scripts to do the magic and deploy an image from your server to that client. First it mounts the image directory from the FOG server via NFS into the local filesystem. So ‘/images’ on the client is essentially the same as ‘/images/<imagename>’ on the server. ‘/dev/sda’ is simply the first hard disk on the client and this is where the image will be restored to (aka destination disk).

    From what I can see your ‘/images’ seams perfectly alright (we’d see other error messages if not!).

    [B]BUT, are you sure that the disk you pulled the image from is NOT larger than the disk to be deployed to…[/B][/quote]

    I am new to this but I understand that much. What I was saying is that my images are not on /images located on /dev/sda. They are on a seperate (sdb) internal drive and I have linked the location on there to the /images located on /dev/sda. I think you might be right about the problem though, I compared the two drives and didn’t realize that the drive I made the image on was bigger. Am I correct in thinking that if I were to shrink the partition on my master image before uploading then any drive I use that’s larger than that partition should work? Also, will FOG automatically expand the partition to take up the full space of the drive during deployment? Sorry if this is super basic stuff.


  • Developer

    Hold on a second. I think you are mixing things up here. Let me explain. When you start deploying an image your client boots up via PXE and comes up with the FOG client. This small linux is made up of several shell scripts to do the magic and deploy an image from your server to that client. First it mounts the image directory from the FOG server via NFS into the local filesystem. So ‘/images’ on the client is essentially the same as ‘/images/<imagename>’ on the server. ‘/dev/sda’ is simply the first hard disk on the client and this is where the image will be restored to (aka destination disk).

    From what I can see your ‘/images’ seams perfectly alright (we’d see other error messages if not!).

    [B]BUT, are you sure that the disk you pulled the image from is NOT larger than the disk to be deployed to…[/B]



  • [quote=“Uncle Frank, post: 42403, member: 28116”]FOG is trying to restore the MBR using the following command when the error occours:
    [CODE]sgdisk -gel /images/d1.mbr /dev/sda[/CODE]
    Possibly failes because the destination disk is too small?? Or somehow different to the original source disk??[/quote]
    Ok that’s good to know. I wonder if the /dev/sda might be causing the issue since my images are linked on a seperate drive and not stored on /images. Do you know where I would go to alter that sgdisk line? Thanks for the reply.


  • Developer

    FOG is trying to restore the MBR using the following command when the error occours:
    [CODE]sgdisk -gel /images/d1.mbr /dev/sda[/CODE]
    Possibly failes because the destination disk is too small?? Or somehow different to the original source disk??



  • Also, I created another image the exact same way and it deploys just fine.



  • Thanks for the responses. Here is a little more info and a screenshot:

    Debian 7.8.0
    FOG 1.2.0

    This image is set as "single disc, multiple partitions (not resizable).
    [IMG]https://lh4.googleusercontent.com/-BEwX-0Ru_cQ/VOTOOjByZkI/AAAAAAAACwg/5X47tLTuPho/w682-h527-no/Capture.PNG[/IMG]


  • Developer

    also, we need your fog version.


  • Developer

    I personally have never seen or heard about this error. Could you please be more specific: Exact error message, possibly a screenshot or photo taken… (maybe download debug session is helpful when noting down things).


Log in to reply
 

462
Online

39.3k
Users

11.0k
Topics

104.6k
Posts

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