From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
Description of problem:
During install I chose lilo instead of grub. The machine booted ok the first
time. I downloaded the kernel upgrades and installed them with rpm -Fvh. While
this happened I got grubby errors. Apparently the rpm upgrade scripts assumed
everyone was using grub. Anyway I went to run lilo afterwards and discovered
that lilo.conf didn't have any image entries. I rebooted anyway and the old
kernel somehow loaded, but I got errors because the modules directory wasn't
there anymore. So I manually edited lilo.conf and rebooted, but even though the
kernel image successfully loaded it didn't like my root=/dev/sda3 (boot was
sda1). The kernel would panic with "can't mount root partition, pass in root=
to kernel" (or something like that) but wouldn't tell me what the bad paramater was.
Also the rescue disk was little help. It let me in to run lilo, but it didn't
include a tool itself to install a boot loader. I had to wipe the install and
start over again (this time I installed grub)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install rh 8.0 and select lilo
2. upgrade the kernel rpms
The instructions for upgrading a kernel say you should use the rpm options
'ivh', not 'Fvh', which removes the old kernel. If you use up2date to update
your kernel this will be taken care of properly.
I don't understand why you think that lilo was not set up properly during the
install, since you were able to boot it ok?
I don't think lilo was set up properly because there were no image entries in
/etc/lilo.conf. I surmise that the installer had created a lilo.conf in ramdisk
and used that to install lilo. At the time I thought that lilo had magically
changed in between versions and didn't need image entries anymore, so I rebooted
anyway. After I rebooted lilo found the old kernel image on the disk even though
it was removed from the filesystem (during bootup it only gave the options for
the up kernel, not the smp kernel), but the kernel couldn't find its modules
directory so had problems during boot like not loading the ethernet drivers.
I had always used -Fvh because upgrading other rpms with -i never worked (I
never read the kernel upgrade guide until now). I upgarded a 7.2 system with
-Fvh and it work properly. Then rpm ran lilo after the upgraded (but it didn't
update lilo.conf, so I had to run lilo myself afterwards anyway). The 8.0 rpms
apparently assume everyone is running grub.
And the reason I didn't use up2date to upgrade the kernel was that
a) The default config specifically does't upgrade the kernel, and I assumed
there was some reason for that
b) The non-x interface for up2date is hard to use
So I guess there is more than problem here. The problem of lilo.conf not being
created properly during install, the problem of the kernel not liking
root=/dev/sda3 for some reason, the kernel not giving a good error message, bug
77030, and that the upgrade scripts for the updated kernel rpm assume everyone
is running grub. If I used up2date I assume the same rpm script would have run.
Thank you for the explanation - I will assign this to an engineer.
What errors did you get from grubby? It should properly support lilo now as
well so everything should have just worked properly. Also, could you attach a
copy of your /etc/lilo.conf?
The lilo.conf got blown away when I installed the system the second time. Now I
have no lilo.conf but a lilo.conf.anaconda:
Maybe I should have had root=LABEL=/ where before I had root=/dev/sda3? What
does root=LABEL=/ mean anyway? Anyway this file isn't the one that gave me the
Should be fixed as of yesterday afternoon in mkinitrd-3.4.30-1 or newer (coming
to a rawhide near you :)
what exactly did you change?
Time tracking values updated
I'm going through Bugzilla closing some bugs that have been marked as Modified
for some period of time. I believe that most of these issues have been fixed,
so I'm resolving these bugs as Rawhide. If the bug you are seeing still exists,
please reopen this report and mark it as Reopened.
Well I'm certainly not going to try to reproduce this.