Some Windows Apps Make GRUB 2 Unbootable

KwahAG writes "Colin Watson, one of the Ubuntu developers, published in his blog information about Windows applications making GRUB 2 unbootable. Users of dual-boot Windows/Linux installations may face the problem, which boils down to particular Windows applications (Colin does not name them, but users point at least to HP ProtectTools, PC Angel, Adobe Flexnet) blindly overwriting hard disk content between the MBR and the first partition destroying information already stored there, in this particular case — the 'core image' of GRUB 2 (GRand Unified Bootloader) making the system unbootable."

Comments

Re:Solution:

[mysidia]

This is not a problem for the most important Linux systems which are not dual boot.

Most systems that are dual boot are workstations, not servers. Meaning the person who uses the system every day is most likely using Linux.

I think the solution is for the Linux installer to create Windows icons and a Start menu item group with two things.... A "boot Linux" icon (for launching loadlin)

And a "fix grub" icon, for fixing grub, no matter what some dastardly windows program has done to it.

Re:WTF is the "embedding area"?!

[vadim_t]

I wasn't imagining that I was forced to manually type out a list of blocks occupied by the file. But I was concerned by exactly what you say. Dear God, why do it like that?

It's the same thing LILO did, which is why most people use Grub now.

And the reason why is because the MBR is tiny, and has no room for code that reads say, ext4.

The MBR did the boot menu and loaded the boot sector from any given partition. That boot sector would do as you say. You don't need to "bet" - it's pretty much what I said :-).

The MBR has no menu. The basic stuff is "find active partition, load first sector, jump to it". With Grub it's more like "load code from embedding area, run it". Which contains enough to read things like ext4 to load the rest.

Really? So why does GRUB need any extra-partition space?

Because there's no room for filesystem reading code in the MBR. Especially not for reading all the formats Linux supports at once (what if you want to boot from FAT, ext3 and zfs?)

If you're thinking grub should load the code from some fixed space in the Linux partition, then every single FS would have to agree to reserve that space. Including the ones like JFS that come from elsewhere.

Why wouldn't you be able to retrieve the boot sector of an extended partition? Obviously some operating systems (Windows) will assume they're booting off a primary partition and break unless their boot sector is tweaked, but this isn't inevitable.

In my understanding, a partition having a boot sector is a DOS convention, that other filesystems don't necessarily follow. I think 512 bytes at the start may be mostly guaranteed, but again, you're not going to read things like reiserfs in that little space, so you're back to having the same problem.

Which is why it should load a second stage from a system or other partition.

It can't read it from "other partition" because if there is a filesystem there, it has to understand it, and 446 bytes is not enough.

If you mean a special, reserved partition, then that reduces the number of primary partitions for other purposes to 3, which creates compatibility issues. And if there are 4 primary ones already, you're screwed.

Resuming: the way x86 computers boot sucks, and boot loaders have to be written with those constraints in mind. The whole "embedding area" is a horrible hack, but the alternatives have significant issues as well.