The latest kernel errata update fails to detect my bootloader:
I will do the following:
[install: kernel-smp 2.4.22-1.2166.nptl.i686]
Is this ok [y/N]: y
kernel-smp-2.4.22-1.2166. 100% |=========================| 13 MB 00:16
Running test transaction:
Test transaction complete, Success!
kernel-smp 100 % done 1/1
Kernel Updated/Installed, checking for bootloader
No bootloader found, Cannot configure kernel, continuing.
Installed: kernel-smp 2.4.22-1.2166.nptl.i686
I'm using grub, and it did update grub.conf (though it left the old
kernel as the default), so I'm not sure where / why I'm getting the
[root@spamstop root]# cat /boot/grub/grub.conf
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/hda3
# initrd /initrd-version.img
title Fedora Core (2.4.22-1.2166.nptlsmp)
kernel /vmlinuz-2.4.22-1.2166.nptlsmp ro root=LABEL=/
title Fedora Core (2.4.22-1.2149.nptlsmp)
kernel /vmlinuz-2.4.22-1.2149.nptlsmp ro root=LABEL=/
This is yum, not mkinitrd (new-kernel-pkg leaves the old kernel as the
default and then yum tries to switch it). What do you get if you
[root@spamstop root]# python /usr/share/yum/checkbootloader.pyc
Unable to determine boot loader.
I might be mistaken (too many machines, not enough brain cells), but I
don't remember this happening when yum updating from 2115 to 2149....
I just glanced through checkbootloader.py. If I uncomment the print
statement in the "for dev in bootdevs" loop, I get:
[root@spamstop yum-2.0.4]# python checkbootloader.py
Unable to determine boot loader.
This system is SCSI (hardware RAID):
[root@spamstop yum-2.0.4]# mount | grep ^/
/dev/sda3 on / type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
/dev/sdb1 on /var/spool type ext3 (rw)
NEEDINFO while awaiting patch from upstream (and so I don't
have to stare at this bug).
Was the yum update to 2.0.5 done in March supposed to fix this? It
didn't, since I still saw the problem when yum put the new 2188 errata
kernel on the system....
can you post your /etc/grub.conf here?
your /etc/grub.conf has tha
the checkbootloader code still looks and uses that to search for
change that from /dev/hda to /dev/sda and see if everything magically
also - I know it's commented out - it doesn't matter.
You should be seeing this behavior from up2date too - it uses the same
code for the bootloader detection.
Changing it from hda to sda appears to make it work:
[root@spamstop grub]# python /usr/share/yum/checkbootloader.pyc
There's no good reason for anaconda to have ever gotten hda in there
in the first place -- that system has always been SCSI, and it was a
fresh install of Fedora Core 1....
you didn't accidentally copy a grub.conf over from somewhere else or
cut and paste a little liberally, did you?
Not that I recall, and the only note in the log book was that default
was fixed manually after updates (and now that the comment was changed
from hda to sda)....
If there haven't been any other reports of anaconda generating hda
instead of sda, though, you should probably chalk it up to me doing it
and having forgotten it -- that machine is a bog-standard dell
poweredge 1750, so it's not like it's an unusual configuration
ok, I'm going to close this one as notabug, for now, unless jeremy
I'd really prefer it if red hat's bugzilla had a:
Close -> Weird.