During Deployment Second Partition shrinking in size

[Sebastian Roth]

@phil_guy No problem! Thanks for the file. I had a first quick look but I need more time for this. Please be a little patient. Feel free to remind me of this when you don’t hear anything by the end of the week.

[phil_guy]

@Sebastian-Roth I really appreciate the help. Let me know if you need any other pieces of information. And also as an update, I updated to git 7799 to see if that fixed the problem, however the issue still remains. Thanks.

[Sebastian Roth]

@phil_guy Turns out I didn’t pay enough attention when reading your posts. Sorry for that! Re-reading it all over and over I think you are saying you are not using the resizable image type at all. Is that correct?

When I transferred that image to my current Fog server, I did it by capturing it and uploading it directly to my new fog server rather than just trying to import the file from the old fog server.

What do you mean by that? Are you saying that you always do a fresh upload of that client or is this still the old FOG 0.32 image?

From the d1.partitions (same in the d1.mbr file) we can clearly see the gap:

/dev/sda1 : start=     2048, size= 70193152, Id= 7
/dev/sda2 : start= 70195200, size=  4816140, Id= 7
/dev/sda3 : start= 97230848, size= 19998720, Id=83, bootable

Size of the second partition is 4816140 sectors multiplied by 512 (bytes per sector) and divided by 1024 three times I get 2.30 GB

So if you deploy this image as is it will have that gap for sure! So question remains, are you getting this even when capturing a fresh image with FOG trunk??? If so, we have quite an issue here. But if I got you wrong and you are just trying to deploy this old 0.32 image over and over again I can possibly provide patched files for you to fix this.

Again I am really confused if I just get you all wrong here. So please be very specific in telling us all the steps you take to re-produce this issue. Thanks!

[phil_guy]

@Sebastian-Roth Thanks for taking the time to look it over.

1. I have only tried using the Multi-image types (both single and all disk). The image I’m trying to deploy has 3 partitions and originally the image was set as a multi-image single disk type on fog .32

2. I assume this is still the old fog.32 image. I deploy the image using fog .32 onto a client. I then capture the image from the same client using the current new fog (fog trunk 7959). During the capture on the new fog trunk server I do notice the shrunk sda2 size.

3. I have also tried capturing other images using the same method and on others it appears to work fine. All the partitions appear to be the correct size. It may just be this specific image.

Let me know if you need any thing else cleared up.

[Sebastian Roth]

@Roger-Saffle, @ITSolutions I moved your posts to a new thread as I think this is worth looking at but so far seems different to what we have here from my point of view.

@phil_guy Ok, this is really interesting. You deploy the image to the client using your FOG 0.32 server, made sure the partitions are good on the client and then upload this client using your FOG trunk server shrinks the second partition. Do I get that right?

I suppose the d1.partitions you posted a picture was from the new FOG trunk server, right? What files do you have in the image directory on your old FOG 0.32 server? Do you have d1.partitions? Please post the contents if you have. As well please deploy your client from the old server (so partitions seem correct) and then schedule a debug upload via the new server. This will bring you to a command shell. Run sfdisk -d /dev/sda and post a picture here. No need to actually run the upload. Just turn off the client and delete the task via the web GUI after you got the information I requested.

[phil_guy]

@Sebastian-Roth I’ll get you all the info and pics whenever I have a chance to sit down and thoroughly record/repeat the process that lead to this hiccup. Just give me a bit of time, thanks.

[Sebastian Roth]

@phil_guy Any news on this?

[phil_guy]

@Sebastian-Roth I apologize for the long delay. I had to step away from this for another project.

And yes you have the set up correct. I deployed the image from my old FOG 0.32 to a client machine. Then using the new FOG I uploaded the image from that same client. During the deployment while using the FOG 0.32, all three partitions are the correct size. But when I upload it to the new FOG, I can see the second partition shrinking. I tried repeating this process with other images (7 in total) and only one other images has this issue. The others are all correct.

And yes the d1.partitions picture I uploaded is from the new FOG trunk server. The image directory from my old FOG 0.32 does not have a d1.partition file. In each image it only contains a d1.mbr, d1p1.img, and d1p2.img

I’ll upload the photo of the output you’re requesting however something has gone wrong and now I can’t even pxe boot any client machines. I’m getting the TFTP open timeout error. I gotta figure this issue out first before I can run the debug mode on the new server.

[Sebastian Roth]

@phil_guy https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP

[phil_guy]

@Sebastian-Roth

Alright so I started from scratch. I took this image from my old FOG 0.32 Server and deployed this image onto a client. I watched it image and noticed that all the partition sizes appeared correct. When I was able to get to the client machines desktop, I looked at the disk management and also noticed all the partitions were the correct size.

Unfortunately I can’t test what happens when I try to capture this same image to the new FOG Trunk Server. My capture is failing on the 3rd partition everytime. I get a “extfsclone.c : bitmap free count err, partclone get free:655082 but extfs get 2418133”. I’m trying to fix this now.

But here’s the output you requested. I don’t know if this effects the fact I can’t actually upload the image in the first place. This was ran from the client machine running the debug mode from the new FOG Trunk server.

0_1466708451928_pic1

[Sebastian Roth]

@phil_guy The partition table looks interesting to me:

unit: sectors

/dev/sda1 : start=      2048, size=  70193152, type=7
/dev/sda2 : start=  70195200, size=  27035648, type=7
/dev/sda3 : start=  97230848, size=  19998720, type=83, bootable

First two partitions are NTFS (type 7) but the last one is marked to have a linux filesystem (type 83) and bootable. I don’t think windows is happy with that.