Hi Folks,

I get this message from the Red Hat Network Alert notification tool:

"Your system is current running kernal-2.6.9-1.681_FC3, but the newest installed kernal is kernal-2.6.10-1.766_FC3. It is recommended you reboot at the first opportunity...."

Rebooting has no effect on this state of things. During boot up, if I ask for the list of kernals to boot to, version 2.6.10-1.766 isn't in the list (although rpm shows it as installed). Huh? Odd. But at least that explains why I can reboot and not get the latest kernal, right?

So, I go looking for grub.conf which is presumably in /boot/grub, right? Nothing there. In /etc, there's a broken link to grub.conf and to grub.conf.rpmsave.

So ok, I've apparently lost some files somehow (perhaps during an update that stalled on me last week), but if that's the case, how come grub still works at all (let alone gives me a choice between versions 2.6.9-1.667 & 2.6.9-1.681_FC3)?

Can anyone tell me what the next step is to get back to a proper state? I'm assuming I need to recreate the grub.conf file or something of the like....

Thanks!

John

If this is the case then you must have a grub.conf somewhere. If grub cannot find a conf file then it will drop you to a grub command line. Looks like this:

grub>

So if you are not seeing this you do have a conf file, just a matter of finding it. Note that grub.conf is usually called menu.lst. Grub.conf is usually a symlink to menu.lst.

In any event, update your locate db: "updatedb" and run 'locate grub.conf' and 'locate menu.lst'

Another thought: Some distro's don't mount the /boot partition automatically. Make sure /boot is mounted when looking for grub conf.

1. What is in your /boot directory?
2. What is in your /boot/grub directory?
3. What is in your /etc/fstab?
4. What does "rpm -V grub" say?

Here's the results of the locate commands suggested:

# locate menu.lst
/usr/share/doc/grub-0.95/menu.lst
# locate grub.conf
/etc/grub.conf.rpmsave
/etc/grub.conf

The /usr/share/doc/grub-0.95/menu.lst is just a sample file that doesn't seem to bear any relation to what's shown as options during bootup. But here's the Linux part:

# For booting GNU/Linux
title GNU/Linux
root (hd1,0)
kernel /vmlinuz root=/dev/hdb1

The /etc/grub* files are symbolic links that are reported as broken by Nautilus. Here's what the shell has to say about them (they show up in red; presumably indicating the broken nature of the links):

# ls -l /etc/grub*
lrwxrwxrwx 1 root root 22 Nov 22 11:18 /etc/grub.conf -> ../boot/grub/grub.conf
lrwxrwxrwx 1 root root 22 Nov 21 23:48 /etc/grub.conf.rpmsave -> ../boot/grub/grub.conf
#


Here's what's in the /boot directory:

# ls -l /boot
total 8148
-rw-r--r-- 1 root root 53807 Jan 13 14:48 config-2.6.10-1.741_FC3
-rw-r--r-- 1 root root 54497 Feb 9 21:17 config-2.6.10-1.766_FC3
-rw-r--r-- 1 root root 51431 Jan 2 13:52 config-2.6.9-1.724_FC3
drwxr-xr-x 2 root root 4096 Nov 25 10:32 grub
-rw-r--r-- 1 root root 531697 Jan 19 07:31 initrd-2.6.10-1.741_FC3.img
-rw-r--r-- 1 root root 533130 Feb 21 14:12 initrd-2.6.10-1.766_FC3.img
-rw-r--r-- 1 root root 530513 Jan 8 09:33 initrd-2.6.9-1.724_FC3.img
-rw-r--r-- 1 root root 728476 Jan 13 14:48 System.map-2.6.10-1.741_FC3
-rw-r--r-- 1 root root 733387 Feb 9 21:17 System.map-2.6.10-1.766_FC3
-rw-r--r-- 1 root root 714267 Jan 2 13:52 System.map-2.6.9-1.724_FC3
-rw-r--r-- 1 root root 1439626 Jan 13 14:48 vmlinuz-2.6.10-1.741_FC3
-rw-r--r-- 1 root root 1463004 Feb 9 21:17 vmlinuz-2.6.10-1.766_FC3
-rw-r--r-- 1 root root 1422969 Jan 2 13:52 vmlinuz-2.6.9-1.724_FC3
#

