From 722e59f1718fa73e69aa5b6ecf1d38df2bc03e8b Mon Sep 17 00:00:00 2001 From: Colin Watson Date: Sat, 28 Aug 2010 00:47:21 +0100 Subject: [PATCH] Windows applications making GRUB 2 unbootable --- ...ws-applications-making-grub2-unbootable.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 debian/2010-08-28-windows-applications-making-grub2-unbootable.txt diff --git a/debian/2010-08-28-windows-applications-making-grub2-unbootable.txt b/debian/2010-08-28-windows-applications-making-grub2-unbootable.txt new file mode 100644 index 00000000..3e0ec70a --- /dev/null +++ b/debian/2010-08-28-windows-applications-making-grub2-unbootable.txt @@ -0,0 +1,18 @@ +Windows applications making GRUB 2 unbootable + +

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:

+ + + +

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!

-- 2.30.2