| 1 |
On Thu, 27 Aug 2015, Neil Bothwick wrote: |
| 2 |
|
| 3 |
> On Thu, 27 Aug 2015 14:19:29 +0000 (UTC), Grant Edwards wrote: |
| 4 |
> |
| 5 |
> > For those of us with multiple Linux installations on a disk, that's a |
| 6 |
> > pretty big reason to stick with grub-legacy. |
| 7 |
> |
| 8 |
> Actually, that's a good scenario for GRUB2. grub2-mkconfig can detect |
| 9 |
> all Linux installations on a system, not just the running one, so you |
| 10 |
> only need one GRUB to boot everything. That's why distro installers are |
| 11 |
> so much better at setting up Linux dual booting these days, because GRUB2 |
| 12 |
> makes it simple for them. |
| 13 |
> |
| 14 |
|
| 15 |
It's true that grub2-mkconfig does Linux detection well but the problem |
| 16 |
with one grub and multiple distros is the need to manually regenerate the |
| 17 |
config. |
| 18 |
|
| 19 |
I give you the following scenario: |
| 20 |
Gentoo + another binary distro (say Fedora). Whichever one manages the |
| 21 |
grub config can regenerate it on updates. On gentoo you'd do that manually |
| 22 |
(post-install hooks?), Fedora would run grub2-mkconfig on kernel updates. |
| 23 |
But what happens when the other one (not responsible for the config) |
| 24 |
updates in a way that affects booting...? |
| 25 |
|
| 26 |
You end up with an inconsistant config. To regenerate you need to boot |
| 27 |
into the config-managing-distro or atleast chroot. But the worst thing is |
| 28 |
you have to review all updates to find out if the config needs changing. |
| 29 |
|
| 30 |
I much prefer chainloading and giving each distro free reign over their |
| 31 |
own boot loader. That way they can pretend they're the boss and work the |
| 32 |
way they were intended to and I can supervise things from gentoo. |
Archives