And /boot/grub:

# ls -l /boot/grub
total 8
-rw-r--r-- 1 root root 3194 Oct 26 15:52 splash.xpm.gz
#

(Apparently just a compressed graphic....)

# cat /etc/fstab
# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=/ / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
LABEL=/opt /opt ext3 defaults 1 2
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
LABEL=/var /var ext3 defaults 1 2
/dev/sda2 swap swap defaults 0 0
/dev/hdd /media/zip vfat pamconsole,rw,exec,user,noauto 0 0
/dev/hdd4 /media/zip1 auto pamconsole,exec,noauto,managed 0 0
/dev/hdb /media/cdrom auto pamconsole,exec,noauto,managed 0 0
#

#rpm -V grub
#

(That is, nothing....)

# rpm -q grub
grub-0.95-3
#

Anything there indicative of anything? Thanks for your time, folks!

John

I don't see /boot in the list of mounted devices, but I don't know what that means....

# mount -l
/dev/hda2 on / type ext3 (rw) [/]
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbfs on /proc/bus/usb type usbfs (rw)
none on /dev/shm type tmpfs (rw)
/dev/sda1 on /opt type ext3 (rw) [/opt]
/dev/sdb1 on /var type ext3 (rw) [/var]
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
/dev/hdd on /media/zip type vfat (rw,noexec,nosuid,nodev)
#

Okay, that doesn't look right. Your /boot/grub looks as if you've never had GRUB installed before. Have you had a separate /boot partition before?

Create this files as /boot/grub/grub.conf, then run grub-install /dev/hda as superuser to install GRUB into Master Boot Record:

OK, I think this is a critical fact (that I should have gotten at earlier): there is apparently a separate boot partition. The hardward browser shows a little partition called /dev/hda1; when I mount that as /boot, the "missing" grub.conf appears and contains info that's consistent with what I see during bootup:
OK, so now I think I see what's happening (newbie blindness is my only excuse! I should have recognized that as the case right off the bat, I guess...):

1. There is a separate /boot partition (I don't know what the relative merits of this approach are, but it's clearly there).
2. In the bootup process, this partition is either never being mounted (or it's being mounted and then unmounted; perhaps as part of the different boot levels?). It's not in /etc/fstab for whatever that's worth.
3. Since there is a /boot directory sitting out there on / (to accept the mount of the /dev/hda1 partition), the up2date utility is "installing" stuff into that directory on / and it's not being seen during the actual bootup (which is looking at the boot partition).

So, patient folks, some questions:

1. Is the separate boot partition worth the hassle?
2. If I should just keep the separate boot partition, should it be mounted during normal operation or should I just mount it before attempting to update the Fedora install (so that kernal updates can be applied somewhere useful)?
3. The boot partition is small, how careful do I need to be that it doesn't fill up? What precautions do you suggest?

Thanks!

John

Yeah, it must be mounted of course, so package installation can write to it. If it is labelled "/boot" (run e2label /dev/hda1 to find out), you can use this:

Else, assign a different label or mount as /dev/hda1 instead of LABEL=...

Whether you need a separate boot partitions depends on how you use it (you can share a common /boot with other installations, for instance) or whether your hardware and BIOS requires the boot partition to be below the 1024 cylinders mark (a requirement for old or exotic hardware).

The idea behind not mounting a boot partition is that you shouldn't need to access any files there in normal operation. If the partition is not mounted, then there is little chance of corruption of any of your kernels etc. Grub can read the partition at boot time without it actually being mounted, in order to boot your kernel (and find the grub stage files that it needs).

You just need to remember to mount it when you rebuild a kernel...if this is too much of a PITA then just add it to fstab and it will be mounted every boot. The choice is your's...

Lots of sensible things.
I like to run without boot mounted, but I compile a lot of kernels (Gentoo), and have learned to mount it in need.
grub finds what it needs via the root directive you give it - or in the case of splash, the explicit pathing (hint: that's always a good place to start a search).

As for size, I have 50Meg for /boot - plenty for half a dozen kernels.

After-thought Well that hint doesn't make a lot of sense if you didn't expilictly do the grub install, and hence don't know what the root directive was for that install - sorry about that.

In that case, mount it read-only, so you don't forget about it.