Slashdot Mirror
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."
Protecting your laptop from open source commies. And maybe viruses.
Nothing is supposed to be there except the user-installed system boot code, boot data, and hard drive parameters.
Third party software certainly has no business messing with Sector 0 or the boot blocks unless it gets explicit permission, advises users of the risks in messing with the boot block, prompts the user to back anything up that's there right now, and writes its bits only to the portion of the boot block that is provided for its required purpose.
It may detect bootloaders, and update their configuration, if the user accepts that, but bootloader configuration is generally stored on the boot volume not the boot block
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.
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.
And yes, LILO is still supported and under development. LILO 23
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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 big headache is FLEXnet, Adobe's "license manager". It's a specialized rootkit that gives the remote licensing system access to the machine at a low level. Which is why it tends to break things a Windows application shouldn't be able to break. On Windows, it runs a background service and contacts a remote server frequently, sending undocumented information to the remote server and accepting update commands to change software already on the computer.
FLEXnet is the successor to FlexLM, a licensing system from the 1980s. It started as a UNIX product. It's been owned at various times by Highland, Globetrotter, Macrovision, and Thoma Cressey Bravo. It was unreliable in the 1990s, and the passage of time does not seem to have improved things.
In general, it's best to avoid buying Adobe products which install the FLEXnet license server.
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
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 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.
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.
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.
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.
What about Gimp as a Photoshop replacement?