Bug 35637 - Upgrade 2.2.14-22 to 2.2.17-14 fails - can't compile sources either
Summary: Upgrade 2.2.14-22 to 2.2.17-14 fails - can't compile sources either
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-04-11 14:42 UTC by Need Real Name
Modified: 2007-04-18 16:32 UTC (History)
0 users

Clone Of:
Last Closed: 2003-06-06 00:17:28 UTC

Attachments (Terms of Use)

Description Need Real Name 2001-04-11 14:42:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)


I've have a bunch (about 35) of RH7.0 computers to upgrade. Some are 100% 
EIDE, some are 100% SCSI. Some SCSI only computers are SMP.

I just ran the upgrade to move to 2.2.14-22 to 2.2.7-14.

On EIDE-only computers, lilo.conf was not using the correct image after 
the upgrade (it kept the old information) while old files were removed 
from /boot. If you reboot without editing lilo.conf before, you loose (in 
my case) the eth0 interface. Fix: leave /boot in the previous state, so it 
is coherent with lilo.conf, or modify the two.

Now, kernel-2.2.17-14 for SCSI: Scsi systems need an initrd file. The 
kernel-2.2.17-14.i686.rpm available from RH, when used with 'rpm
-Fvh' does not automagically make a new initrd image. Again, lilo.conf is 
not coherent with what in /boot after the upgrade. Again, one can loose 
access to eth0.

I also tried to compile kernel-source-2.2.16-22 & kernel-source-2.2.17-14 
with the latest gcc rpm (presented by RH as a fix to apply to RH7.0: gcc-
2.96-69). In both cases, on the system that I used
to try to compile the sources, a SMP system, I got:

- If smp is not activated, compilation (make bzImage) fails with:
/usr/src/linux-2.2.16/include/linux/kernel_stat.h:47: 'smp_num_cpus' 
undeclared (first use in this function)

- If smp is activated, compilation (make bzImage) fails with:
gcc -D__KERNEL__ -I/usr/src/linux-2.2.16/include -D__ASSEMBLY__ -D__SMP__ -
traditional -c checksum.S -o checksum.o
checksum.S:231: badly punctuated parameter list in #define
checksum.S:237: badly punctuated parameter list in #define

Since I also have this problem with the current version of the
kernel in RAW HIDE, I suspect that this may come from the GCC rpm
instead of the kernel source themselves.

I can give a full 'rpm -qa' if needed: the computer is RH7.0 + a
complete application of patches listed as needed to correct bugs
& security holes, as one can see on RH web site.


(I selected 'high' for these bugs, since one can apply all patches
as requested by RH and have his/her computer in a non-bootable state)

Reproducible: Always
Steps to Reproduce:

Actual Results:  .

Expected Results:  .


Comment 1 Need Real Name 2001-04-11 17:12:34 UTC
I tried a 'make mrproper' before, same result. I installed
kgcc-1.1.2-40 (got from RH7.0) and the compilation process was
okay! So the problem is 100% linked to the compilation tools.
Maybe the kernel-source rpm should require kgcc...

However, I've found something strange in net/ipv4/ip_masq.c :
I had to comment line 578 & 579 to be able to compile this file:


Comment 2 Arjan van de Ven 2001-04-17 13:28:02 UTC
1) Re the lilo.conf: You don't want the kernel rpm to edit your lilo.conf,
do       you?

2) Re "make mrproper" yes it is annoying, but there is nothing we can do
about      it given the state the kernel buildsystem is in

3) Re the EXPORT_SYMBOL(ip_masq_hash);, that should be fixed in the 2.2.19 we
   recently released.

Comment 3 Need Real Name 2001-04-17 14:49:48 UTC
1) About lilo.conf: I'd like the rpm to tell me something like "warning: files
have been changed in /boot. Check lilo.conf consistency!" and have files
removed from /boot put in a backup place. Or better, have the new files 
installed in "/tmp/boot/", with a message saying "new kernel installed in
/tmp/boot, you have to move it to /boot and edit lilo.conf".

In the actual situation, if someone just applies the patch and then reboot,
the system can be in a inconsistent state. This must be avoided.

2) For 'mrproper': the problem is the same: a comment from rpm(1) would
remind people of what is the first thing to do when installing the kernel
sources. (In this particular case it changed nothing but that's not the point)

I dunno if the rpm building system allows one to insert such comments in a
way that will display the comments when the package is installed. Obviously, you
would have less support to perform on these matters if such a feature is
used. (and have these comments copied in a file displayed at reboot when
one performed a full release upgrade)

My 2cts comment...

Comment 4 Arjan van de Ven 2001-04-17 17:00:30 UTC
It's hard to display those.
And NO files will be removed if you do rpm -i kernel-FOO.rpm
only if you use rpm -iU which you really shouldn't use.

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