[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [help-a-newb] setting grub



(Not sure what I can trim, yet.)

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:
>>> On 19/03/11 13:29, Joel Rees wrote:
>>>>
>>>> I'm having the devil of a time trying to figure out how to set the
>>>> default boot and how to chain in grub 2 in squeeze.
>>>>
>>>> I found something about using update grub and setting the default boot
>>>> in a fle in /usr/share/grub, followed by doing an update-grub, but
>>>> that doesn't change the default boot,
>>>
>>> You can change the default in file /etc/default/grub. Edit the
>>> GRUB_DEFAULT= line to the entry number you want (starting with 0 for the
>>> first entry in the grub menu.
>>>
>>> Then run update-grub.
>
>
>
>> I think I got stuck for a while on update-grub being in /usr/sbin. Or
>> was it grub-update ?
>
> It's "/usr/sbin/update-grub".

True.

>>> 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.

>> 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.

Of course, I can mess with the BIOS drive order or the marked boot
partition, but I have reasons for not wanting to do that which aren't
relevant here.

> 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.

--
Joel Rees


Reply to: