FOG resizes all partitions even System Reserved!

[maxcarpone]

Hey guys,

First, I must say I use FOG for several years now and it’s a great software so thanks to all people involved in the project.

I have FOG 1.54 installed on a server and it runs flawlessly for a while except recently when I encountered a problem related to resizable partitions.
I made several captures of various Windows installations (mostly 7 and 10), image type is set to resizable and it does work but a bit too well because it resizes everything!
I check the d1.fixed_size_partitions and there’s nothing in that file of all my images which is really strange

I read that FOG was checking the label to see if it was a system reserved partition and as my language is French, maybe there is a problem with the translation?

Anyway, I don’t have a single image which works as it’s supposed to do even the old ones. Any clue to resolve that problem rather than filling the d1.fixed_size_partitions file myself?

Thanks

Max

I apologize for the language mistakes which could have been slipped above.

[Sebastian Roth]

@maxcarpone You are perfectly right, there was a language issue in partition/filesystem label checking in 1.5.4! We fixed that and should be all fine if you upgrade your installation to FOG 1.5.5. Make sure you read the important notice in the release notes here if you have storage nodes in your setup: https://news.fogproject.org/fog-1-5-5-officially-released/

Please let us know if things work out properly after upgrading.

[maxcarpone]

I’ve just upgraded to 1.55 and set up a new image with my usual settings. Then, I launched a capture task which was much quicker during the “erase mbr” process (good point!).
But, when I checked the content of file d1.fixed_size_partitions, I’ve been disappointed because it’s still empty

I also tried to add “1” in that file and it works as expected, the system reserved partition not being extended.

So, despite being upgraded, my server still has the same behavior.

The French name of system reserved partition in W10 is : “Réservé au système”
Using diskpart, I get : “Réservé au” in Name column and “Système” in Info column.

How I can help to sort this out? What do you need, let me know.

Cheers

Max

[Sebastian Roth]

@maxcarpone said in FOG resizes all partitions even System Reserved!:

How I can help to sort this out? What do you need, let me know.

Please schedule another capture task for your client but this time tick the checkbox for debug. When you get to the shell run the following commands, take a picture and post here:

blkid -po udev /dev/sda1 | grep FS_LABEL
blkid -po udev /dev/sda2 | grep FS_LABEL
...
grep "label " /usr/share/fog/lib/funcs.sh /bin/fog.upload

Hints:

• ... means do the same for all your partitions sda1 to sdaX.
• That space behind label is intended to be there…

[maxcarpone]

Done

I hope this can help.

[Sebastian Roth]

@Quazz is our specialist for these label issues. From what I see in the picture I’d think the label detection should work for you. Have you made sure the image uploaded is really the new one. I mean if something does wrong at the end of the upload your new image would be stuck in /images/dev/... folder and not moved to /images/<IMAGENAME>.

I am not saying our scripts are perfectly fine. I just can’t see where it is going wrong on your side yet. Might just be me being blind on both eyes.

[Quazz]

Can’t test anything at the moment, but it looks like multiple people having issues. Everything seemed to work on the point of the initial fix, however.

The only commit I see that could possibly change anything after that point is the buildroot update

[Sebastian Roth]

@Quazz said in FOG resizes all partitions even System Reserved!:

but it looks like multiple people having issues.

Really? I must have missed those posts!?

@maxcarpone I can provide the older init files for testing if you like.

sudo -i
cd /var/www/html/fog/service/ipxe
wget http://fogproject.org/inits/67init.xz
wget http://fogproject.org/inits/67init_32.xz

Now go to this host’s settings and set 67init.xz as Host Init if it is a 64 bit machine or 67init_32.xz if it’s good old 32 bit.

[maxcarpone]

@Sebastian-Roth Hey, I created a new image so there is no possible mistake.

I’m ok for testing more things, I just need more explanations.
If I understand well, I must log on the server and go to /var/www/html/fog/service/ipxe and download 67init.xz then go to the “TFTP server” settings and change the pxe boot image? Or do I need to execute something on the client side in debug mode?

