test.kernel.org testing seems to have shaken out a problem with the
kernel banner changing, introduced by this commit:
[PATCH] Fix linux banner utsname information
commit a2ee8649ba6d71416712e798276bf7c40b64e6e5
We first noticed it with 2.6.19-git13 as we use this version string as
part of our boot validation process, which started tripping for every
job. Although we have been able to modify our validation, I am
concerned that this is a widespread mechanism for finding the version of
the kernel from non-running kernels. It appears that SLES9 and possibly
SLES10 is going to be affected too.
On a SLES9 box here, making an initrd for this kernel fails as below:
Module list: sym53c8xx reiserfs
Kernel version: %s (powerpc)
Kernel image: /boot/vmlinuz-autobench
Initrd image: /boot/initrd-autobench.img.new
No modules found for kernel %s
If you follow the initrd build process it appears that they look at the
compressed kernel and extract the internal version number from it, in
order to find the modules. For this they use the get_kernel_version,
which starts returning %s with this change:
# get_kernel_version /boot/vmlinuz-autobench
%s
Obviously this method is dubious at best for finding the kernel version
here. I do wonder if there should be some approved interface for
getting this information out of the kernel. Perhaps something similar
to the IKCFG_ST<config>IKCFG_ED bracketing the uname structure or something.
Andi, just a heads up.
-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
