sda3 and sda4 of resizable windows 7 image not restoring

[Wayne Workman]

@JJ-Fullmer Well if the drive is a true 120GB SSD, then you have about 128849018880 sectors to work with. Here’s how I figured that:

the way the start and size columns work for the d1.minimum.partitions file works is, the start is where the partition starts, and start+size is the last sector of the partition. The next partition should use the next sector. You have to fit all your partitions and their data into 128849018880 sectors.

You can take time to get the d1.minimum.partitions right, or, more easier as you said, resize the partitions as small as possible on the original disk and upload that, then manually expand them out on the new disk.

[JJ Fullmer]

@Wayne-Workman So in theory if I edit d1.minimum.partitions to reflect where the partitions should each start, it will work as it is?

[Wayne Workman]

@JJ-Fullmer Should. But keep in mind how much space is in use on those partitions, you have to allow for the space used or it won’t work.

At any rate, make a copy of the d1.minimum.partitions file as a backup.
cp /images/UPSpvc/d1.minimum.partitions /images/UPSpvc/d1.minimum.partitions.old

[JJ Fullmer]

@Wayne-Workman http://thestarman.pcministry.com/asm/mbr/DriveOffsets.htm
You may want to check your sector math…
Anyway I took a look at what those extra partitions were and saw that they were the HP recovery tools partitions that are useless to me.
So I tried the fixparts delete the partition solution again and then did a bootrec /rebuildbcd and it works now without the stupid partitions.

I’m pretty sure though that editing the minimum partitions so that the maximum sectors minus the size of that last partitions was the start and so on would work.

Thanks,
-JJ

[Wayne Workman]

@JJ-Fullmer Well, if there isn’t 1,024 MB in a GB, and there isn’t 1,024 KB in a MB, and there isn’t 1,024 B in a KB, and there isn’t 512 B in a sector, then I’m lost…

The formula for going directly from GB to B is Bytes = Gigabytes x 1,073,741,824 I found on a site.

[JJ Fullmer]

@Wayne-Workman
120 * 1073741824 = 128849018880
128849018880 / 512 = 251,658,240
Wait that is what you have you just kept typing the 12 digit number. And I was seeing a higher number of sectors for the 120 GB then the last sector of the 500 GB drive (976,762,879) And I was like, that can’t be right. But I looked again and you just hit copy on the wrong number I think.

[Wayne Workman]

@JJ-Fullmer Yup. I copied the wrong number lol.

[Sebastian Roth]

@JJ-Fullmer Well this is an interesting one as we obviously never had anyone wanting to resize this kind of partition layout yet.

As we can see from your posts the old disk is a lot larger than the new one:

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors

vs.

Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors

While this does not have to be a problem per se it is causing an issue in your case because sda3 and sda4 start at a position way beyond the SSD capacity. If my understanding of the magic resize algorithm is correct we don’t move any start sectors of any of the partitions as this might cause an issue. We keep all the start sectors and only shrink/expand the partitions. This is usually fine because most installations have the big system partition last and therefore this is being shrunk/expanded.

A couple of times Tom and I have discussed rewriting that magic resize algorithm and improving it. Your case would definitely be on the list for improvements. But on the other hand we are a bit worried about making things worse because we would need to do assumptions on which partition’s start sector can be moved and which can’t (windows boot partitions are very picky with being moved!). A lot of things can go wrong if we need to do those kind of guess work.

[JJ Fullmer]

@Sebastian-Roth After I realized the issue I thought of another instance where something like this happened that would be another case that would benefit from the redoing the algorithm. I wanted to convert a mbr image/windows install to an efi style without redoing the whole thing and I actually found a tool that can do that. The problem is my original image is only 1 partition and efi requires having a seperate efi partition. I discovered I was able to shrink my partition and just add a small efi partition to the end and I was able to successfully convert the image. However when I tried to deploy the image I found that the efi partition would always start at the same spot regardless of the size of the hard drive. So I stopped trying to do that. Granted with it being the boot partition it could get picky with being moved and make the whole idea moot. And granted if I had a standard 2 partition windows mbr installation, I could have deleted the first partition to create the efi partition and then fog would deploy the image like any other. So it’s a special case scenario within a special case scenario.

But perhaps the algorithm would only change when there are more than 2 partitions. Like if partitions is greater than 2 do a bunch of math, maybe either require specifying which partition is the one you want to be resized/is the main data partition, or check volume names for mount points or some sort of universal indication that a partition is the main partition. Or just assume the largest of the original partitions wants to resize and do the math based on the current algorithm to find the max size, but just call the sector count used to do the math of it’s max size the sector size of the new hard drive minus the sum of sectors of sda3 and up. I don’t know though, maybe that’s helpful, maybe it’s just ranting. Overall it’s only useful in very special cases and probably not worth the effort. Unless something about partition formatting changes in the near future or something.

[Wayne Workman]

Maybe checkmark boxes in the image definition to tell the inits to move the start sectors? Could be I guess 5 checkboxes, for 5 partitions. Some may have more partitions than that but I think 5 would cover most.