Ok, I get it, I need to edit host parameters.

[maxcarpone]

@Sebastian-Roth Well, d1.fixed_size_partitions is still empty with the new init provided

[Sebastian Roth]

@maxcarpone said in FOG resizes all partitions even System Reserved!:

Well, d1.fixed_size_partitions is still empty with the new init provided

Thanks for testing. Seems like it never worked or your system is somehow special?! @Quazz Any ideas? Could you possibly test a French Windows version in the next couple of days?

[maxcarpone]

@Sebastian-Roth I won’t be surprised because all the files d1.fixed_size_partitions I have are empty and I’m using FOG since 1.2 (before moving to trunk version).

[Quazz]

@Sebastian-Roth I recently updated most of my images and it works fine on all MBR images (accross languages (EN, FR, NL) and W7 + W10), but I do notice a problem on the latest W10 GPT images, where the first partition isn’t picked up on certain languages since they decided to change/translate labels. (first partition is “Recovery”). in fact I think this may even fail on English too since it’s FAT32, not NTFS

However, if @maxcarpone is using an MBR installation (looks like he is since the first partition label), then I have no clue why it wouldn’t work. The regex works fine in test cases and in real scenarios on my own images.

His label information on his disk is correct too as we can see in the screenshot, by all accounts it should be processed correctly…

If an English image could be created the same way a French one would and then testing to see if that one works could potentially shed some light on the situation. I realize that’s asking a lot of course. You don’t have to install all the software or anything, just install Windows and then prepare for capture as you usually do.

main reason I want to test this is because I wonder if we’re focusing on the language too much as opposed to other alternative factors that could mess with detecting the partitions correctly

double check image settings, primarily the OS field needs to be correct or it will never even try to check for the labels

[maxcarpone]

@Quazz Here is a screenshot of my image settings

I asked my colleagues to see if they had the same problem and some have that problem with empty file and some don’t.
For example, in another college, their W10 images have :1:3 in d1.fixed_size_partitions but not their W7 images!

I don’t understand because we installed things the same way and we built our FOG server the same way too!

[Quazz]

@maxcarpone Could you provide a screenshot of the disk layout in Windows Disk Management?

:1:3 is odd to say the least, thinking that disk layout is something like “System Reserved” “Main Windows partition” “Recovery”. Either that or it’s GPT and somehow the second partition wasn’t picked up… Not sure.

But anyway, let’s focus on the images you have available to you in front of you first. I currently don’t really have an idea as to why it would fail in your situation, though.

[maxcarpone]

@Quazz Here it is.

[Quazz]

@maxcarpone Looks normal to me, should just work, very strange!

Will likely look into an entirely different system for this later tonight if I don’t forget.

[Quazz]

After further investigation, using the ‘English’ label ‘System Reserved’ works fine.

I double checked my french images and one dating 25 october capture the label was picked up correctly, but one dating 16 november was not.

I believe the one around 25 october was the one I was using when I originally tested the new label regex and confirmed it working.

Not sure how/why it wouldn’t work now, though.

[Quazz]

@Sebastian-Roth Soooo, this is bizarre, but both the [EeÉé] and [Dd]? seem to fail now.

I am at a loss as to explain why though since it definitely worked

[Tom Elliott]

@Quazz I think it best to move the checks into a case statement and separate out whether it should be reserved or reserved with the accents.

I’m suspecting the Regex method is very finicky.

Possibly we need to use .*[Rr][EeÈè][Ss][EeÈè][Rr][Vv][EeÈè].*

Here’s why:
https://stackoverflow.com/questions/2348379/use-regular-expression-in-if-condition-in-bash

Basically, ? in the if statement regex = Wildcard for one or more characters. You were, I presume, using [Dd] as an “if d exists or not, let’s be true” kind of scenario?

I don’t think it has to do with the e or accented e’s, just plain it doesn’t know what to match and what not.