Resizing issue maybe?

[Sebastian Roth]

@adame You might be able to get this fixed by shuffling around with your partitions but we also might be able to get this fixed from our side as well - not promising anything but we might be able.

Please run a debug upload job from the old HDD (schedule a normal upload but just before you click “CREATE UPLOAD TASK” there is a checkbox for debug). The client boots up and drops you to a shell. Run sfdisk -d /dev/sda. Please take a picture an upload it here.

[edit] Just a blind shot: Edit /images/<image-name>/d1.fixed_size_partitions file. I guess it reads 1: right now. Make it 1:2 and try deploying again to the SSD.[/edit]

[adame]

@Sebastian-Roth Ok I’ll give that a shot.

[adame]

Sorry. Had to put out some fires, haha. So far I got this part done. I’ll do the other thing after I put out another fire.

https://gyazo.com/78b039ef89bd2eb7c90d54511d640d8f

[adame]

I changed that file to 1:2 and so far it went on to the next process. So I’m farther than I was. I’ll let you know once it’s finished if it’s all good to go.

[adame]

@Sebastian-Roth Setting the image to 1:2 worked like a charm. Loaded up windows just fine after it finished. Will I need to do that with every image or is that something on your end you can do? I don’t mind if I have to edit it manually for each one.

[Sebastian Roth]

@adame Thanks for the picture. This things is your partition layout is not really “the typical clean install of windows” that we usually have. So FOG is kind of tripping. You have two hidden NTFS partitions (type 27) which is kind of unusual. I’ll see if we can change the scripts to work for your partition layout as well.

What is that first partition for anyway??? Second is the boot partition and third is windows, right? But the first?!?

[adame]

@Sebastian-Roth Sorry for the late response. These came from Panasonic. The 3rd partition is the system recovery partition so we are able to restore to factory settings. Also has 64 and 32-bit of the OS in it. They don’t send out recovery media at all. Kind of sucks. We spend like $3,000 a piece on these and we can’t even get $5 jump drive with the recovery media on it without requesting to get one for a small fee.

[adame]

@Sebastian-Roth But I’m assuming that’s where a lot of laptops have been going these days. Granted most still come with recovery media but they have that extra partition primarily for factory resets. The thing I’m going to love about fog is if that hard drive took a crap I have a “factory reset” on the fog server so I don’t have to purchase the media.

[Sebastian Roth]

@adame said:

But I’m assuming that’s where a lot of laptops have been going these days.

Absolutely. Lots and lots of different setups and it’s not very easy to kind of auto-discover and do assumptions on partition scheming! There are too many things that can go wrong. I checked our scripts and thought about adding a check to see if windows boot files are found on one of the partitions.

@Tom-Elliott what do you think about this idea? Find BCD on one of the partitions and if we find it mark this partition and all the ones before it as fixed size! Not sure if this would break other weird partition layouts.

[adame]

@Sebastian-Roth And if you can’t, it’s not the end of the world I’m sure but you might want to add it to the wiki on how to do this so you don’t have a bunch of posts regarding this. I only need to do it to maybe 10 images. The rest are desktops with the general Windows partitions. I just imaged a desktop and it flew right through it without any edits.

[Tom Elliott]

Is there a potential update on any of this?

[Sebastian Roth]

@Tom-Elliott Well, I am still waiting for you to tell me your opinion on my suggestion of adding a script that can run on the FOG server which will go through the images and try to add d1.partitions and d1.mbr to all the old legacy images that are missing those files. As I told you we should able to extract the information needed to do this from the *.img files.
An alternative way would be to do the information extraction on every deploy if those files are missing. I don’t really like that idea! Better do it once and update the image with that information I find. What do you think?

[Tom Elliott]

@Sebastian-Roth I’m totally up for it, just have no idea what I’m doing.

[Sebastian Roth]

@Tom-Elliott No worries, I’ll do it! You’ll see…

[adame]

Sorry. Had a long weekend! Hope everyone had a great weekend! I’ll keep an eye on this thread if this is where you’ll update us on how things go. Thanks!

[Sebastian Roth]

@Tom-Elliott I guess I’ve mixed up two different issues in my head here. In my last post I was talking about extracting start sector information from the *.img files but that’s totally not the point of this issue here.
This is about trying to detect the windows boot partition and make this and all the partitions before it fixed size so the windows boot manager is not being moved. I think I need your expert knowledge on this as well. Looking at the current code of putting together the fixed_size list I find this part of the code very strange. What does the for loop below “Setting up any additional fixed parts” actually do???

[Tom Elliott]

@Sebastian-Roth That loop is to ensure non-resizable partitions don’t move around.

[Sebastian Roth]

@Tom-Elliott That’s what I would’ve guessed as well. But I really can’t get my head around this weird check [[ $((ntfscnt + extfscnt)) -gt 1 && $part_number -eq 1 ]]. Isn’t this making the whole loop useless as it only adds something to the fixed list if “part_number == 1”?!?

[Tom Elliott]

It’s backward.

Look at the first part. It already enters the fixed sizes for non-resizable partitions. The second part (the osid) is to ensure at least the first partition is fixed size, in the case there are any resizable partition found.

[Sebastian Roth]

Ok, thanks for explaining. Makes a little more sense now. But I still think the for loop is useless. This would do the exact same thing without any loop:

[[ $((ntfscnt + extfscnt)) -gt 1 ]] && fixed_size_partitions="$fixed_size_partitions:1"

By the way. The current code in trunk is ...="$fixed_partitions:... (missing the _size). Guess this is a bug?!

Do you like the idea of trying to find the BCD file on one of the NTFS partitions and make this and all the ones before fixed size?