On 2012-11-07 11:32 (GMT+0100) Chris Murphy composed:
Felix Miata wrote:
It only "squelches" when its installer finds MBR code that is incompatible with the legacy PC BIOS standard, which is to say code that results from installing any portion of Lilo or Grub in the MBR code space.
Isn't it true that grub2-install always replaces this 440 bytes of code in the MBR code region?
Last I checked, installing either Grub to a partition leaves the MBR untouched, as well it should.
Windows' bootloaders are well enough understood that, for single HD BIOS systems at least, it should require no more than a relatively simple algorithm to create an additional entry in the Windows boot menu, forcing its menu to appear at each boot, and allowing the user to choose between Windows and Linux at boot time.
It would be nice to leverage this instead of clobbering it with GRUB, however it can't directly bootload linux. So while it could be the boot manager, it would have to redirect the process to a linux capable bootloader. And that's a bit problematic…
Not really. Any scripting device capable of creating a new boot.ini entry is certainly capable of creating a file on the same filesystem by a dd of the boot sector where the Linux bootloader is installed. I failed to mention in my prior post that such a file is always necessary for Windows to "boot" Linux. If the Linux bootloader menu is configured with a 0 timeout, there's no visible indication to a user that Linux was not directly booted via the Windows boot menu.
Once this is done, it should make no significant difference whether Windows "squelches" the MBR by flipping two partition table bits. After it does so, it's a very simple and quick process to unflip them if it is desired to restore master boot loader status to the Linux bootloader installed on a Linux native primary partition.
Unfortunately ext[234] lack a sufficiently large enough offset (or a modifiable offset) into which an up to 64KB GRUB bootloader (stage 1.5 or core.img) can reside. To put the bootloader on a linux primary partition using ext[234] means using blocklists from the outset and that means to expect fragility in bootloading.
Boot fragility is a practical given multibooting Linux and Windows. I see no material difference in degree of fragility between disrupting Windows expectation of MBR content and the use of blocklists.
IMO the Grub2 designers from the outset loaded the "rewrite" of the original Grub with poor decisions. It's been an ambitious and complicated project deserving of its own native partition, and for its use on BIOS systems, a primary only.
Meanwhile, all distros should be providing alternate bootloader options that include Grub Legacy at least. *buntu's early Grub2 adoption taught me that early on. None of my multiboot systems have Grub2 installed as a master bootloader. Only *buntu has been allowed to install Grub2, and then only to its /. All other distros offering no other option have no bootloader installed, and depend on me manually creating an entry in a menu.lst file to boot them from. Those that offer no no bootloader option as an alternative to Grub2 don't get installed at all.
-- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
