FOG resizes all partitions even System Reserved!

[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.

[Quazz]

@Tom-Elliott We had case originally I believe, but it has more limited pattern matching, it wouldn’t work at all at the time.

I think it’s ultimately just going to be struggling with accented letters no matter what we do. Even cheeky capture methods like [D-Fd-f] don’t work to capture é in the inits (but does on something like Centos 7 or even online shell sandboxes.

I’m not sure WHY that is, though.

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.

Yes, that was the original idea, which works in certain environments I suppose, but should definitely be replaced with a wild card instead. (along with [Dd])

However, even when removing that bit, it still fails to match. It so far has only worked with

[Rr]*[Ss][Ee][Rr][Vv]* as the pattern.

[Rr][EeÉé][Ss][Ee][Rr][Vv][EeÉé]* does not work.

I’m thinking that perhaps using grep to do the matching might be more consistent and predictable in its behavior.

Something like:

echo $label | grep -iq "R[ée]serv[ée]"

[Tom Elliott]

@Quazz A way around it:

I believe the problem is dealing with multiple different characters within the same pattern of matching.

Maybe something like:

.*[Rr][Ee|È|è][Ss][Ee|È|è][Rr][Vv][Ee|È|è][Dd|].*

[Quazz]

@Tom-Elliott

I like that idea, I will test it in a minute, but I did edit it a little bit (correcting accents and changing the last character possibilities given the label format that gets checked + added support for Dutch)

[Rr][Ee|É|é][Ss][Ee][Rr][Vv][Ee|É|é][Dd|_|Ee]

Well edit with results

[Tom Elliott]

Running some testing:

I created a labels.txt file

I then pulled the information from labels.txt into a variable.

Then I run inline testing: Regex pattern used: *[Rr][Ee|É|é][Ss][Ee|É|é][Rr][Vv][Ee|É|é|][Dd|_|]*

Then I run inline testing: Regex pattern used: .*[Rr][Ee|É|é][Ss][Ee|É|é][Rr][Vv][Ee|É|é|][Dd|_|].*

Hopefully this can help shed light. The .* matters more than we might expect.

[Sebastian Roth]

@Quazz Are you sure it’s both that fail now or could it just be one of them? I could imagine this being a very dirty character encoding issue. Could be wrong though.

[Tom Elliott]

@Sebastian-Roth Talking with @Quazz in chat, he says “you’ll never guess what works, storing the regex into a variable”

[Quazz]

@Tom-Elliott [Rr][Ee|É|é][Ss][Ee][Rr][Vv][Ee|É|é][Dd|]

This one is confirmed to work in my test case.

Feel free to update github as I can’t create a PR atm

[Sebastian Roth]

@Quazz Great work. Could you please make sure to test this in the FOS client as well as the bash version might differ to the one you have on other systems. Possibly you have done the tests in the client already, then forget my comment.

[Quazz]

@Sebastian-Roth Yes, I have tested in FOS, every other variation we tried worked on regular systems already

edit: I may have messed up the test case, I’ll try again in a bit though

I dun goofed, I’m pretty embarassed. I messed up my sed which made the variable empty and of course it matches then…

[Tom Elliott]

@Quazz So what does this mean?

Is the test cases working properly now?

[Quazz]

@Tom-Elliott Unfortunately not, it turns out it was working because the variable was empty.

Back to square one.

Would [Rr]*[Ss][Ee][Rr][Vv]* be dangerous to use in production? I don’t expect many false positives, but arguably not resizing certain partitions that should is less harmful than the reverse.

edit: Even stuff like grep fails, the accents are blocking everything so far