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."
It makes sense for a bootloader to place data and code outside of partitioned space. It makes more sense to place the code inside a partition, even if it's a one-track partition dedicated to the bootloader. If they collided with components of Windows' bootloader or FreeBSD's bootloader, or some pre-boot hard disk encryption software I'd have little sympathy for them.
On the other hand, user-level apps storing data on the hard disk outside of partitioned space is very bad mojo. They should not be doing that. Ever. Period.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Bingo. It is absolutely wrong to put data outside of partitioned space, and it is insane to blame something else for your own bug. Indeed, one security measure when installing a new system might be to zero out all unpartitioned space and then make sure nothing is ever written to it - Grub makes this impossible.
Grub should use an existing partition to store all the bits which don't fit inside the MBR, following the lead of EFI system partitions if necessary but supporting various common filesystems otherwise. Instead they use an atrocious hack to try to make things look neat.
Does grub have any more reason to be there these other companies?
It does if I put it there. Nothing should be automatically written into partitioned space. Partitioning defines what areas of the disk I want to be automatically written to using whatever scheme I define by setting the partition type. Anything outside that, I'm free to manage any way I please. I can put a block-oriented FORTH program there if I like, individually managing "screen" loads and saves in the FORTH code. Or whatever. The point is, they're my blocks to do with as a like, and nothing should be written there except what I explicitly write there.
Among other things, it does mean that if I choose to write GRUB data there, it should be perfectly safe there. If it isn't, that's a serious bug in whatever program overwrote the unpartitioned block(s).
"Convictions are more dangerous enemies of truth than lies."
The whole point behind VMs is to make the host as reliable and stable as possible and put the flakier OS and software in a VM so when it crashes and burns, all one has to do is start the VM, not try to rebuild file structures and apps from scratch. Your post suggests you're not quite clear on the concept.
Unless you honestly believe that "Son of Vista" is more reliable and stable than Linux. In which case, I recommend you get help from a competent mental health professional.
Tech Public Policy stuff