FOG resizes all partitions even System Reserved!

[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

[Sebastian Roth]

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

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

Possibly a character encoding thing. Sorry but have no great idea on how to work around this.

[Tom Elliott]

@Sebastian-Roth I suppose we could try enforcing all of the systems to load UTF-8 locale?

[Quazz]

@Tom-Elliott BR2_ENABLE_LOCALE_WHITELIST="en_US"

to

BR2_ENABLE_LOCALE_WHITELIST="en_US.UTF-8" ?

edit: is it possible the difference is down the glibc vs uClibc???

[Quazz]

Haven’t forgotten about this, just been setting up a build environment so I can try out some of the locale options and see if anything helps.

[maxcarpone]

I did not really understand what was going on here… Have you made some progress?

[Quazz]

@maxcarpone Basically, unicode support (required for letters such as é) is broken/missing in current builds, causing the check to fail.

I think we’re on the right track, but each build takes time to compile, so for each idea it takes hours before I can test.

Currently looking into busybox locale support.

[Quazz]

Still no improvement, I did notice /usr/share/locale being empty, not sure if that’s expected on buildroot or not… (according to the buildroot code, locale support only works if the target file system has locales in /usr/share/locale)

I have a week off next week, so this seems like it will be on hold for a while.

[Sebastian Roth]

@Quazz Thanks for looking into this!

Usually you don’t have to recomplie from scratch all the time. Try changing some code or setting and run make again. Depending on what you changed this will only take a couple of minutes.

[Quazz]

@Sebastian-Roth That’s usually true, but for some reason my changes weren’t being reflected, I was probably doing something wrong, but couldn’t figure it out.

So far, the only thing I’ve been able to find is that everything should work, sigh.

[Sebastian Roth]

@Quazz @Tom-Elliott I have done some testing on my own now and this is definitely unicode hell! Short story is I think we should not rely on those label checks anymore as they can go wrong so easily with non ASCII characters. Here you go with a bit of unicode fun in the client shell:

[Mon Dec 03 root@fogclient ~]# e=$(echo -ne '\xC3\xA9')
[Mon Dec 03 root@fogclient ~]# E=$(echo -ne '\xC3\x89')
[Mon Dec 03 root@fogclient ~]# label=$(echo -ne 'R\xC3\xA9serv\xC3\xA9_au_syst')
[Mon Dec 03 root@fogclient ~]# echo $e
é
[Mon Dec 03 root@fogclient ~]# echo $E
É
[Mon Dec 03 root@fogclient ~]# echo $label
Réservé_au_syst

Ok that’s for starters just to get the right characters set in variables as I can’t seem to enter those using my keyboard in a ssh session on a client (neither can I in the VM terminal). So I suppose bash and the underlaying libs are able to display unicode characters but it’s not fully supported anyhow.
Important: This is using the UTF-8 codes for é but there are other encoding standards like ISO-8859-1 through to ISO-8859-15 and many more that may encode the very same character with different codes. Or let me say it the other way round. If we read that label the returned string might be using different unicodes than we had used in the scripts although the characters look identical to our eyes it would still not match. So here comes the fun part:

[Mon Dec 03 root@fogclient ~]# if [[ $label =~ [Rr][Ee$E$e] ]]; then echo "JA"; fi
JA

So using the variables in the bash regex actually does work. But…

[Mon Dec 03 root@fogclient ~]# if [[ $label =~ [Rr][Ee$E$e][Ss] ]]; then echo "JA"; fi

What?!? I simply added [Ss] which should match, shouldn’t it? Ok let’s try to skip the special character for now.

[Mon Dec 03 root@fogclient ~]# if [[ $label =~ [Rr].[Ss] ]]; then echo "JA"; fi
[Mon Dec 03 root@fogclient ~]# if [[ $label =~ [Rr]..[Ss] ]]; then echo "JA"; fi
JA
[Mon Dec 03 root@fogclient ~]# if [[ $label =~ [Rr][Ee$E$e].[Ss] ]]; then echo "JA"; fi
JA

Crazy stuff. So this special character ends up being two characters when doing bash regex. I still have no idea what that extra character might be and how to find it other than using . as any character. I guess it stems from our buildroot bash only partially supporting UTF-8 unicode. Anyhow, this is how my new regex looks like:

[Mon Dec 03 root@fogclient ~]# if [[ $label =~ [Rr][Ee$E$e].[Ss][Ee][Rr][Vv][Ee$E$e].[Dd]? ]]; then echo "JA"; fi
JA

And exactly the same if we use grep instead:

[Mon Dec 03 root@fogclient ~]# echo $label | grep "[Rr][Ee$E$e][Ss][Ee][Rr][Vv][Ee$E$e]"
[Mon Dec 03 root@fogclient ~]# echo $label | grep "[Rr][Ee$E$e].[Ss][Ee][Rr][Vv][Ee$E$e].[Dd]*"
Réservé_au_syst

Same ugly hack I reckon. And please keep in mind that this could fail if some Windows installations were made using ISO-8859-1 code pages. So to sum it all up. Let’s move forward and not waste any more time to find the perfect regex matching all the labels out there.

We have started to gather information on that stuff and I think we should tackle it now and see if it works any better: https://github.com/FOGProject/fos/issues/18

[Quazz]

@Sebastian-Roth I’ll be glad to escape unicode hell, I do think focus on a language neutral solution is the way to go. I’m still unsure about the best direction to take.

So far, it seems we have two possible paths to explore:

File based detection:
Will check the mounted partition for specific files/folders, if they exist then we know what kind of partition we can expect (eg resizable partition if Windows folder is found)

However, I foresee some funky stuff being able to mess this up. Atypical installations might not be detected properly.

Partition flag based detection:
Will check the mounted partition for specific flags, if they exist then we know what kind of partition we can expect based on the set flags.

However, partition flags seem to have been somewhat inconsistently set as well as have changed between MBR and GPT somewhat. And of course users/software could theoretically alter these (although this will typically lead to issues with the system in question so less likely than with labels and marginally less likely than with files)

Our greatest advantage is that we only really need to think about NTFS partitions if we are simply replacing the old label system. This means we can work a lot more targetted regardless of the path taken.

I created and tested out the partition flag system which seems to work well on the systems I use, but of course I have no idea how it will behave outside of that.

[Sebastian Roth]

@Quazz Yes, I think those are the two options we have. I tend to go the file based way because this is something that people/software can’t fiddle with. I am fairly sure that no one will ever change the boot loader binary path/name or Windows installation dir name. There is no reason to do this. Sure there is not much reason to change the flags either but I feel like this can happen more easily and the difference is, that Windows will still work perfectly fine with altered flags - so people won’t notice until they clone with FOG.

Our greatest advantage is that we only really need to think about NTFS partitions if we are simply replacing the old label system. This means we can work a lot more targetted regardless of the path taken.

I was hoping to improve the whole set and also make detection if Linux partitions work better. But that might just be another step.

Essentially I want to distinguish between partition only being fixed in size (e.g. recovery as we don’t want to expand that) and those that need to be fixed in position and size (e.g. boot partitions). But that’s the bigger picture. I might have the time to work this out over Christmas. Don’t think I will get there before.

[Quazz]

@Sebastian-Roth I was looking into a file based approach but ran into a major speed bump.

It seems that on GPT builds of Windows 10 (at least on the latest official ISO release of Microsoft), the only folder (and there’s no files) on the first partition (which should be non-resizable) is ‘System Volume Information’ which is available on every NTFS partition…

Not sure how to resolve this at this point.

Got a working flag based approach available for now which should work fine for cases such as @maxcarpone has experienced.

edit: Even better news, had an OEM disk come in so I checked it out and it turns out they also use the ‘hidden’ flag which means we can mark them as non-resizable as well with this approach.

Of course as you pointed out, ideally they’d be ‘moveable’, but that’s a different issue I think, just fixing the partitions being resized that shouldn’t should do for now I think!

[Sebastian Roth]

@Quazz said:

It seems that on GPT builds of Windows 10 (at least on the latest official ISO release of Microsoft), the only folder (and there’s no files) on the first partition (which should be non-resizable) is ‘System Volume Information’ which is available on every NTFS partition…

What exactly is the first partition for I am wondering?!

Got a working flag based approach available for now which should work fine for cases such as @maxcarpone has experienced.

Great stuff. I would say let’s give it a try! Mind sending a pull request towards out fos git repo?

[Quazz]

@Sebastian-Roth https://github.com/FOGProject/fos/pull/22