05.08.11
Windows Killer Feature: It Kills GNU/Linux Partitioning
Summary: Microsoft uses system updates in Windows to eliminate access to one’s GNU/Linux partition/s, despite repeated complaints from users
VISTA 7, despite all the vacuous marketing, is no different than its predecessors when it comes to anti-competitiveness. In many ways, it is a lot worse. Microsoft is not only preventing OEMs from offering GNU/Linux as an option, but it is also destroying GNU/Linux partitions that exist outside the Windows one. Microsoft has done this type of thing for decades as we explained in posts such as:
- Microsoft Continues to Sabotage GNU/Linux Installations Using ‘Updates’
- Microsoft Still Sabotages Linux MBRs in Vista 7
- The History of Microsoft’s Multi-boot Sabotage
Jamie Watson explains that Microsoft is still doing this, even with system updates in an age of a mythical ‘new Microsoft’. Jamie is rightly upset because he needs to spend time wrestling with what most people would not even know how to resolve. “Windows 7 Declares War on GRUB” is his headline and the level of Microsoft’s intrusion is inexcusable:
Windows then informed me that it had another “Important Update” to install, so I let it do that, rebooted, and it seemed ok. But of course, this being Windows we have to stick to the absolute, inviolable Microsoft philosophy – “Why do it simple when you can do it complicated?”. Shortly after rebooting from that update installation, it informed me that it had even more “Important Updates” to install, including Windows 7 SP1. Sigh. So I let it do that… of course, it slogged around for an hour or so downloading and trying to install the update(s), before it finally informed me that the installation had failed, please reboot.
Here we go again… I tried to reboot, and Windows Update had scribbled on the MBR again. ARRRGGGGHHHH! Boot openSuSE Live USB, repair GRUB, boot openSuSE from disk, all is well. Boot Windows, it thrashes around in “Phase 3″ for a while again, then seems to be ok, but when I tried to reboot after that, GRUB was corrupted again. ARRRGGGHHH! At this point I was ready to just give up, go to the class next week and tell them that I am not interested in training on a stupid, broken, unreliable, uncooperative tinker-toy operating system. But I am too stubborn for that, I’m afraid. So now I am doing a “factory restore” on the dm1, and then I will go through all of the Windows Update installations before installing Linux and GRUB on it. If it still fails after that, I will print out the quote above and hand it to the instructor on Monday. Sigh.
So, there you have it. What’s going on? Has Microsoft simply decided that they won’t tolerate GRUB, or anything other than their own crummy bootloader? Or are they just so stupid and narrow-sighted that they don’t care, and don’t bother checking before they start scribbling on the disk in the place where they assume their bootloader should be? Or are they so incompetent that this is all just another ridiculous Microsoft “bug”, and if I sit tight and wait for the next “patch Tuesday” or whatever, it might go away?
Where are the antitrust regulators? According to some new statistics, the market share of GNU/Linux on the desktop keeps growing. Microsoft must not be allowed to pull the above tricks. █
Content is available under CC-BY-SA
saulgoode said,
May 8, 2011 at 6:26 am
I do not think there is enough basis for an anti-trust intervention.
My understanding is that there is a small amount of space residing on a boot disk between the MBR and the first partition. The PC BIOS specification does not establish how this space (the “MBR gap”) should be used. GRUB, if installed to the MBR, will use the MBR gap space for storing its Stage 1.5 code and it is possible that the problem Mr Watson encountered is owing to the Windows update placing its own data in the space and corrupting the GRUB code.
If such is the case, Microsoft could claim to be merely abiding by the specification and that they have just as much a right to that MBR gap space as GRUB. At least that would be the legal argument.
Though it is always risky to rely upon unspecified behavior from a standard (even a de facto one), from a technical standpoint, my view would be that the MBR gap space should be controlled by whatever boot code is in the MBR; if Microsoft’s NTLOADER is used then MS should regulate the gap space, if GRUB is installed then it should control the gap space.
It is extremely poor practice on Microsoft’s part to ignore the possibility that their customers may wish alternative code to control the boot process, but it is not necessarily contrary to the PC BIOS specifications (notably, the GRUB installer takes the more friendly approach of issuing a warning and aborting installation if it detects the MBR gap space is already in use).
Whether because of incompetence, apathy, or actual malice, Microsoft’s lack of consideration of its customers provides sound reason to reject Windows, but it does not necessarily meet the legal threshold of abusing their monopoly.
twitter Reply:
May 8th, 2011 at 7:20 am
Given Microsoft’s prior convictions as a coercive monopoly and proven history of MBR malice, we must conclude that Microsoft’s actions in this case are malicious. There’s more than enough grounds for anti-trust enforcement and every gnu/linux desktop distribution should complain. Red Hat, Canonical, Mepis and many others will be irrevocably harmed by this and society should not wait for private lawsuits to fix it. Notice that this is happening the month of shutdown for the last anti-trust oversight shutdown?
Users should not wait for government relief. The best solution is to dump and ignore Windows, especially the new versions which don’t have a real presence on corporate networks. Time wasted on Windows is time not spent learning how to get the job done with free software.
An immediate technical relief for Mr. Watson would be to run Windows 7 in Virtual Box or use disk swapping. Chances are that Windows 7 has hooks to detect it is being run in a Virtual machine and will abort, so disk swapping is probably the only option for people who must use Windows.
I’d rather scrub toilets for a living than support an abusive monopoly with my time and effort but the choice is rarely that stark. The more we use free software, the less people will be abused.
Needs Sunlight Reply:
May 9th, 2011 at 5:14 am
M$ has been aware of the bootloader or a long time:
http://www.birdhouse.org/beos/byte/30-bootloader/
Dr. Roy Schestowitz Reply:
May 9th, 2011 at 9:09 am
In Microsoft’s eyes it must be a feature, not a bug.
Dr. Roy Schestowitz Reply:
May 8th, 2011 at 9:59 am
IIRC, it was Microsoft’s Bill Hilf who blamed this on technical difficulties. So I guess what one GRUB developer can do a 85,000-employee company cannot.
assemblerhead said,
May 8, 2011 at 10:17 am
This has been a problem for a long time.
My desktop has two HD’s sitting next to it. One boots Win32, the other Linux. Which drive is hooked up depends on what I am doing.
This is the only way I have been able to get around this.
(Besides, when Windoze crashes you don’t have to format or risk the Linux drive / partitions in the reinstall.)
Dr. Roy Schestowitz Reply:
May 8th, 2011 at 10:25 am
Microsoft is not even trying to address the issue. That’s the problem.
assemblerhead Reply:
May 9th, 2011 at 5:15 pm
Agreed.
They think the problem belongs to somebody else.
They probably didn’t bother to check for the new BIOS/UEFI LBA translation either. For people with the newest machines and 3TB+ size HDs. The DOS/Win MBR won’t work correctly on those. (Linux does!)
Remember Kerberos and how M$ did its implementation of that? Could be more of the same …
twitter Reply:
May 9th, 2011 at 6:16 pm
It’s more like they think they’ve created a problem for someone else. They have but these problems they create have a tendency to blow back on them. People conclude that Windows is malware and dump it.