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."
I thought nothing was supposed to be there (Score:4, Interesting)
... and that's the reason why BIOS 'virus protection' blocks access to that portion of the hard drive. Too bad that DRM breaks everything once again and too bad the mainstream of users isn't affected by it.
WTF is the "embedding area"?! (Score:4, Interesting)
WTF is this "embedding area?" It sound like GRUB is misusing the disk geometry to find unused space and then getting upset that other programs do that too.
Googling for "embedding area" find that it's a term that GRUB 2 made up and that it's not really a part of anything. In fact, apparently this space doesn't even exist under EFI systems, and that this "embedding area" is an artifact from DOS.
So, basically, GRUB is misusing the disk to store information in a place it has no right to be touching, and then getting upset that other people make the same mistake. Genius.
Re:Move along (Score:2, Interesting)
Just proprietary companies fucking up some computers.
Does grub have any more reason to be there these other companies? It looks like nobody is supposed to be there... including grub.
It is free for all region (Score:4, Interesting)
While MBR has some function, the rest of sectors between MBR and the first partition was always a great area.
Many MBR viruses put their stuff there. Many stupid programs use it to store DRM data, so they can check whether they were copied to other computer
If GRUB is using this region too, it is equally stupid. There is no protocol for allocating this area and there is no guarantee that this data is not going to be overwritten by any other stupid program.
So nothing to see here, move aling, it is just Core Wars between stupid programs.
GRUB developers should have known better.
Another example of DRM fail (Score:3, Interesting)
So once again DRM is fucking with peoples' abilities to use their computers. Except this particular bit of DRM doesn't just screw with Windows; it could potentially screw with every OS on your drive (or screw with your ability to access them, at any rate).
Yeah, it's not conventional DRM, but it's a form of DRM in that it restricts the user in some arbitrary way (and, I ought to add, breaks something else in the process... that too should be part of the definition of DRM).
Re:Solution: (Score:5, Interesting)
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"?! (Score:3, Interesting)
which goes to the question of whether or not some of these programs really count as user level. Is anti virus user level? Well it can be, but what about one that blocks rootkits? What about one that is trying do something crazy related to virtualization? What if HP just assumes you're either too stupid to use unbuntu on your computer or are smart enough to not use their terrible software anyway?
PC angel and HP protect conceivably live outside the OS level, well actually they do basically the same thing GRUB does, which is allow you to boot into another OS. They just aren't full blown OS's (PC angel is disk imaging, HP protect is I think aiming to be security before the OS layer). I don't think i've ever used adobe flex, but I can't see why a web creation suite is is writing outside a normal partition. Note: I'm guessing at how HP protect works, but some of their security solutions could conceivably live outside the OS, whether that's a good idea or not is another matter, but they might have a legitimate reason for doing it that way.
if it's a problem of everyone trying to solve the same problem in basically the same way (trying to stick bootloaders all in the same place) it might be a big political win for GRUB, to justifiably create some actual standards so all the OS guys use the same bootloader locations, with their boot info in a standard format so they can all work at once. Though adobe in this one looks like they deserve to be slapped around a bit, if the conjecture is accurate.
Re:HP ProtectTools (Score:4, Interesting)
http://h30434.www3.hp.com/t5/Operating-systems-and-software/New-laptop-harddrive-non-OEM-Vista-disk/m-p/314927 [hp.com]
Re:WTF is the "embedding area"?! (Score:2, Interesting)
Wait wait wait, I have to specify the specific blocks to load now? And ...?
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and its use is discouraged.
grub-setup: error: If you really want blocklists, use --force.
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. And another for the MBR gave a menu of primary and extended partitions for keyboard selection. What is the Grub project finding so difficult?
Re:Another example of DRM fail (Score:2, Interesting)
Not only that, but if somebody figured out which software used such DRM... Hypothetically they could get at that bit by comparing the overwritten GRUB to the normal GRUB, and then start their reverse-engineering hacks against the DRM portion since it's no longer hidden.
DRM that writes to the same spot every time without any checks sounds like something with a big "CRACK ME" target painted on it. Now its just a matter of time until figuring out which software does this.
Turbo Tax Did It First (Score:3, Interesting)
We've been down this road before. In 2003, Intuit's Turbo Tax (for tax year 2002) pulled the same stunt [goodells.net], indiscriminately overwriting sectors at the beginning of the disk (outside any partition) and trashing people's bootloaders.
All in the futile pursuit of DRM. That's reason enough for me to use Tax Cut, instead, every year since.
Re:Move along (Score:3, Interesting)
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.
How do you plan to boot from an arbitrary Linux partition using a 512-byte boot loader?
Re:Another example of DRM fail (Score:3, Interesting)
"DRM that writes to the same spot every time without any checks sounds like something with a big "CRACK ME" target painted on it."
Good. The sooner it's cracked the sooner it may go out of fashion. :)
Nothing new (Score:4, Interesting)
Re:WTF is the "embedding area"?! (Score:5, Interesting)
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.
Re:Move along (Score:5, Interesting)
Heh, funnily enough that's exactly what Windows 7 does. If you install it to an empty drive, it'll create two partitions - one small one (a couple hundred megs?) for the boot loader, and the rest for Windows itself.
Flexlm rant (Score:5, Interesting)
A later MS Windows version I had the misfortune to use had a Y2K bug in 2008! With an update our perpetual licences were marked as expired in 2000. It took two weeks to get a fix out of Macrovision.
Re:It is free for all region (Score:3, Interesting)
It has been tradition for the system (bootloader, OS, etc) to "own" the first track (which can mean up to 63 sectors on PCs with legacy CHS MBRs). MBR doesn't have enough partitions to waste. With GPT, now you have 128 of them, though GPT uses 34 sectors, not just one (and a duplicate set at the end of the drive for backup). The decent way out of this is to leave the first entire track to the system.
Re:Solution: (Score:3, Interesting)
What if you want games on both? This would be especially true if you do any kind of cross-platform development.
Plus, if you share a computer with others it's often not feasible to require them to startup a VM to use Windows.
The main reason my system dual boots Windows is as a backup - if I need Linux functionality or my Windows installation is screwed up, then I can use Linux instead. Windows is still the primary OS, so dual booting is still the best choice.
Re:Solution: (Score:4, Interesting)
Virtualization is the last refuge of a horrendously mis-engineered operating system.
Re:Solution: (Score:3, Interesting)
Or, better, don't.
Linux is not meant to run under Windows. If you want to run Windows, by all means run Windows and don't waste anyone else's time.
HP restore partition (Score:2, Interesting)
On my HP laptop, whenever I enter the restore partition software screen by hitting F11 on the BIOS screen, it resets the boot partition to the Windows loader.
No need to actually tell the restoration software to do anything, you can just enter it and exit straight away; it simply removes any bootloader installed automatically with no confirmation beforehand.
I actually found this "feature" useful when I wanted to remove a Linux installation gone bad, as it saved me the trouble of restoring the Windows bootloader.
Nevertheless, this is outrageous.
Re:LILO is immune to this. (Score:3, Interesting)
I really like one thing about GRUB2; you can add linux live-cds there:) I have a USB memory with ubuntu installed on it + live cds for the latest ubuntu version in the grub menu.
Not open to discussion? (Score:3, Interesting)
LILO put the blocks addresses of the boot file into the boot loader. Of course, this has two major problems:
1 - Every time the boot file is updated, the boot loader needed to be updated. A simple command sufficed. But this problem absolutely PAILED in the face of the second issue...
2 - The boot file was limited in size, Only a fixed number of addresses could be coded into the boot file. But, this problem was partially "fixed" by the third issue:
3 - (I did two MAJOR problems, this is a minor issue). The boot loader operates in REAL mode on the x86. As a result, the code must load under 640K. But, since the boot file is of limited size ANYWAY, this one really didn't matter so much.
Of course, since the "MBR loader" is under 1 sector (the forced jump, checksum, and primary partition areas do take space, and these are BIOS-checked), there really isn't even room for a device driver. This code is pretty much forced to work in real-mode, but that's actually a good thing -- it can make use of BIOS interrupts for the disc handling. But...
4 - The boot is limited to a BIOS reachable (disc geometry) region. That is why some OSs MUST be loaded into the first 528MB (or so, it's really been a while since I've looked at this crap, sue me if the actual is different) region.
Now, different OSs attempt to get around these limitations in different ways. A boot loader can chain to a partition-specific boot loader, which serves to "push" the issues. Some OSs (cough, DOS, cough) simply force the OS image to be contiguous and the first thing in a partition. But, users don't (generally) WANT to be bothered with these issues. Where the OS is physically resident, HOW it loads, and how to keep its size within constraints. Linux can be built with built-in drivers, minimal drivers, etc. Using many different file systems...
So, GRUB attempts to address these issues. If you think you can do better (and, from your fairly arrogant tone, I think you do think so), have at it.
Re:WTF is the "embedding area"?! (Score:5, Interesting)
> Though adobe in this one looks like they deserve to be slapped around a bit, if the conjecture is accurate.
Adobe deserve to be slapped around a bit (and then a bit more). Period.
Otherwise I think the problem is (again) the BIOS. It only loads the 1st sector to boot, when 63 sectors (or 2048 with EFI) are reserved. Back in the old days you could just fit some FAT16 code in there to find the DOS image - but only at the expense of error handling. Nowadays you have to load the next stage from a fixed position - and the only position that is certainly fixed are the other 62 sectors. So they are the logical place for a boot loader.
You could add a boot partition, but with only 4 partitions available, that would use up a very limited resource. And I guess even if you put a boot partition into the first 63 sectors (which is now perfectly possible), Adobe would still overwrite it (and Windows would possibly freak out).
Separate drives (Score:3, Interesting)
Re:Solution: (Score:3, Interesting)
No CMYK, no replacement for Photoshop. Unfortunately.
Never fear, he was trying to be funny.
Although I disagree with them -- another interface is a big hit to productivity.
I agree.
Remember New Ribbon. :)
Trying not to.
Re:Separate drives (Score:3, Interesting)
I did something similar. Windows is on my first hard drive (/dev/sda or C:, depending on your point of view) and Linux is on /dev/sdb or D:. I have the BIOS boot /dev/sdb, which is where Grub is. Then, when I boot to Windows, it never has any reason to mangle /dev/sdb, because it sees it as an unformatted D: drive.
So, these sorts of apps can do whatever they want to the first few sectors of /dev/sda, as long as Windows continues to boot, and Linux and GRUB are left untouched.
Re:Wow, it's Rip Van Winckle! (Score:3, Interesting)
Wow, it's Rip Van Winckle!
"Probably not until xorg and the linux kernel get decent 3d support for ati or nvidia. (decent meaning at least as fast the closed source drivers for a large subset of openGL and fully implements all the 3d functions of the closed source drivers.)"
The nVidia linux driver IS their closed source driver, FWIT.
And AMD have released a full 3D open source GPL compliant driver for their recent cards.
Please, go back and read some news sites from 5 years ago, they'll fill you in on what you missed while asleep.
Nouveau is the open source nvidia driver, The opensource AMD driver is much slower than the closed source fglrx ati drivers, This is slowly changing and nouveau is becoming closer to feature complete.
Progress is either happening very quickly or very slowly in this regard, depending on your perspective, from the end users point of view the stability is getting worse, as lots of slow stable code is discarded for new code that eventually will be much faster, but for the moment is the worst of all worlds. From the developer point of view, the specs are open the code is starting to work, and the features are being complete at a pretty amazing rate.
I would guess that the big event in Linux graphics is going to be when a release includes nouveau as the default and drops the NV and support for the nvidia.
What you don't seem to get is that unless there is a well documented opensource graphics subsystem, it won't be virtualized with near native speed.