During Deployment Second Partition shrinking in size



  • I’m able to capture and deploy images fine however just recently I’ve noticed that the second partition (sda2) on the image appears to have shrink and the extra space that should be apart of that partition has become unallocated space. The image i’m deploying has 3 partitions, one for the OS/boot, one for regular storage data, and a backup/recovery. Both the Boot and Backup are exactly the size they’re suppose to be but the storage/data drive which should be around 12BG has loss about 10GB and that loss 10GB just sits out there in no where land.

    0_1463689147236_IMAG0269_1.jpg

    If I run the backup/recovery partition, when it’s done re-imaging this problem doesn’t occur. It appears exactly as it should be. The issue only happens on a fresh deployment. I’m unsure if its the image or a setting in fog i need to change.


  • Developer

    @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.



  • @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


  • Developer



  • @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.


  • Developer

    @phil_guy Any news on this?



  • @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.


  • Developer

    @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.



  • @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.


  • Developer

    @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!



  • @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.


  • Developer

    @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.



  • @Sebastian-Roth I apologize for confusion. I hope this is what you requested. I simply uploaded the file that said d1.mbr from that particular image folder. The file was too big to upload so I had to compress it. Thanks again.

    0_1463872193334_d1.mbr.tar.gz


  • Developer

    @phil_guy Are you kidding? How did you manage to upload the pictures - which are binary as well? Just copy that d1.mbr file (as is) from your FOG server to a USB key, get it to your PC and upload to the forum. It’s really not that hard, is it?



  • @ITSolutions Stupid question but how do I do that? Do you mean I need to go get the original image file and print out the d1.mbr output of that?


  • Testers

    @phil_guy We need you to upload the actual file, so that it can be examined and find why the partition is not expanding.



  • @Sebastian-Roth I’m unsure what “binary d1.mbr” file you’re referring too. If you mean the d1.mbr file thats listed in that particular image, when i try to cat that out I get a long list of unreadable texts/symbols. If the file you’re requesting is something and/or somewhere else please let me know. Thanks.

    This is the output if I try and read the contents of d1.mbr

    0_1463759675455_IMAG0272.jpg 


  • Developer

    @phil_guy said:

    The image that i’m using was built for fog 0.32 …

    Thanks for letting us know. Definitely one of the very important infos that you didn’t mention in your first post.

    Please upload the binary d1.mbr file to the forum as well. I definitely need that to be able to reconstruct all the odd bits of this… and hopefully find a solution.



  • @Sebastian-Roth @Wayne-Workman @ITSolutions I’m running Ubuntu Server 14.04 with Fog Trunk (7669). The image that i’m using was built for fog 0.32 as a Multi-Partition Single Disk Type. 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.

    Currently the image type is set as Multi-Partition All Disk and its format is set by default as partclone. The Multi-Partition Single Disk Type failed on capture during the sda3 upload part and the Single Disk Type failed right off the bat if I remember correctly.

    Belong is everything you guys requested that I knew how to get. Either I’m not looking in the right place or I just don’t have some of those files. I can’t find anything that says original and only the d1.partition file has anything readable using cat. The d1.mbr and others are just a gobbled mess of random text and symbols.

    0_1463750015113_IMAG0271.jpg


  • Developer

    Yes, please post FOG version, ls -al /images/<img-name> and the contents of d1.partitions, d1.original.partitions, d1.minimum.partitions, d1.fixed_size_partitions, d1.original.fstypes (whichever of those are available) plus upload d1.mbr (as well small file) just to make sure we have all the valuable information available. I’ll check it out over the weekend.


Log in to reply
 

400
Online

39.3k
Users

11.0k
Topics

104.5k
Posts

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