Re: [help-a-newb] setting grub
On Thu, Apr 7, 2011 at 3:02 AM, Joel Rees <joel.rees@gmail.com> wrote:
> On Thu, Apr 7, 2011 at 12:32 AM, Tom H <tomh0665@gmail.com> wrote:
>> On Wed, Apr 6, 2011 at 10:56 AM, Joel Rees <joel.rees@gmail.com> wrote:
>>> On Sun, Mar 20, 2011 at 12:09 AM, Dom <toyer@rpdom.net> wrote:
>>>> I don't use chain loading, so am not sure how to do that. I think grub2
>>>> should automatically detect other OSen, is os-prober is installed, when
>>>> update-grub is run. I'm sure someone else here can advise you.
>>>
>>> Well, apparently, it doesn't find the other OSses until you do the
>>> /usr/sbin/grub-update . That's one problem. The other problem is that
>>> I don't want Debian to be the default right now. Maybe later.
>>
>> Because update-grub runs "/etc/grub.d/30_os-prober" which runs os-prober.
>
> Which detects my kernels and tries to list out direct jumps to them in the menu.
>
> Which is not what I want at all. It makes the jump to the Fedora 13
> kernel okay, but dies on the Fedora 15(alpha) kernel. I'm not sure
> whether that's grub2's fault or F15(alpha)'s fault, but if it were
> chaining I'd be a lot more sure, and I'd have a chance to muck with
> the grub that Fedora installs.
F15's failure may or may not be grub's fault... F15's in alpha mode so
it's most probably F15 but we can't tell from your posts.
If you don't want os-prober to add your Fedora entries to grub.cfg,
set "GRUB_DISABLE_OS_PROBER=true" in "/etc/default/grub" and run
update-grub.
>>> 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.
>>>
>>> With chainloading each system can maintain its own grub, and Debian's
>>> kernel install scripts don't need to know for Fedora's kernels.
>>>
>>> That doesn't completely solve things. That is, if Debian ever thinks
>>> it has to make a third entry, and the third entry was the default,
>>> what was default is no longer.
>>
>> grub1's update-grub had the same fragile linkage - although I vaguely
>> remember an option to update the default entry but I could be
>> imagining things/thinking of something else.
>>
>> I can think of two options (short of switching to LILO as has been
>> suggested in the past here).
>>
>> 1. Set "GRUB_DEFAULT=saved" in "/etc/default/grub" and run
>> "grub-set-default <n>"; update-grub". You will then always boot by
>> default with the last kernel with which you booted.
>>
>> It isn't really what you're looking for but it could be good enough.
>
> Well, I have another example of why this would be problematic. There
> is a BFO boot option I'm playing with, and with the BFO pseudo-kernel
> in there, Debian's grub2 puts it before the real kernels. Which would
> have me defaulting to trying to install a new OS evertime I boot up,
> until I go change it by hand. And, then, when I get tired of the state
> of the BFO gadgetry at this point, I delete it from the Fedora /boot
> directory and Debian's grub2 defaults me to an old kernel.
You'd have to run "grub-set-default <n>"; update-grub" after every
time that you add/remove BFO.
>> 2. Set "GRUB_DEFAULT=0" in "/etc/default/grub", create
>> "/etc/grub.d/09_first-kernel", and run update-grub, where:
>>
>> $ cat /boot/grub.d/09_first-kernel
>> #!/bin/sh
>> cat << EOF
>> menuentry "first kernel" {
>> set and insmod prelims
>> set root=...
>> search ...
>> linux ...
>> initrd ...
>> }
>> EOF
>>
>> But you'll have to maintain this file manually.
>
> Manual is no problem here, because it would chain, and Fedora talks
> care of its own grub.
>
> That's the whole point of chaining. Debian doesn't have to know how to
> sift through Fedora or openBSD or openSolaris partitions or whatever.
> Just chain to whatever boot loader is stored in the base partition
> specified.
>
> Anyway, I have been playing with that. I found an example or two for
> chaining to MSWindows which looked possible, but don't seem to work.
>
> I found a tutorial at
> <http://www.dedoimedo.com/computers/grub-2.html>
>
> and something of a manual at
>
> <http://www.gnu.org/software/grub/manual/html_node/index.html#Top>
>
> I had to edit /boot/grub/device.map and add the entry from
> /dev/disk/by-id for the third drive since I added the drive after
> installing Debian, although that may have been a mistake.
>
> I've made several stabs at this, but the present one ("09_fedora",
> with the execution bit properly set) looks like this:
>
> ----------------------------
> #! /bin/sh -e
> echo "adding chain to hd(1,1) and hd(2,1)"
>
> cat << ENDOFOTHERS
> menuentry "Fedora on /dev/sda1" {
> insmod part_msdos
> insmod ext2
> insmod chain
> set root='(hd1,msdos1)'
> chainloader (hd1,msdos1)+1
> }
>
> menuentry "Fedora on /dev/sdf1" {
> insmod part_msdos
> insmod ext2
> insmod chain
> set root='(hd2,msdos1)'
> chainloader (hd2,msdos1)+1
> }
> ENDOFOTHERS
> --------------------------------------
>
> After doing update-grub and re-booting, grub now shows me the menu
> entries. When I let it take the first, it clears the grub splash
> screen, gives me a dash at the top left of the screen and sits there
> forever. When I select the second, it fails to even clear the splash
> screen.
>
> I've tried combinations of
>
> set root='(hd1)'
>
> and
>
> chainloader (hd1)
>
> and in the latter case, I get, for the first one,
>
> Grub loading stage 1.5
>
> and then it sits there forever. For the second entry, still nothing.
>
> Getting a grub command menu, I tried looking at the partition types,
> and everything comes back none for the device (hd0) and MSDOS for the
> bios-level partitions (hd0,1), except for (hd2,1), where grub just
> goes away and quits responding. (Grub has a habit of going away
> anytime I ask it for help.)
>
> I'm going to try removing device.map and re-installing grub, to see if
> it recognizes the third drive better that way.
>
> If that fails, I suppose I'll have to re-install Debian someplace
> where grub2 will stay out of my way. I can't afford to waste more time
> on this puzzle.
>
> If it works, I'll probably rename 30_os-prober to 08_os-prober and
> clear the execute bit on 09_fedora so the other OSses come first and
> leave it that way for a while.
The grub2 developers decided that most people wouldn't want to set up
chainloads and would want update-grub to add all the available
installs to grub.cfg to be directly bootable. There's possibly a case
to add an option to "/etc/default/grub" to choose to have other
detected OSs with chainloads...
You can update "/boot/grub/device.map" with grub-mkdevicemap.
Check that you've used the correct (hdX,msdosY) for Fedora with
grub-probe and possibly use a "search ..." line after the "set
root..." line (or just use a "search ..." line).
Renaming 30_os-prober's a good solution too, although it doesn't solve
the BFO problem without some intervention form your side but nothing
else does.
Reply to: