Heads up on an forthcoming rawhide kernel change...

[Don Dutile]

is there still an i686-PAE variant, and if so, is that distinguished in 
the kernel naming below ?


Jarod Wilson wrote:
> So we had a bug filed a while ago, requesting the ability to install the same 
> kernel version of different arches on the same system with the same /boot 
> partition:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=197065
> 
> To do that, we've made some changes that should be transparent to most users, 
> save those that are building external kernel modules. As of 
> kernel-2.6.25-0.154.rc6.git7.fc9, we now include the target cpu in uname -r 
> output, like so:
> 
> # uname -r
> 2.6.25-0.154.rc6.git7.fc9.x86_64
> 
> And we've also renamed files in /boot:
> 
> # ls /boot/*x86_64*
> /boot/config-2.6.25-0.154.rc6.git7.fc9.x86_64
> /boot/initrd-2.6.25-0.154.rc6.git7.fc9.x86_64.img
> /boot/System.map-2.6.25-0.154.rc6.git7.fc9.x86_64
> /boot/vmlinuz-2.6.25-0.154.rc6.git7.fc9.x86_64
> 
> # ls /boot/*i686*
> /boot/config-2.6.25-0.154.rc6.git7.fc9.i686
> /boot/initrd-2.6.25-0.154.rc6.git7.fc9.i686.img
> /boot/System.map-2.6.25-0.154.rc6.git7.fc9.i686
> /boot/vmlinuz-2.6.25-0.154.rc6.git7.fc9.i686
> 
> The uname -r change also means /lib/modules/ looks slightly different:
> 
> # ls /lib/modules/
> 2.6.25-0.154.rc6.git7.fc9.i686
> 2.6.25-0.154.rc6.git7.fc9.x86_64
> 
> And so do the contents of the kernel-devel packages:
> 
> # ls /usr/src/kernels/
> 2.6.25-0.154.rc6.git7.fc9.i686
> 2.6.25-0.154.rc6.git7.fc9.x86_64
> 
> This last one is probably the one with the most visible impact, as any 
> external module build script that was looking 
> for /usr/src/kernels/$(uname -r)-$(uname -m) should now be looking 
> for /usr/src/kernels/$(uname -r) only.
> 
> Sorry for the disruption, and it looks a touch ugly having arch in uname -r, 
> but hey, everyone else[*] is doing it. And now you can install both arch 
> kernels to the same /boot.
> 
> Yell loudly if we broke something besides external kernel module building, 
> which should be trivial for your 3rd-party module provider to fix.
> 
> [*] kylem says ubuntu/debian already do this, and possibly suse as well...
>