Bug 51655 - Kernel Make Install instals lilo, uninstalls grub
Summary: Kernel Make Install instals lilo, uninstalls grub
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: initscripts
Version: roswell
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
: 52039 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-13 17:28 UTC by Nick Simicich
Modified: 2014-03-17 02:22 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2001-08-28 06:16:07 UTC

Attachments (Terms of Use)

Description Nick Simicich 2001-08-13 17:28:22 UTC
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.

How reproducible:

Steps to Reproduce:
1.run grub-install
2.make bzImage
3.make install

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.

Additional info:


# arch/i386/boot/install.sh
# 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
# Arguments:
#   $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.

Comment 1 Glen Foster 2001-08-13 19:03:08 UTC
We (Red Hat) really need to fix this defect before next release.

Comment 2 Jeremy Katz 2001-08-13 22:33:00 UTC
/sbin/installkernel is in the kernel package...

Arjan, have we come to any sort of resolution on what's being done with this?

Comment 3 Arjan van de Ven 2001-08-13 22:42:31 UTC
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)

Comment 4 Arjan van de Ven 2001-08-19 19:38:56 UTC
*** Bug 52039 has been marked as a duplicate of this bug. ***

Comment 5 Bill Nottingham 2001-08-28 04:01:47 UTC
fixed in mkinitrd-3.2.1-1.

Comment 6 Bill Nottingham 2001-08-28 04:25:24 UTC
(as in, the file is moved. We really can't do anything with the contents until
the next release.)

Comment 7 Nick Simicich 2001-08-28 06:16:02 UTC
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?

Comment 8 Bill Nottingham 2001-08-28 06:19:09 UTC
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.

Comment 9 Jeremy Katz 2001-08-28 06:25:38 UTC
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.

Comment 10 Nick Simicich 2001-08-28 07:02:49 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.