Forgot your password?
typodupeerror
Bug Ubuntu Windows Linux

Some Windows Apps Make GRUB 2 Unbootable 429

Posted by timothy
from the windows-is-to-boot-out-not-up dept.
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."
This discussion has been archived. No new comments can be posted.

Some Windows Apps Make GRUB 2 Unbootable

Comments Filter:
  • Re:Solution: (Score:2, Informative)

    by mattventura (1408229) on Saturday August 28, 2010 @05:32PM (#33405392) Homepage
    At least one of the apps mentioned in TFS (Flexnet) runs a service in the background, so running as a non-admin user would make no difference since the service is still privileged.
  • by mysidia (191772) on Saturday August 28, 2010 @05:33PM (#33405400)

    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

  • by The MAZZTer (911996) <megazzt@NoSPAM.gmail.com> on Saturday August 28, 2010 @05:41PM (#33405442) Homepage
    IIRC there's a part of grub.cfg that is marked with comments to not be auto-replaced when grub takes inventory of your linux kernel versions. Put the Windows stuff in there.
  • Re:Move along (Score:3, Informative)

    by arose (644256) on Saturday August 28, 2010 @05:42PM (#33405446)
    Yes, it does. GRUB deals with the boot process, it's one of the things that do have any business of being there.
  • Re:Move along (Score:4, Informative)

    by Anonymous Coward on Saturday August 28, 2010 @05:54PM (#33405498)

    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.

  • by John Hasler (414242) on Saturday August 28, 2010 @05:58PM (#33405526) Homepage
    And yes, LILO is still supported and under development. LILO 23 [debian.org]
  • by John Hasler (414242) on Saturday August 28, 2010 @06:01PM (#33405536) Homepage

    Grub should use an existing partition to store all the bits which don't fit inside the MBR...

    We call that LILO.

  • by FuckingNickName (1362625) on Saturday August 28, 2010 @06:04PM (#33405560) Journal

    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)

    by makomk (752139) on Saturday August 28, 2010 @06:08PM (#33405576) Journal

    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)

    by RobertLTux (260313) <robert@@@laurencemartin...org> on Saturday August 28, 2010 @06:15PM (#33405626)

    sort of the same way a hummer is JATO compatable

  • by alexhs (877055) on Saturday August 28, 2010 @06:18PM (#33405650) Homepage Journal

    It's also called "GRUB with blocklists"

    You can find more here [archlinux.org],
    and in my other post [slashdot.org]

  • by Animats (122034) on Saturday August 28, 2010 @06:20PM (#33405660) Homepage

    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)

    by Anonymous Coward on Saturday August 28, 2010 @06:28PM (#33405714)

    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.

  • by Teun (17872) on Saturday August 28, 2010 @06:43PM (#33405792) Homepage
    /etc/grub.d/40_custom
  • by FuckingNickName (1362625) on Saturday August 28, 2010 @06:57PM (#33405890) Journal

    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)

    by cgenman (325138) on Saturday August 28, 2010 @07:34PM (#33406080) Homepage

    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)

    by Dahamma (304068) on Saturday August 28, 2010 @07:39PM (#33406110)

    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.

  • by couchslug (175151) on Saturday August 28, 2010 @07:45PM (#33406140)

    "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.

  • by alexhs (877055) on Saturday August 28, 2010 @07:49PM (#33406174) Homepage Journal

    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.

  • by Drinking Bleach (975757) on Saturday August 28, 2010 @07:50PM (#33406180)

    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.

  • by FuckingNickName (1362625) on Saturday August 28, 2010 @08:04PM (#33406232) Journal

    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.

  • by FuckingNickName (1362625) on Saturday August 28, 2010 @08:17PM (#33406282) Journal

    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.

  • by Skapare (16644) on Saturday August 28, 2010 @09:42PM (#33406566) Homepage

    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.

  • by Skapare (16644) on Saturday August 28, 2010 @09:58PM (#33406648) Homepage

    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)

    by clint999 (1277046) on Saturday August 28, 2010 @11:30PM (#33406978) Homepage Journal
    Don't run those apps as administrator. Administrator privileges are needed for raw disk access.
  • Re:Move along (Score:3, Informative)

    by Dahamma (304068) on Saturday August 28, 2010 @11:37PM (#33406996)

    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...

  • by peterhoeg (172874) <peter@h[ ].com ['oeg' in gap]> on Sunday August 29, 2010 @01:07AM (#33407252) Homepage

    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]

  • by ultranova (717540) on Sunday August 29, 2010 @05:47AM (#33407924)

    I bought Fallout 3 for PS3 on sale since the PC version I bought on Steam consistently froze after a scant few minutes of play. Should I as an end consumer really need to dig into minutiae of Windows settings to try and tweak it enough for a game to run properly?

    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.

    I thought we had left the bad old days behind us.

    "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.

    Repeat after me: PCs for surfing and work, consoles for games.

    Consoles are for people who's Google-Fu is weak.

One small step for man, one giant stumble for mankind.

Working...