Grub question (Ahem....help! Now it just says 'GRUB')

[Otto Haliburton]

> -----Original Message-----
> From: redhat-install-list-bounces at redhat.com [mailto:redhat-install-list-
> bounces at redhat.com] On Behalf Of Stuart
> Sent: Thursday, September 30, 2004 12:31 PM
> To: Getting started with Red Hat Linux
> Subject: Re: Grub question (Ahem....help! Now it just says 'GRUB')
> 
> Rick Stevens wrote (even if I am not really replying to him as such):
> >> I'm unclear whether you think this would have helped my problem. I
> >> think not. Using Stuart's info he said grb had two parts. In my case
> >> grub said 'GRUB' but didn't say 'GRUB second phase loader' or whatever
> >> that language is. I assume grub cannot find fstab on it's own,
> >> correct?
> Grub never looks for /etc/fstab - it is only concerned with firing up
> the kernel and telling where its root filesystem lives.
> The rest of your boot process is taken over by the init scripts in
> /etc/rc.d/
> 
> my understanding of your setup is this:
> MBR of entire disk: third party bootloader
> first sector of /boot: grub stage 1
> in the /boot filesystem: grub stage 2 and its config files.
> 
> the fact that you got GRUB on the screen in the forst place suggests
> that the first stage is/was fine, or it would never have run at all.
> The reason (as I see it) that you didn't get your bootloader menu is
> that grub stage 1 could not locate and execute grub stage 2, which it
> looks for by sector. This stands to reason if you moved your partitions
> about, even if they didn't change their identifiers - the second stage
> binary will have been moved when you moved the filesystem it sat in.
> 
> when it just said GRUB, did you have anything else on screen?
> if not, then it was the first stage only.
> if you had a grub console prompt then it had loaded the 2nd stage but
> couldn't find grub.conf
> 
> > Correct.  /etc/fstab is used by the "mount -a" command in the startup
> > scripts.  The MBR part of grub (first stage) needs to know where the
> > second stage is located.  That's what the "root=" thing is for in
> > grub.conf--it tells grub where /boot is (and hence, where the second
> > stage loader and the grub config file are).
> Actually the root= bit is a kernel argument. Unless you meant line 2
> below: (in which case sorry for correcting you :-) )
> Standard RH entries in grub look like this (with explanatory notes...)
> 1. title <whatever>
> 2. root (hd0,0)
> where is your /boot FS? It just means ' the files on the following two
> lines are on this filesystem'. Saves typing (hd0,0) or similar on every
> line... (hd0,0) == /dev/hda1 in normal linux speak
> 3  kernel /vmlinuz-2.4.21-4.EL ro root=LABEL=/
> which kernel (relative to (hd0,0) should grub load?
> the root= bit tells the kernel where its root (/) filesystem is. It
> needs this info so it can locate and run /sbin/init (first process on
> your system)
> 4. initrd /initrd-2.4.21-4.EL.img
> which initial ramdisk should the kernel unload and use for loading
> boot-critical modules/device drivers?
> >
> >> Labels are sort of nice for my 1394 drives when I need to hook up
> >> multiple drives and keep them straight, but actually I don't use them
> >> for my systems.
> This is also the only place I use these myself. Messing up the LABEL
> bits either in grub.conf or /etc/fstab causes boot issues
> a) when the kernel tries to run /sbin/init ( the infamous 'Kernel panic
> no init found' boot error and
> b) when /etc/rc.d/rc.sysinit tries to check and mount all the
> filesystems it sees in /etc/fstab. This has a number of issues - mainly
> caused by duplicate or missing labels. It usually results in the rather
> unwelcome sulogin prompt 'give root password for maintenance...'
> 
> >
> >
> > Yes, that can be helpful.  The main problem with labels is when people
> > try to have multiple versions of Linux installed on the hard drives.
> > You know, multiple partitions labeled "/usr" or "/".  Which one gets
> > used when is indeterminate.
> usually (IIRC) rc.sysinit just fails if it finds duplicate labels
> 
> Kind Regards
> 
> Stuart
> 
> --
> Stuart Sears RHCE RHCX
> '2 + 2 = 5 for sufficiently large values of 2'
> 
we have all made little mistakes about GRUB and that is probably because it
has changed even the original author's code is being maintained and updated
by someone else.  First mistake, there can be and in most cases there are
three stages stage1, stage2, stage1.5. Stage 1 main purpose is to do some
bios checks, geometry and other things, but it's main purpose is to load
stage 1.5 or stage 2, it is exactly 512 bytes long and it is the routine
that is printing "GRUB".  It contains the block sector of stage 2 or stage
1.5.  It is dumb.  Now my mistake, stage 1.5 can be stored right behind the
MBR not stage 2.  It's main purpose is to load stage 2.  It does know one
file system and only one. It purpose is to load stage 2 from the file system
it knows. It prints its errors in numbers corresponding to stage 2 no error
messages. Stage 2 purpose in life is finish loading itself and then it has
two methods of booting.  1. it loads the kernel directly or 2. it chain
loads another boot loader .... Now in the case under discussion, after
looking at the error messages there is error message if the partition is
screwed or incorrect.  There is no error message for a missing grub.conf so
in this case I don't know what happened cause the error message was not
printed, so while mistakes were made the final analysis that grub-install
should be ran is the correct solution.