If you find that running Windows makes a GRUB 2-based system unbootable
(Debian bug, Ubuntu
bug), then I’d like to hear from
you. This is a bug in which some proprietary Windows-based software
overwrites particular sectors in the gap between the master boot record and
the first partition, sometimes called the “embedding area”. GRUB Legacy and
GRUB 2 both normally use this part of the disk to store one of their key
components: GRUB Legacy calls this component Stage 1.5, while GRUB 2 calls
it the core image
(comparison).
However, Stage 1.5 is less useful than the core image (for example, the
latter provides a rescue shell which can be used to recover from some
problems), and is therefore rather smaller: somewhere around 10KB vs. 24KB
for the common case of ext[234] on plain block devices. It seems that the
Windows-based software writes to a sector which is after the end of Stage
1.5, but before the end of the core image. This is why the problem appears
to be new with GRUB 2.

At least some occurrences of this are with software which writes a signature
to the embedding area which hangs around even after uninstallation (even
with one of those tools that tracks everything the installation process did
and reverses it, I gather), so that you cannot uninstall and reinstall the
application to defeat a trial period. This seems like a fine example of an
antifeature, especially given its
destructive consequences for free software, and is in general a poor piece
of engineering; what happens if multiple such programs want to use the same
sector, I wonder? They clearly aren’t doing much checking that the sector
is unused, not that that’s really possible anyway. While I do not normally
think that GRUB should go to any great lengths to accommodate proprietary
software, this is a case where we need to defend ourselves against the
predatory practices of some companies making us look bad: a relatively small
number of people do enough detective work to realise that it’s the fault of
a particular Windows application, but many more simply blame our operating
system because it won’t start any more.

I believe that it may be possible to assemble a collection of signatures of
such software, and arrange to avoid the disk sectors they have stolen.
Indeed, I have a first draft of the necessary code. This is not a
particularly pleasant solution, but it seems to be the most practical way
around the problem; I’m hoping that several of the programs at fault are
using common “licence manager” code or something like that, so that we can
address most of the problems with a relatively small number of signatures.
In order to do this, I need to hear from as many people as possible who are
affected by this problem.

If you suffer from this problem, then please do the following:

Save the output of fdisk -lu to a file. In this output, take note of
the start sector of the first partition (usually 63, but might also be
2048 on recent installations, or occasionally something else). If this
is something other than 63, then replace 63 in the following items with
your number.

Save the contents of the embedding area to a file (replace /dev/sda
with your disk device if it’s something else): dd if=/dev/sda of=sda.1
count=63

Do whatever you do to make GRUB unbootable (presumably starting Windows),
then boot into a recovery environment. Before you reinstall GRUB, save
the new contents of the embedding area to a different file: dd
if=/dev/sda of=sda.2 count=63

Follow up to either the Debian or the Ubuntu bug with these three files
(the output of fdisk -lu, and the embedding area before and after
making GRUB unbootable.

I hope that this will help me to assemble enough information to fix this bug
at least for most people, and of course if you provide this information then
I can make sure to fix your particular version of this problem. Thanks in advance!