Best practice for multiple version/OS boot?
rc040203 at freenet.de
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.
>> https://bugzilla.redhat.com/show_bug.cgi?id=872826 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
>> 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
> 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.
> 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