multiboot installation

[Chris Murphy]

On Nov 7, 2012, at 9:52 PM, Felix Miata <mrmazda at earthlink.net> wrote:

> On 2012-11-07 11:32 (GMT+0100) Chris Murphy composed:
> 
>> 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.

I'm suggesting directly loading linux from the Windows bootloader, if it could do it, rather than depending on chainloading another bootloader that's been forced into another partition in a manner upstream says isn't recommended.


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

Changing a single flag state is really inconsequential compared to pushing bits of code the size of needles into a haystack without any reference in the file system as to their location.

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

If there could be an MBR equivalent of the GPT BIOS Boot partition that's known to be exclusive to GRUB and not some other file system, this would be unambiguous and thus more reliable compared to now. But practically I think BIOS firmware that have a problem using GPT and BIOS Grub should be considered a firmware defect.

> 
> Meanwhile, all distros should be providing alternate bootloader options that include Grub Legacy at least.

I think we know that's a total dead end. Only Red Hat was maintaining it and now that's significantly winding down. LILO is a more viable alternative. Heck, waiting another 10 years for UEFI boot managing and loading to sort its merry way out from under a rock is more viable.

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

Look there's really nothing great about either GRUB Legacy or GRUB2 from an end user perspective. It's like battery acid: extremely useful for what it's designed to do, but you really want to minimize skin contact with it. What this means for UEFI is

Chris Murphy