Some Windows Apps Make GRUB 2 Unbootable 429
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."
Re:Solution: (Score:2, Informative)
Re:I thought nothing was supposed to be there (Score:5, Informative)
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
Re:So that's what happened... (Score:4, Informative)
Re:Move along (Score:3, Informative)
Re:Move along (Score:4, Informative)
Wrong, GRUB belongs in the MBR, not in some unpartioned space that is not supposed to be of use, if they have a problem with that, just keep that thing (GRUB) small or create a partition.
LILO is immune to this. (Score:5, Informative)
Re:WTF is the "embedding area"?! (Score:3, Informative)
We call that LILO.
Re:I thought nothing was supposed to be there (Score:4, Informative)
The "boot block" is precisely one sector right at the start of the fixed disk, with some space being taken up by the primary partition table, signature, etc. The problem is not Grub (and certain Windows software) writing to this area, but writing to unpartitioned space elsewhere on the drive.
This is as wrong as looking at some filesystem, discovering that certain free blocks are unlikely to be allocated, and then using that space for storage.
Re:Solution: (Score:5, Informative)
Of course, Flexnet is apparently quite capable of making Windows unbootable too [adobe.com], at least if you're using TrueCrypt. Say no to badly-designed DRM!
Re:Move along (Score:3, Informative)
sort of the same way a hummer is JATO compatable
Re:WTF is the "embedding area"?! (Score:5, Informative)
It's also called "GRUB with blocklists"
You can find more here [archlinux.org],
and in my other post [slashdot.org]
FLEXnet, Adobe's rootkit (Score:5, Informative)
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. [wikipedia.org] 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.
Re:Move along (Score:2, Informative)
This isn't actually true. It used to be. Windows NT was POSIX.1 compatible (which is not very useful, and definitely doesn't imply that you can take POSIX software and run it on Windows NT without significant porting effort).
But Microsoft removed that feature from Windows XP onwards. Now the only way to get POSIX compatibility in Windows is to download and install a separate component that adds limited POSIX capabilities. Frankly anyone who cares about POSIX will just use an actual UNIX or a clone like GNU/Linux.
Re:So that's what happened... (Score:3, Informative)
Re:WTF is the "embedding area"?! (Score:2, Informative)
There is not a 4 partition limit. MBR allows infinite partitions (space-permitting) within the extended partition - even more than GPT, in theory.
And there is no reason you can't boot from a logical partition - it's just a problem for Windows because of the way it computes distances from the start of extended partition vs whole disk, and that can be fixed by fiddling with the boot sector for the partition.
What's to prevent one of these programs from overwriting the data another makes?
Nothing should be doing it. But what's happening here is some badly behaving Windows program exposing a fault in Grub. The article title is misleading.
Re:Solution: (Score:5, Informative)
If I'm not mistaken, Flex is required for Photoshop, Illustrator, Dreamweaver, Flash, InDesign, and After Effects. Except for After Effects, you won't find any real professional-level alternatives for any of them.
Try telling upper management that you banned your $100 an hour designers, artists, and developers from the tools they need to do their jobs, because you were worried about bootloader compatibility and proper code behaviors.
Re:Move along (Score:4, Informative)
The way most other boot loaders have done it (including the original GRUB). Put enough code in the MBR to load the rest of the code and config out of a second location. The smart ones actually use a real partition for that, though, so no one overwrites it.
Re:WTF is the "embedding area"?! (Score:3, Informative)
"where would I get another partition for Grub to run from without deleting all the recovery data?"
I just make recovery media and blow the old partitions away.
Re:WTF is the "embedding area"?! (Score:3, Informative)
Wait wait wait, I have to specify the specific blocks to load now?
No you don't. GRUB will compute the blocks and store them in the MBR. It's "unreliable" because if the file to be loaded is physically moved/modified, the loader will be broken.
I've written a toy partition bootloader over a weekend which was able in around 400 bytes to load and execute any file on a FAT filesystem.
I bet you mean that you wrote a program to which you gave the path of a COM file that would in turn write the MBR so it would load and execute that file. And it happened to work with your BIOS and the files you tried it with (did you try with files physically located after 8GiB ? on an old broken BIOS ?)
So what ? That's basically what LILO and GRUB stage 1 are doing.
And another for the MBR gave a menu of primary and extended partitions for keyboard selection.
Basically what the Debian mbr package does. That's chain-loading. (Could you really boot an extended partition ?)
What is the Grub project finding so difficult?
Go read the documention to get what features GRUB1 [gnu.org] and GRUB2 [enbug.org] have.
GRUB is a shell, understand many filesystems, can boot a variety of OS (many of which are requiring multiple files being loaded at specific addresses), from a variety of devices (including netboot), does switch to protected mode, and much more.
It happens that all these features are not fitting in the at most 446 bytes available in the MBR.
Re:WTF is the "embedding area"?! (Score:4, Informative)
What's wrong with FAT? Pretty much everything from space inefficiency to lack of permissions to filename restrictions to reliability issues, especially after unclean shutdowns.
Also GRUB's core.img already only supports one filesystem -- whichever one is /boot (which can be FAT, GRUB can do that as well), filesystem modules for other types if necessary are loaded directly from said /boot partition.
Re:WTF is the "embedding area"?! (Score:1, Informative)
What's wrong with FAT? Pretty much everything from space inefficiency to lack of permissions to filename restrictions to reliability issues, especially after unclean shutdowns.
Why does your bootloader partition need to concern itself with space efficiency, permissions and filename restrictions? And why are you not doing synchronous writes to critical areas, ordered such that no single sector write will corrupt a file? I doubt Grub replays the journal before boot, so journaling won't help.
Finally, please explain why a non-standard storage in unpartitioned space solves any of the listed problems.
Put another way, explain why EFI is wrong to use FAT and say what should have been done.
Re:WTF is the "embedding area"?! (Score:2, Informative)
No you don't. GRUB will compute the blocks and store them in the MBR. It's "unreliable" because if the file to be loaded is physically moved/modified, the loader will be broken.
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?
I bet you mean that you wrote a program to which you gave the path of a COM file that would in turn write the MBR so it would load and execute that file.
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 :-).
And it happened to work with your BIOS and the files you tried it with
Well, it happened to work on half a dozen machines built over the past 12 years and every VM I tried it on.
did you try with files physically located after 8GiB ?
Yes. This isn't 1995 any more. INT 13 extensions are supported.
on an old broken BIOS ?)
Probably not. What kind of old and broken are you contemplating?
So what ? That's basically what LILO and GRUB stage 1 are doing.
Really? So why does GRUB need any extra-partition space?
Could you really boot an extended partition ?
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.
GRUB is a shell, understand many filesystems, can boot a variety of OS (many of which are requiring multiple files being loaded at specific addresses), from a variety of devices (including netboot), does switch to protected mode, and much more.
It happens that all these features are not fitting in the at most 446 bytes available in the MBR.
Which is why it should load a second stage from a system or other partition.
Re:WTF is the "embedding area"?! (Score:3, Informative)
A 512 byte sector (MBR) does not have enough space for code to read a filesystem. So either you waste a whole partition just for the next bootloader stage ... which in the days of MBR partitions, there were not enough available to do that ... or you just sequence the sectors after the MBR, which then gives enough space to load minimal filesystem read-only support. LILO can play tricks to fake raw sectors inside a filesystem, but that is a very fragile setup that breaks whenever the filesystem is changed.
It has been quite normal for decades to have boot loader code in the sectors right after the MBR. It has never been normal for any other code to put anything here.
With the new GUID Partition Table [wikipedia.org] (GPT) format, there are 128 partitions available. That's enough to use one or two for boot loader extra code. Any demands for bootloaders to put their next stage code inside a partition should be paired with the demand to use GPT, too.
Re:It is free for all region (Score:3, Informative)
It is legacy that the system "owns" the entire first disk track, not just the first sector. In the case of PCs with 63 sectors per track, that means all sectors from 0 to 62 which make the first track. It would be fewer sectors for smaller tracks in different geometry.
Re: (Score:0, Informative)
Re:Move along (Score:3, Informative)
Yeah, that's actually why most Linux distros recommend a "/boot" partition that is as simple as possible (ie ext2, not a journaling fs). Once the files are written to that partition, it stores the exact location of the executable and config files into the MBR so that it can find them.
At least that's how "GRUB 1" worked... sounds like "GRUB 2" tried to be clever and it didn't work out so well...
Re:WTF is the "embedding area"?! (Score:2, Informative)
The BIOS isn't the limiting factor when booting from a GPT disk - the OS is or rather the OS's boot loader.
Windows will not let you boot from a GPT disk on a non-EFI machine, but Linux (using GRUB2 or a patched GRUB1) works perfectly fine with GPT on my two machines here.
Take a look at this page: http://www.rodsbooks.com/gdisk/booting.html [rodsbooks.com]
Re:"built his house upon the sand" (Score:3, Informative)
This has nothing to do with Windows and is a Fallout 3 bug [sevenforums.com]. And no, a mere consumer couldn't figure it out, so he'll end up buying the same thing twice.
"Bad old days" return whenever there's some new development in hardware. The use of protected mode - first through DOS extenders and later through pmode OS freed us from messing around with DOS's memory types, but then 3D accelerator cards arrived, with their proprietary APIs of course. Now everyone uses Direct3D or OpenGL, but multi-core has arrived, forcing games to switch to parallel execution, and bugs result during transition. Compute shaders - using the 3D accelerator as a math co-processor - is the newest fad; we'll see what new problems arise from there.
Consoles are for people who's Google-Fu is weak.