Problem with size of partitions
- FOG Version: 1.3.5RC16
- OS: CentOS7
- Service Version:
After upgrading to this version, there is a problem with the sizes of the partitions restored. For example, I captured with this version a disk with three partitions of aproximately 522 MB (System Reserved), 100 GB (C:) and 198 GB (D:) and when I deploy the captured image on the same computer the sizes of the partitions are 522MB, 295 GB(C:) and 2GB (D:)
Perhaps have something to do with using sectors instead of bytes since RC15?
This is the content of the file d1.minimum.partitions
/dev/sda1 : start= 2048, size= 65024, type=7, bootable
/dev/sda2 : start= 1072640, size= 37683712, type=7
/dev/sda3 : start= 190852200, size= 257024, type=7
@Tom-Elliott You’re welcome. Here are the results after the last modifications you have uploaded. Seems like there are no more errors. Now I’m making the whole deployment to see the final partition sizes in Windows enviroment.
Thank you very much!
@michelsantana Fix for this then is now up too! THanks for helping
@Tom-Elliott Still one error
@Tom-Elliott Perfect! I will try again and post the results
Fix for the missed elements should be up if you wanted to retest.
@michelsantana I’m pushing fix for the error’s being spat out.
@Tom-Elliott I have downloaded those files and repeated the process. There is a minor error than you can see in the first capture, but it seems that the problem is solved. Tomorrow I will try a deployment with a physical machine and post the results.
Thank you very much for your help!
Mind trying these:
Init’s are up at:
wget -O /var/www/fog/service/ipxe/init.xz http://mastacontrola.com/init.xz wget -O /var/www/fog/service/ipxe/init_32.xz http://mastacontrola.com/init_32.xz
@michelsantana I know what’s causing it, just trying to figure out a way around it in a nice method.
@Tom-Elliott It seems like it’s taking the d1.minimum.partitions as source to determine the proportion between partitions instead of the d1.partitions. In our example the sda3 partition is the bigger one in size but it’s almost empty.
@michelsantana I realize that and am replicating your d1.minimum.partitions and d1.partitions file.
I know what’s causing it too btw.
@Tom-Elliott In the previous example the machine (Virtual) had a 60GB hard disk. Just for testing purposes I increased the size of the harddisk to 180GB and this are the results. As you can see there is no error this time with extended partitions but the sizes of the partitions still doesn’t have the right proportions.
@michelsantana can you get the size of the disk you’re trying to apply this to?
blockdev --getsz /dev/sdaI think should do it.
@Tom-Elliott You are more than welcome. And yes, in our configuration all the partitions are primary, so we don’t have any extended partition.
Thank you very much
@michelsantana So based on what I’m seeing, this may be a problem simply because it has no extended partitions.
I’m taking a look at the main scripts to try to narrow down another (but separate) issue so I can try to see if i can get the logic out of this too. Thanks for the information thus far.
@Tom-Elliott This is the output of the command you have requested. Now I only have access to a Virtual Machine, but I guess that the problem is the same. Here you have the captures in sequence:
sfdiskis much more useful if you can get it.
You would start the “debug” task.
At the command prompt type
Step through it slowly.
It will show the output of the sfdisk as it gets applied.
@Tom-Elliott This is the output of the sgdisk command once booted with a debug deploy task with the kernel argument that you have resquested. Don’t know if is this what you are talking about.
Can you create a debug task and add “ismajordebug=1” to the kernel arguments for the host?
Step through and get the output of the sgdisk information?
It will be slow, but please it will help tremendously.