Re: [help-a-newb] setting grub
On Fri, Apr 8, 2011 at 3:47 AM, Andrei Popescu <andreimpopescu@gmail.com> wrote:
> On Mi, 06 apr 11, 23:56:56, Joel Rees wrote:
>>
>> Another problem is the fragile linkage. If Debian ends up with more
>> than two entries there, or if, for some reason I delete the rescue
>> mode entry, having the third entry as the default suddenly is not what
>> I want. Maybe that won't happen with Fedora 13's most recent kernel as
>> the default, but it definitely is more than possible if I try to
>> default to the Fedora 15 install.
>
> You can set GRUB_DEFAULT to the complete name of an entry, then you
> won't have to worry about reordering.
Well, I was thinking about that, but the names of the kernels change
whenever the kernel is upgraded. This is actually the biggest problem
with trying to have one boot manager to rule them all.
mv-ing 30_os-probe to 08_os-probe seems to work for getting Fedora to
the top. If I have to, I can probably work out how to have a probe for
each active OS install (gross!) and move the probe I want to be
default up front in the order.
Default menu item number 0 would be sufficient in my case (for now),
except that, any way around this, when Fedora updates its kernel, I
have to notice, and then I have to catch the re-boot, take it to
Debian, and run update-grub by hand before grub will see the new
kernel. (And then I can finally boot it to Fedora so Fedora can clean
up the update.)
It's difficult enough for a distro to fix up the name of the kernel in
its own boot manager. That's part of the reason some of the BSDs (at
least used to) put boot managers in their own BIOS level partition. (I
haven't checked that it's still the case in several years.)
With one boot manager to rule them all, that boot manager has to be an
OS, with programming languages, file systems (and foreign file
systems), and nearly fully-functioning drivers. It has to go digging
around in other OSses internals. That is complicated and fundamentally
unclean.
I suppose the grub engineers want to have the pseudo-grub in each OS
install go hunting for other /boot/grub directories in other OSses to
update or something. Or maybe put events in the (ever-burgeoning)
grubOS. (Grub is the new Xen?)
With chaining, each distro/OS updates it's own latest kernel in its
own boot manager, and the boot managers can be kept clean, simple, and
stable. Chaining is what makes that possible. And it doesn't really
incur any serious penalty, another 5 second (adjustable) timeout is
all, and that 5 second timeout tends to operate in parallel with
things, so that it effectively adds only a second or two. That should
be understood as part of the cost of multi-booting.
For now, I've used Fedora's grubby to remove the bfo, and I've done
update-grub in the Debian install, and, until I am ready to move
Debian to a more permanent place, I'll just have to remember the
update-grub step. Debian will probably end up replacing the Fedora 13
install when F15 becomes a release.
I'll have to try to get time to get on the grub developers' mailing
list and see if I can sweet-talk them into getting insmod chain
working for chaining to legacy grubs or something. Or at least ask
them if I'm missing something.
Joel Rees
Reply to: