[lkml]   [2006]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject2.6.19-git13: uts banner changes break SLES9 (at least) 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/
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

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-12-11 16:13    [W:0.092 / U:3.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site