From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Description of problem:
When a "make install" is done to install a new kernel, the make install
looks for and runs lilo.
lilo overlays grub in the boot sector. This can result in an unbootable
Of course, lilo has to be on the system. This affects any systems with
both lilo and grub installed, especially any systems which had
lilo installed and are upgraded.
Steps to Reproduce:
Actual Results: lilo was installed into the MBR, overlaying grub.
./arch/i386/boot/install.sh runs either /sbin/lilo or
/etc/lilo/install, depending on which is available.
Expected Results: ./arch/i386/boot/install.sh looks for a file called
/sbin/installkernel which will be run to install the kernel
in the make install instead of the default actions.
RedHat's istallation of Grub should include a /sbin/installkernel that
does everything that ./arch/i386/boot/install.sh does except
for running lilo. Optionally, it should insure that the just
installed kernel is mentioned somewhere in /boot/grub/grub.conf.
# This file is subject to the terms and conditions of the GNU General
# License. See the file "COPYING" in the main directory of this archive
# for more details.
# Copyright (C) 1995 by Linus Torvalds
# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
# "make install" script for i386 architecture
# $1 - kernel version
# $2 - kernel image file
# $3 - kernel map file
# $4 - default install path (blank if root directory)
# User may have a custom install script
if [ -x ~/bin/installkernel ]; then exec ~/bin/installkernel "$@"; fi
if [ -x /sbin/installkernel ]; then exec /sbin/installkernel "$@"; fi
# Default install - same as make zlilo
if [ -f $4/vmlinuz ]; then
mv $4/vmlinuz $4/vmlinuz.old
if [ -f $4/System.map ]; then
mv $4/System.map $4/System.old
cat $2 > $4/vmlinuz
cp $3 $4/System.map
if [ -x /sbin/lilo ]; then /sbin/lilo; else /etc/lilo/install; fi
This has made the beta mailing list a couple of times.
We (Red Hat) really need to fix this defect before next release.
/sbin/installkernel is in the kernel package...
Arjan, have we come to any sort of resolution on what's being done with this?
It's being worked on. Unfortionatly the script HAS to move to another RPM to
make touching (and hence fixing) this script even remotely possible.
(some very deep rpm voodoo is involved)
*** Bug 52039 has been marked as a duplicate of this bug. ***
fixed in mkinitrd-3.2.1-1.
(as in, the file is moved. We really can't do anything with the contents until
the next release.)
I used to work for IBM. We came up with all sorts of reasons why we could not
fix bugs. Fixing this bug requires deleting or commenting one line in a shell
Would someone mind writing me an e-mail about why you can't comment one line in
a shell script until the next release?
If you can't actually support grub, maybe it is a bad idea to try to shift to
it on this point release?
The file is owned by every single kernel package ever installed.
CHanging it creates file conflicts between the old kernel packages and the new RPMs.
And as for why this is bad -- this then breaks the ability to install a new
kernel package while leaving your old kernel package in place.
Also, I will be changing things around slightly in anaconda tomorrow so that the
lilo.conf that gets written out if you're using grub isn't /etc/lilo.conf but is
instead something like /etc/lilo.conf.anaconda so that running lilo on a kernel
make install will fail unless you're using lilo.
Then given the number of times that this has come up on the beta list, you
should abandon grub. Unless it is reasonable for someone who is building a
kernel to end up with a system that they are going to have to rescue.
Will anaconda remove an existing lilo.conf? I think I have the same old
lilo.conf I've always had in 7.1, yep, there is where I have "bleed" as the
kernels I was messing with, as in when I run them my system bleeds". Will it
be a new function to move /etc/lilo.conf if the reconfig or install is done?
There are two files in question: the install.sh file that is part of the
kernel, and the /sbin/installkernel file. Which, I guess is part of kernel on
Redhat today and initscripts in other distributions.
Given that people will want to upgrade systems that have old kernels on them by
installing from the new redhat, won't this conflict exist whenever you try to
move the file from kernel? Kernel is one thing you usually leave on an
upgrade, right? You left my old kernels on the Roswell overlay. Right now, I
have my 7.1 kernels and my Roswell kernels. You can't have too many kernels.
I would assume that would continue, so that people could fall ack to old
I suppose I don't understand how hard it is to take ownership of a file in RPM,
or why it can't be fixed in the Kernel component.
I especially don't understand why it is fixed in mkinitd, since that is a
component I would not expect to need unless I actually was going to have an
initrd and it seems to be totally unrelated. Hmmm..it looks like mkinitrd is
tied in to lilo, and some other things that would only need it if you actually
needed an initial ramdisk. Oh, well, I guess the way things are going, everyone
will need an initial ramdisk.
But I would have guessed either Grub, initscripts, or kernel.