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.