Best practice for multiple version/OS boot?

Ralf Corsepius rc040203 at
Mon Nov 25 07:53:20 UTC 2013

On 11/25/2013 07:58 AM, Adam Williamson wrote:
> On Mon, 2013-11-25 at 06:33 +0000, Tim Landscheidt wrote:
>> More contested seems to be the multi-boot setup.
>> has a
>> myriad of opinions on how it should be set up;
>> suggests "chainloader", and
>> recommends "configfile".  Of course there is also GRUB's OS
>> prober.
>> So what are Fedora developers /actually/ using?

Depends on what you want to test. To check for packaging issues I am 
just using mock. In cases I really want to/need to test a package, I am 
using a chainloaded multiboot configuration on an eldery/"written-off" 
machine ("a dedicated testing machine").

 > Creating a
> I have noticed a fairly strong correlation here: the more you know about
> how booting works, the more strongly you are inclined to avoid multiboot
> as far as possible...
> There really aren't any perfect options. The upstream advice of using
> 'configfile' as a sort of chainload-lite is probably the best approach
> for grub2-booted OSes, overall. jlaska's page is outdated; upstream
> grub2 explicitly discourages doing full chainloading. I'll slap a 'this
> is obsolete' header on that page, I don't think James would mind. You'll
> note, though, that the _design_ of both approaches is fairly similar:
> have a 'master bootloader' not owned by any OS, let each OS own its own
> boot configuration, and have the master bootloader read each OS's own
> bootloader configuration when booting that OS. It's just that the old
> 'chainloading' method actually loaded each OS's bootloader, while the
> 'configfile' method has the master bootloader read in the config files
> from the slaves rather than loading a whole bootloader that they
> control.
> Personally, I use VMs.
>> separate GRUB partition and "chainloader"/"configfile"?
That's what I am using. However, Fedora's installer and grub2 can make 
this a challenge (It once was easy, but these days it's </self censored>.

>> Running OS prober in the "main" OS after each installation/
>> kernel update?  Something else?  How often do the setups al-
>> low one to shoot oneself in the foot, or are they (more or
>> less) "foolproof"?
> No, none of them are foolproof. I'd expect either the configfile or 'let
> one OS be in charge and run mkconfig from that OS every time you update
> any other OS' approach would mostly work most of the time.
I can imagine the works to some extend within the Red Hat family of 
Linuxes, but is almost non-workable when installing several different 
Linux distros or different OSes in parallel.

> The
> configfile approach is less of a pain and, because it involves less
> manual work, less subject to snafus. If I really had to multiboot, I'd
> probably go with the configfile approach.

The only approach I found working fairly reliable is using a 
traditional, strictly separated, cascade of bootloaders with strictly 
separated physical partitions.


More information about the devel mailing list