FOGProject / fos

FOG Operating System
31 stars 33 forks source link

Detect Windows boot/recovery partition #18

Closed Sebastian-Roth closed 5 years ago

Sebastian-Roth commented 5 years ago

From @Sebastian-Roth on October 18, 2017 18:13

So far we use the filesystem labels (remember to fix the wording in the script code) to find boot/recovery/reserved partitions on Windows systems. This fails on systems having a different label, namely foreign language installations. See here, here and here.

We need a different way of detecting those "special" partitions.

Copied from original issue: FOGProject/fogproject#195

Sebastian-Roth commented 5 years ago

From @mastacontrola on October 18, 2017 20:11

I've added a label for the French "Reserved" label, however I agree that a much better method of detecting reserved partitions should be created. There's too many different languages for us to just keep on "adding" new labels to search for. Also, labels can be set by the user, so it's kind of an unreliable mechanism in some situations.

Sebastian-Roth commented 5 years ago

Trying to gather more information on this and discussing this with others we came up with four different types of partitions so far:

  1. Windows system partition* - This partition contains the files need to boot up Windows and should be fixed in size and start sector. Should be fairly easy to detect.
    1. Windows Vista/7/8/10/Server 2008: Boot\BCD (registry hive config file) and bootmgr (boot loader binary) (ref1)
    2. Windows XP: boot.ini (INI config file) and NTLDR (boot loader binary)
  2. Windows recovery, EFI and OEM partitions as well as Linux SWAP and /boot partitions - We want those to be fixed in size but have a movable start sector as those partitions are last on disk quite often. So we need to move those to be able to expand the Windows partition.
    1. Windows recovery - should be easy, find Recovery\WindowsRE\winre.wim file.
    2. EFI partition - easy, find EFI\Boot\BOOTX64.EFI bzw. EFI\Boot\BOOTX86.EFI
    3. OEM partition - Almost impossible to detect as every vendor does his own thing.
    4. SWAP is easy to detect using blkid
    5. Linux /boot shouldn't be to hard as almost all distros use GRUB these days.
  3. Windows boot partition* - On systems with only one single partition for boot and system we want this single partition to be fixed in start sector but not fixed in size.
    1. TBD
  4. Normal NTFS or EXTFS formated partition (neither system nor boot) - Those shouldn't be fixed at all, so movable and re-sizable!
    1. Nothing new here. Those partitions we will actually shrink and move around as we like.

Cross-linking Georges posts about different OS specs here: https://forums.fogproject.org/topic/11070/disk-drive-geometry-and-partition-layouts-for-well-know-os

* Quite often we see the naming of those partitions in reverse. Some people state that the system partition is the one containing the files to start windows, e.g. BCD and such. Thus the one named boot partition actually holds the Windows system files. Doesn't make sense to me but ... Wikipedia officially states that the reverse naming logic exists. Probably not something we need to care about but it's important to know when reading up on those things!

Will update this post as I find out new things.

Sebastian-Roth commented 5 years ago

Closed https://github.com/FOGProject/fogproject/pull/210 for now as we still haven't come to terms with this and other things are coming up. Need to pick that up again at some point.

Sebastian-Roth commented 5 years ago

@Quazz suggestion in the forums:

parted -l /dev/sda | grep boot | awk '{print $1}'

(making use of the partition flags to find the correct partition, since flags should always be in English in FOS, this should work across the board)

Which will return the partition number for the boot partition (for both linux and windows even)

All these tools are already present in the inits.

Can also use similar commands to find other special cases

Microsoft reserved partition (Windows 10 UEFI installations, typically third partition)

parted -l /dev/sda | grep msftres | awk '{print $1}'

Hidden “Basic data partition” (Windows 10 UEFI installations, typically first partition)

parted -l /dev/sda | grep hidden | awk '{print $1}'

Linux swap

parted -l /dev/sda | grep swap | awk '{print $1}'

Linux LVM

parted -l /dev/sda | grep lvm | awk '{print $1}'

The only edge cases coming to mind are Windows XP and such maybe. They might set the boot flag on the only partition.

But it shouldn’t be hard to detect if there’s only one partition in which case skip the remaining logic because it would be pointless to check.

Sebastian-Roth commented 5 years ago

While I like the idea of using those flags I have a feeling that they are not reliably set on most systems. Just one first example, on my Linux machines the SWAP partition is not flagged at all. Interestingly enough the flags are not available in all partition schemas (reference) - e.g. msftres only in GPT while hidden, raid and lvm only seem to be valid in MS-DOS tables. I have no idea why that would be.

I still wonder if locating files on those partitions would be a lot more reliable.

Quazz commented 5 years ago

Thanks for the reference link, very helpful.

I don't think swap has a flag set on Linux regardless, but it should mention swap in its filesystem and still allow it to match, afaik. I've only tested on my own installs and obviously not all distributions and what not, so maybe this varies.

It seems like Microsoft split the flags depending on whether it's an MBR or GPT install, which is fine, it's still useable as is.

Interestingly the hidden flag is still used on a GPT Windows image (just tested this).

Not sure about raid or lvm, not able to really test those atm.

More testing is needed I think.

I do like the file idea, it should be fairly accurate, although I do wonder about the OEM partitions. (don't have an OEM install to play with) Would like to see some way of detecting them too.

Also just tried to test the recovery test on a GPT install and the Recovery map is empty? It's also much smaller. It seems to work very differently to MBR Recovery.