bad postinst in kernel-images
Hello,
We (me and Marek Veber) have probably found a bug in postinst script in
Debian kernel images. Decription of the problem follows:
I was trying to install a new kernel-image-2.4.20-pentiumiii package (I am
building my own kernel-image debs, but I guess, the same problem is in
official Debian kernel-image debs) while I was running a kernel with the
same version (just only a new revision of the package). The package is
built from kernel-source-2.4.20-5 Debian package by make-kpkg. While
installing the package the postinst script is trying to create
a modules.dep file by running:
depmod -a -F $realimageloc/System.map-$version $version
But it found many unresolved symbols and I received a warning. It
corresponds to this part of code in the postinst script:
print "There was a problem running depmod. This may be benign, \n";
print "(You may have versioned symbol names, for instance).\n";
print "Or this could be an error.\n";
print "\tdepmod exited with return value $exit_value\n";
print "\tdepmod got a signal $signal_num \n" if $signal_num ;
print "\tdepmod dumped core \n" if $dumped_core ;
if ($initrd) {
print "Since this image uses initrd, I am not deleting the file\n";
print "/lib/modules/$version/modules.dep. However, there is no\n";
print "guarantee that the file is valid. I would strongly advice\n";
print "you to either abort and fix the errors in depmod, or \n";
print "regenerate the initrd image with a known good modules.dep\n";
print "file. I repeat, an initrd kernel image with a bad modules.dep\n";
print "shall fail to boot.\n";
}
Because I am using the initrd support, I got scared. So I called Marek and
we tried to solve the problem.
[ ... approx. one hour of trying to solve the problem ... ] :-)
Finally we located the problem. We found out, the call of
depmod -a -F $realimageloc/System.map-$version $version
is wrong. Although in the manpage of depmod is written:
-F kernelsyms,--filesyms kernelsyms
When building dependency files for a different kernel than the
currently running kernel, it is important that depmod uses the
correct set of kernel symbols to resolve the kernel references
in each module. These symbols can either be a copy of Sys-
tem.map from the other kernel, or a copy of the output from
/proc/ksyms. If your kernel uses versioned symbols, it is best
to use a copy of the /proc/ksyms output, since that file con-
tains the symbol versions of the kernel symbols. However you
can use a System.map even with versioned symbols.
Even it is written, you can use the System.map file, you cannot (so we
assume it is a bug in the documentation). But how can you obtain the
/proc/ksyms of the kernel, you cannot boot (at this moment)? The
System.map file looks like this:
c0100000 A _text
c0100000 t startup_32
c01000a5 t checkCPUtype
c0100133 t is486
c0100142 t is386
c0100191 t L6
c0100193 t ready
c0100194 t check_x87
[...]
/proc/ksyms looks like this:
[...]
c024103c i8253_lock_R2272a0d2
c0106e30 machine_real_restart_R3da1b07a
c0106d80 default_idle_R92897e3d
c029c2c0 drive_info_R744aa133
c0240b80 boot_cpu_data_R0657d037
c029bf88 EISA_bus_R7413793a
c029bf8c MCA_bus_Rf48a2c4c
c0114ab0 __verify_write_R203afbeb
[...]
First difference is missing the _R2272a0d2 stuff in the System.map file.
But it does not matter. Second difference is missing the middle column in
/proc/ksyms. So we tried to put -F /tmp/System.map as an argument to
depmod, where /tmp/System.map was the $realimageloc/System.map-$version
file, but without the middle column. I guess it can be obtained by
running:
cut -d " " -f 1,3 $realimageloc/System.map-$version > /tmp/System.map
And it worked. No unresolved symbols, no errors and the kernel booted
successfully. So we assume, the postinst script should be changed in such
similar way. What do you think about that?
Regards,
Marcel Kolaja
soLNet, s.r.o. http://www.solnet.cz/
--------------------------------------------------------------------------
"If I have trouble installing Linux, something is wrong. Very wrong."
-- Linus Torvalds
Reply to: