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

[Stuart]

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'