sharing /boot among multible Linux distros

[Chris Murphy]

On Nov 26, 2013, at 10:17 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:

> On 11/27/2013 04:24 AM, Chris Murphy wrote:
>> 
>> On Nov 26, 2013, at 7:39 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>> 
>>> On 11/26/2013 11:56 PM, poma wrote:
>>>> On 26.11.2013 23:18, Michael Schwendt wrote:
>>>> 
>>>>> That's because your setup is wrong. If I were you, I would install a
>>>>> bootloader into the boot sector of each of your /boot partitions and
>>>>> chainload them from your MBR.
>>>> 
>>>> Are you kidding?
>>> 
>>> I guess, he isn't. It's what I recommend, too. It's the only way to make sure the different OSes/distros bootloaders do not interfere with each other.
>> 
>> Well it's not a good recommendation to do what is explicitly not recommended by GRUB devs.
> 
> Correct, they are warning about it, but this doesn't mean their recommendation is any good.

OK but are you saying you're willing to take responsibility for other people's systems whom you've recommended this method, over other methods, if they break? I wouldn't do that.

> To me, this is just one of those many grub2 usability regression.

Nothing stops you from using grub legacy, despite it not being maintained in ~6 years, or using extlinux.


> 
>> grub-install spits out a warning if you try to do this, by the way. It requires the user pass --force for it to work. And --force also isn't supported by anaconda for 4-5 Fedora releases now.
> Right. Why do you think people like me have been complaining about anaconda? Its usability has regressed.

It is not the responsibility of the anaconda team to support things that the developers of other tools themselves don't recommend.

> This is issue is one detail contributing to it.
> 
>> It can't be used if /boot is on XFS or LVM or md RAID, all of which lack boot loader padding areas, so fewer configurations are supported.
> Well, I am using one dedicated boot partition for each Linux distro and a common /boot and so far haven't had any problems.

Right, so if you don't like GRUB2 anyway, isn't recommended for your use case, and you're using /boot on ext4, why not use extlinux which is designed for the use case you want? Why persist using something and then complaining about it?


> 
>> The earlier suggestion to have the primary grub.cfg include an entry using configfile to point to each distribution's grub.cfg is the better way to handle this.
> From my experience, this a way which is guaranteed to kill your system in longer terms, because different distros' grub configs are too different.

If, like anything else, you keep grub2 up to date, including periodic replacement of its core.img, configfile supports all grub2 configuration files, and legacyconfigfile even supports grub "legacy" configuration files. The issue arrises when using old old old versions of grub2. There are some distros that still use ancient grub 1.98 versions. Those are fine for their grub.cfg to continue to be updated by the distro kernel updater, but it's better for the newest grub to be the one actually installed as the bootloader (the creator of boot.img and core.img).


> 
>> Each distribution updates only their own grub.cfg. And as far as I'm aware, no distribution ever re-runs grub-install,
> Distro upgrades and rescuing installations may do so.

Again, I'm not aware of any distro that runs grub-install after the initial installation. It actually would be a good idea for this to happen periodically, though. As merely updates to the grub2 package does not cause the modules themselves to be updated, or core.img recreated from those updated modules.

Nevertheless, nothing from distro A should touch the grub.cfg for distro B. And if you use /etc/grub.d/40_custom, which should not be stepped on in an update, then the user should be assured their use of configfile or legacyconfigfile or multiboot can continue to point to the grub.cfg of other distros.

But the idea of using one grub to chainload another grub in a VBR just to read a configuration file is what's fragile and prone to breakage. All kinds of forums are full of this sort of problem.


Chris Murphy