Re: Building new kernels for SuSE

From: Nico Kadel-Garcia (nkadel_at_comcast.net)
Date: 12/27/04

  • Next message: volkman: "splitting of harddisk partitions"
    Date: Mon, 27 Dec 2004 08:26:55 -0500
    
    

    "Michael Heiming" <michael+USENET@www.heiming.de> wrote in message
    news:6hb5a2-7r8.ln1@news.heiming.de...
    > In comp.os.linux.setup Nico Kadel-Garcia <nkadel@comcast.net>:
    >> 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
    >> xf86tools
    >> 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`
    > kernel-2.6.10mh-1

    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).


  • Next message: volkman: "splitting of harddisk partitions"