Phil Perry a écrit :
On 26/03/11 21:00, Yannick Perret wrote:
Hello,
not sure if it was still pointed here, so:
in RHEL6 (and so in SL6, and the later Fedora) Redhat changed the output
of 'uname'. Now the arch is added to the kernel version.
It means that on my SL6 I get:
uname -r
2.6.32-71.18.2.el6.x86_64
whereas on a SL5 I get:
2.6.18-238.12cc.el5 (do not mind the strange release version, we use a
patched version of our own).
It is a small change, but it can makes people loosing time to find out
why some existing stuff brokes on SL6 (such as using "uname -r" to build
kernel dependancies in SPEC files or using it to verify the installed
kernel).
It was just to share - I loose a little of my time when building some
kernel modules.
Regards,
--
Y.
Yes, it's a known issue:
https://bugzilla.redhat.com/show_bug.cgi?id=588430
Coming from el5 I too found it "unexpected" behaviour.
Yes, saw these reports. Not clear what they planed to do for this. The
explanation seems to be to allow installing 32bit and 64bit kernels on
the same machine (so in /boot/) without initrd/vmlinuz name collision
(same for /lib/modules/ and /usr/src/kernels/). The result is probably a
good idea - even if installing 32b+64b kernel implies to have separated
filesystems for binaries, so having a separated /boot should be a good
idea too -, but I would have expected them to use "`uname -r`.`uname
-m`" for building files instead of changing the "uname" output...
Not a very big issue, and by my side I patched 'uname' to restore the
previous behavior (at least the time to check existing scripts that use
'uname -r' output).
Regards,
--
Y.
