Red Hat Bugzilla – Bug 35637
Upgrade 2.2.14-22 to 2.2.17-14 fails - can't compile sources either
Last modified: 2007-04-18 12:32:38 EDT
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:
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)
Steps to Reproduce:
Actual Results: .
Expected Results: .
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:
1) Re the lilo.conf: You don't want the kernel rpm to edit your lilo.conf,
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
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...
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.