by TeraByte Support » Mon Nov 30, 2015 9:23 am
Sounds like "they" (must be some newbies as MS) "tried" to make it safe but
messed up and went beyond the existing partitions (cylinder) alignment. It
is a bit more complicated than it seems when dealing with alignment.
Definitely a bug that should be reported to MS. In fact the whole thing
changing your partitioning should be considered a bug, you set it up the way
you want it and it undoes it, not a good thing (where's the media ?)
"SaliesBuzz" wrote in message news:10613@public.image...
Having upgraded several machines to the latest Windows 10 v10586 1511, it
would appear that the upgrade does create a 450mb recovery partition,
irrespective of there being sufficient free space after the Windows 10
partition.
It appears to make no difference if one does this from the downloaded
upgrade or from a mounted ISO.
Like most sensible people, it is easier to back up a Windows partition that
contains everything (Boot, System, Primary etc), as this makes for easier
recovery if there are any problems.
We have clients to whom we have recommended BootIT Bare Metal and Image for
Windows, and we have had to help with the mess that this upgrade had caused.
It looks as though the upgrade will shrink the active in place upgrade
partition by 450Mb and then try to write a 450Mb partition in the space it
thinks it has created. Because it assumes that you have a simple MBR (or
GPT), and appears to to know nothing about EMBR, it stamps all over the
table, and you end up with the subsequent partition trashed. When using
BootIT BM to delete the 450Mb partition you end with 447MB free space, which
shows where the problem lies! The next partition is trashed and is not
recoverable by BootIT BM, other than by a restore, hence the old mantra is
true! Always backup before dealing with anything from Microsoft!
There may be some explanations as to why the upgrade behaves like this:
On one machine we upgraded, there was no additional partition created. This
may be because there was already a recovery partition or that the recovery
was "inside" the existing Windows 10 partition. It may be worth checking
this before the upgrade using:
reagentc /info from an elevated command prompt.
Also, on a machine which only had the basic Windows 10, there was no
additional partition created. Again, this may have been because the Recovery
was already present "inside" the partition or:
With Pro versions and above (in Win 10 this is now just Enterprise), there
is access to the bitlocker. This needs an additional partition to make it
work. Even if it is not activated it may be that the Upgrade assumes you may
activate it and goes ahead and stamps all over your EMBR.
On most "new" machines that come pre-loaded with Windows 10 (and latterly
Windows 8.1), the standard OEM build no longer uses MBR but GPT based
paritions. Because this allows for 128 partitions, it may be that the
Windows 10 upgrade assumes you have a GPT based system, doesn't check this,
and goes ahead and trashes your subsequent EMBR partition.
I have neither the time (or inclination!) to debug another Microsoft mess,
although I suspect that converting to GPT may be the answer.
As long as one is aware of what it might do, you can use BootIT BM to sort
the mess out.
To summarise- Before Upgrade:
Backup all your partitions, especially the one following the one you are
upgrading.
Check your Windows version.
Check that Bitlocker is disabled.
After Upgrade:
Turn off Fastboot, (it is re-enabled).
Check that your other settings haven't been changed, particularly the
privacy ones and the update rules that let you PC be used to update other
computers.
On the plus side I would say the upgrade is worth doing. It appears to run
quicker than the previous version, particularly on old Hardware.
Hope this helps someone who happens this way