Red Hat Bugzilla – Bug 77020
lilo not set up properly during install, kernel upgrade makes machine unbootable
Last modified: 2007-04-18 12:48:03 EDT
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): How reproducible: Didn't try Steps to Reproduce: 1. Install rh 8.0 and select lilo 2. upgrade the kernel rpms 3. reboot Additional info:
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: prompt timeout=50 default=linux boot=/dev/sda map=/boot/map install=/boot/boot.b message=/boot/message linear image=/boot/vmlinuz-2.4.18-14smp label=linux initrd=/boot/initrd-2.4.18-14smp.img read-only append="root=LABEL=/" image=/boot/vmlinuz-2.4.18-14 label=linux-up initrd=/boot/initrd-2.4.18-14.img read-only append="root=LABEL=/" 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 problem.
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.