Re: Building new kernels for SuSE
From: Nico Kadel-Garcia (nkadel_at_comcast.net)
Date: Mon, 27 Dec 2004 08:26:55 -0500
"Michael Heiming" <michael+USENET@www.heiming.de> wrote in message
> In comp.os.linux.setup Nico Kadel-Garcia <firstname.lastname@example.org>:
>> For various reasons, I'm playing with SuSE these days, and have found the
>> RPM structure for kernel management badly fractured. It's impossible to
>> simpy do a "rpm --rebuiild" of one of their "src.rpm" or "nosrc.rpm"
>> packages, they have dependencies on weird km_* modules you have to build
>> from other, not obviously related packages like km_nvidia from the
>> SRPM, and require some "kernel-dummy" package and can't find their own
>> included copy of "patches.addon.tar.gz"
> In general it's a pain in the ass modifying a .spec from a distro
> munged kernel if you want to update/modify the rpm on your own.
The spec file isn't the problem. It's turning off features for a security
reason, and even getting their own published SRPM's or this funky
".nosrc.rpm" thing to recompile with new .config files to disable or enable
specific hardware. Their own standard SRPM's cannot be recompiled without
massaging their prostates to provide or eliminate "kernel-dummy",
"km-nvidia", and other strange little widgets that are not directly
published ini their public repositories nor, as near as I can tell, on their
distribution CD's. I'm concerned they're in violation of the GPL with this
whackiness, or at least not bothering to include at least source code for
their un-tainted modules such as "kernel-dummy".
> But then if kernel 2.6 and you have no needs for any fancy
> enhancement or/and dislike to run a tainted kernel why bother?
For several reasons.
1: I don't want YaST auto-updates to update my kernel under me, so I
wanted to rename the built-up kernel RPM as "kernel-nousb" so that YaST
wouldn't try to replace it.
2: I do need a tainted kernel, namely NVidia support which is its own IP
rights nightmare and support problem.
3: Running brand spanking new, high-end hardware with an older kernel
without the patches backported is difficult, running it with a brand new
latest kernel is dangerous, in general it's safer to take the kernel that it
was known to run under and make minimal necessary changes to it (such as
working from a kernel-source RPM). But integrating in, for example, the
NVidia support YaST uses or the necessary grub.conf changes is more than a
bit of a nightmare to support across a wide number of machines, especially
when you start getting into some SMP, some single-processor, some x86_64,
etc., etc. Much safer to build up a new clean set of RPM's.
I used to be able to just churn these out in the Fedora world, but this SuSE
setup is confusing, obscure, and difficult.
> Download from kernel.org, use the old config and run 'make rpm'
> and you get a nice src and binary rpm out of it.;)
> $ rpm -qf /boot/vmlinuz-`uname -r`
Huh. The "make rpm" is new, I'll take look at whether it works well. I'm
afraid it'll diverge pretty wildly from the SuSE structure, especially the
integration of NVidia support.
Oh, did I fail to mention that SuSE broke grub-install in the process of
shoving some of its functionality into YaST to hide it from mere mortals
like me who actually use the command line? (That may not be why they did it,
but it's the result).