Resizing issue maybe?
So I got my fog server up and running great. I have a few new MDCs that I wanted to put some SSDs in to replace the crappy HDDs in them. I can just do a clone with the Samsung software but figured what the heck, let’s do this with fog to test it out.
So I chose to create a Windows 7 image and make it resizable. It captured the full harddrive as planned. Now when I slap in the formatted SSD the server starts to deploy to the MDC and looks like it’s working just fine. After the first partition it seems to crap out. I know it’s a multipartition but it’s just the typical clean install of windows where windows created those partitions themselves. I never had this issue before. I seen it was an issue in previous builds and was fixed from searching the forum but did it crop it’s ugly head back up? Or am I doing something wrong?
The HDD that I’m replacing was 500GB and being replaced by a SSD that’s 250GB.
It seems to work at first. This is when it’s deploying to the MDC
Then on the next screen after this hits 100%
I’ll dig up the log file when I get back in a 20 minutes since you might want to look at that maybe? Thanks!
FOG Version: 7577
SVN revision: 5441
Again, anything to report?
Anything at all?
@adame Any news. Did you get to test this?
I’ll definitely test it. Thanks for all your hard work guys. I’ll let you know when I’m back at work on Monday . Have a great weekend!
I’ve updated the init’s to include the code to hopefully iterate the partitions during upload and setup our strings of fixed size partitions more properly.
Please test and/or review as necessary and let me know if things are okay.
Of course this will only impact new uploads from this point forward so to really test we need to have an upload task performed. Particularly on a system that the BCD partition is not on the first partition of the disk if possible.
@Sebastian-Roth I totally agree. I think I just had the loop in the case we needed to do as you’re suggesting (all partitions up to a certain point) without directly indicating it. Yes, the fixed_partitions was a mistake on my part.
I’ve removed the first partition out of the loop, but have left the loop in place so I can mount and test the presence of the BCD. It should work, but I will admit it’s completely untested.
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
_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?
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.
@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”?!?
@Sebastian-Roth That loop is to ensure non-resizable partitions don’t move around.
@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???
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!
@Tom-Elliott No worries, I’ll do it! You’ll see…
@Sebastian-Roth I’m totally up for it, just have no idea what I’m doing.
@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.mbrto 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
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?
Is there a potential update on any of this?
@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.
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.
@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.