I sent this to kernel newbies first, and while I got one response there,
it answered a different question than the one I was asking...
I'm on a SuSE system.
I'm working on automating the install of said system, but it needs a
Linus kernel - 2.6.21.7 specifically, and it needs kernel source too so
that we can build modules in the field as needed.
I see you can make an rpm of a bootable kernel with "make rpm".
Is there a streamlined way of building a corresponding kernel-source
RPM? Or do people pretty much all just dump the source in /usr/src, and
manually update symlinks as needed? If the latter, what symlinks need
to be updated?
On Wed, 12 Sep 2007 09:13:41 -0700, Dan Stromberg wrote:
>
> I sent this to kernel newbies first, and while I got one response there,
> it answered a different question than the one I was asking...
>
> I'm on a SuSE system.
>
> I'm working on automating the install of said system, but it needs a
> Linus kernel - 2.6.21.7 specifically, and it needs kernel source too so
> that we can build modules in the field as needed.
>
> I see you can make an rpm of a bootable kernel with "make rpm".
>
> Is there a streamlined way of building a corresponding kernel-source
> RPM? Or do people pretty much all just dump the source in /usr/src, and
> manually update symlinks as needed? If the latter, what symlinks need
> to be updated?
Please note that I don't mean just a .src.rpm.
Also, I probably should point out that I've spent a couple of hours
googling about this, and am not finding much.
On Wed, Sep 12, 2007 at 09:13:41AM -0700, Dan Stromberg wrote:
>
> I sent this to kernel newbies first, and while I got one response there,
> it answered a different question than the one I was asking...
>
> I'm on a SuSE system.
>
> I'm working on automating the install of said system, but it needs a
> Linus kernel - 2.6.21.7 specifically, and it needs kernel source too so
> that we can build modules in the field as needed.
>
> I see you can make an rpm of a bootable kernel with "make rpm".
>
> Is there a streamlined way of building a corresponding kernel-source
> RPM? Or do people pretty much all just dump the source in /usr/src, and
> manually update symlinks as needed? If the latter, what symlinks need
> to be updated?
Being rpm ignorant I do not know what the expected content of a kernel-source RPM
are but this is the available targets for kernel packaging (from make help):
Kernel packaging:
rpm-pkg - Build the kernel as an RPM package
binrpm-pkg - Build an rpm package containing the compiled kernel
and modules
deb-pkg - Build the kernel as an deb package
tar-pkg - Build the kernel as an uncompressed tarball
targz-pkg - Build the kernel as a gzip compressed tarball
tarbz2-pkg - Build the kernel as a bzip2 compressed tarball
I just tried binrpm-pkg - but alas I have no rpm installed it failed.
Sam
On Wed, 2007-09-12 at 09:13 -0700, Dan Stromberg wrote:
> I sent this to kernel newbies first, and while I got one response there,
> it answered a different question than the one I was asking...
Are you sure?
> I'm on a SuSE system.
>
> I'm working on automating the install of said system, but it needs a
> Linus kernel - 2.6.21.7 specifically, and it needs kernel source too so
> that we can build modules in the field as needed.
Find a kernel-source.*.src.rpm or kernel-*.src.rpm or whatever SuSE uses
for
nameing convention and reverse engineer the .spec file.
Fedora BTW abandoned kernel-source* and they have now a website with a
description
how to produce a configured kernel source tree (e.g. for out-of-tree
modules).
> I see you can make an rpm of a bootable kernel with "make rpm".
Well, then there must be a .spec file somewhere which just wants to be
extended.
> Is there a streamlined way of building a corresponding kernel-source
> RPM? Or do people pretty much all just dump the source in /usr/src, and
Yes, you put all the steps you do by hand into the .spec file. That's
it.
> manually update symlinks as needed? If the latter, what symlinks need
> to be updated?
Actually nowadays usually there no "sym-link updating" anymore necessary
-
just put the correct ones in /lib/modules/$(uname -r)/ and the full name
in
/boot/grub/menu.lst.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Wed, 2007-09-12 at 19:05 +0200, Sam Ravnborg wrote:
[....]
> Being rpm ignorant I do not know what the expected content of a kernel-source RPM
> are but this is the available targets for kernel packaging (from make help):
The kernel-source including all patches and configured as usually to be
found under
/usr/src/linux-$VERSION (or so). One needs that for e.g. external
modules.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Wed, 12 Sep 2007 19:09:26 +0200, Bernd Petrovitsch wrote:
> On Wed, 2007-09-12 at 09:13 -0700, Dan Stromberg wrote:
>> I sent this to kernel newbies first, and while I got one response there,
>> it answered a different question than the one I was asking...
>
> Are you sure?
Yes, I'm sure. The answer over there was "you don't want to do that. Do
this instead.
>> I'm on a SuSE system.
>>
>> I'm working on automating the install of said system, but it needs a
>> Linus kernel - 2.6.21.7 specifically, and it needs kernel source too so
>> that we can build modules in the field as needed.
>
> Find a kernel-source.*.src.rpm or kernel-*.src.rpm or whatever SuSE uses
> for
> nameing convention and reverse engineer the .spec file.
> Fedora BTW abandoned kernel-source* and they have now a website with a
> description
> how to produce a configured kernel source tree (e.g. for out-of-tree
> modules).
So this is as smooth as producing kernel-source RPM's gets?
I might be better off sticking with a .tar.bz2 and repointing symlinks.
>> I see you can make an rpm of a bootable kernel with "make rpm".
>
> Well, then there must be a .spec file somewhere which just wants to be
> extended.
I'm not sure this is going to be any easier to automate, if that's what's
required.
>> Is there a streamlined way of building a corresponding kernel-source
>> RPM? Or do people pretty much all just dump the source in /usr/src, and
>
> Yes, you put all the steps you do by hand into the .spec file. That's
> it.
I may just stick them in a bash script and forget about the RPM. Or are
there other packages that are going to be cranky, dependencywise, if I
ignore the RPM?
>> manually update symlinks as needed? If the latter, what symlinks need
>> to be updated?
>
> Actually nowadays usually there no "sym-link updating" anymore necessary
On OpenSuSE 10.2, there appears to be:
# find / /home -xdev -ls | egrep -- '-> /usr/src/linux'
215641 0 lrwxrwxrwx 1 root root 26 Sep 11 17:50 /lib/modules/2.6.18.2-34-default/source -> /usr/src/linux-2.6.18.2-34
213786 0 lrwxrwxrwx 1 root root 45 Sep 11 17:50 /lib/modules/2.6.18.2-34-default/build -> /usr/src/linux-2.6.18.2-34-obj/x86_64/default
> just put the correct ones in /lib/modules/$(uname -r)/ and the full name
> in
> /boot/grub/menu.lst.
Which correct "ones"? Sometimes pronouns aren't shortcuts :)
Thanks!
On Wed, Sep 12, 2007 at 07:11:21PM +0200, Bernd Petrovitsch wrote:
> On Wed, 2007-09-12 at 19:05 +0200, Sam Ravnborg wrote:
> [....]
> > Being rpm ignorant I do not know what the expected content of a kernel-source RPM
> > are but this is the available targets for kernel packaging (from make help):
>
> The kernel-source including all patches and configured as usually to be
> found under
> /usr/src/linux-$VERSION (or so). One needs that for e.g. external
> modules.
For external modules you need a fully build kernel which may be
clean up by "make clean".
Thats not the same as a source RPM as per my understanding.
Sam
On Sep 12 2007 10:31, Dan Stromberg wrote:
>
>>> I'm on a SuSE system.
>>>
>>> I'm working on automating the install of said system, but it needs a
>>> Linus kernel - 2.6.21.7 specifically, and it needs kernel source too so
>>> that we can build modules in the field as needed.
>>
>> Find a kernel-source.*.src.rpm or kernel-*.src.rpm or whatever SuSE
>> uses for nameing convention and reverse engineer the .spec file.
>> Fedora BTW abandoned kernel-source* and they have now a website with
>> a description how to produce a configured kernel source tree (e.g.
>> for out-of-tree modules).
>
>So this is as smooth as producing kernel-source RPM's gets?
>
>I might be better off sticking with a .tar.bz2 and repointing symlinks.
Do that for a handful of machines and it gets tiresome.
>>> I see you can make an rpm of a bootable kernel with "make rpm".
>>
>> Well, then there must be a .spec file somewhere which just wants to be
>> extended.
>
>I'm not sure this is going to be any easier to automate, if that's what's
>required.
The 'proper' (though this is not an authoritative answer) way is to
build the rpm the same way SUSE did. This ensures best compatibility and
the fewest surprises. I am not saying it is easy, though.
>>> Is there a streamlined way of building a corresponding kernel-source
>>> RPM? Or do people pretty much all just dump the source in /usr/src, and
>>
>> Yes, you put all the steps you do by hand into the .spec file. That's
>> it.
>
>I may just stick them in a bash script and forget about the RPM. Or are
>there other packages that are going to be cranky, dependencywise, if I
>ignore the RPM?
Somewhat. The kernel rpm and 3rd party kernel module rpms share symbols
so that upgrading will upgrade all the necessary things. (Instead of
having to go through it all manually.)
>>> manually update symlinks as needed? If the latter, what symlinks need
>>> to be updated?
>>
>> Actually nowadays usually there no "sym-link updating" anymore necessary
>
>On OpenSuSE 10.2, there appears to be:
It is not necessary. rpm -Uhv'ing the kernel-source rpm will repoint the
symlink to the version you just installed.
>> just put the correct ones in /lib/modules/$(uname -r)/ and the full
>> name in /boot/grub/menu.lst.
>
>Which correct "ones"? Sometimes pronouns aren't shortcuts :)
Use http://benjiweber.co.uk:8080/webpin/ , and be happy.
Jan
--
On Wed, 2007-09-12 at 10:31 -0700, Dan Stromberg wrote:
> On Wed, 12 Sep 2007 19:09:26 +0200, Bernd Petrovitsch wrote:
[...]
> >> I'm on a SuSE system.
> >>
> >> I'm working on automating the install of said system, but it needs a
> >> Linus kernel - 2.6.21.7 specifically, and it needs kernel source too so
> >> that we can build modules in the field as needed.
> >
> > Find a kernel-source.*.src.rpm or kernel-*.src.rpm or whatever SuSE uses
> > for
> > nameing convention and reverse engineer the .spec file.
> > Fedora BTW abandoned kernel-source* and they have now a website with a
> > description
> > how to produce a configured kernel source tree (e.g. for out-of-tree
> > modules).
>
> So this is as smooth as producing kernel-source RPM's gets?
I had no problems with the kernel-source.*.rpm approach.
> I might be better off sticking with a .tar.bz2 and repointing symlinks.
>
> >> I see you can make an rpm of a bootable kernel with "make rpm".
> >
> > Well, then there must be a .spec file somewhere which just wants to be
> > extended.
>
> I'm not sure this is going to be any easier to automate, if that's what's
> required.
The problem, that automation of such a task depend on various factors
(which
may be somewhat private):
- you have a linux-$VERSION:tar.bz2
- optionally, you have patches. And some distributions have *lots* of.
- you need a .config (and run `make oldconfig`).
You have to decide on each (independent if you build an RPM or a script)
of
them.
If you need regularly .rpm from ongoing development, you probably need
to figure out first which procedure is the best.
It's from a conceptual view different if you either have your kernel
source
and produce new kernels every other day for testing, etc. (then simple
scripts
are more than enough) or you produce a .rpm every other day to install
it and
keep it for months (for whatever reason).
[...]
> I may just stick them in a bash script and forget about the RPM. Or are
A .spec file is a just set of "scripts", some meta-information and
produces
a container. And you have a package management at install time.
I can't decide if the more effort for the .rpm pays off for you - that
also
depends on factors like "geek value", "number of installations", ....
And that the reason for me to suggest to find a recent SuSEs
kernel.src.rpm
and start from there or find the one behind the "make rpm" thingy.
[....]
> On OpenSuSE 10.2, there appears to be:
>
> # find / /home -xdev -ls | egrep -- '-> /usr/src/linux'
> 215641 0 lrwxrwxrwx 1 root root 26 Sep 11 17:50 /lib/modules/2.6.18.2-34-default/source -> /usr/src/linux-2.6.18.2-34
> 213786 0 lrwxrwxrwx 1 root root 45 Sep 11 17:50 /lib/modules/2.6.18.2-34-default/build -> /usr/src/linux-2.6.18.2-34-obj/x86_64/default
Yup, but these (usually) don't change at run-time. So I would put them
into
the .rpm like any other sym-link (or delete and create them in the
pre-rm and
post-install scripts if it's not fixed at rpm-build-time).
> > just put the correct ones in /lib/modules/$(uname -r)/ and the full name
> > in
> > /boot/grub/menu.lst.
>
> Which correct "ones"? Sometimes pronouns aren't shortcuts :)
Sorry, the correct sym-links. Since I have no experience with recent
SuSE,
I didn't know that's the same as in the RedHat world (but they point
somewhere else).
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Wed, 2007-09-12 at 19:51 +0200, Sam Ravnborg wrote:
> On Wed, Sep 12, 2007 at 07:11:21PM +0200, Bernd Petrovitsch wrote:
> > On Wed, 2007-09-12 at 19:05 +0200, Sam Ravnborg wrote:
> > [....]
> > > Being rpm ignorant I do not know what the expected content of a kernel-source RPM
> > > are but this is the available targets for kernel packaging (from make help):
> >
> > The kernel-source including all patches and configured as usually to be
> > found under
> > /usr/src/linux-$VERSION (or so). One needs that for e.g. external
> > modules.
> For external modules you need a fully build kernel which may be
> clean up by "make clean".
> Thats not the same as a source RPM as per my understanding.
Yes, if "source RPM" means files named like "kernel-$VERSION.src.rpm".
But we are talking[0] about a kernel-source-$VERSION.$ARCH.rpm's which
contain
the kernel sources (read: lots of .c and .h files, etc.) - including a
matching
.config and after `make oldconfig` - so that one can build out-of-tree
modules
after installing it with "KSRC=" (or whatever the Makefile parameter is
usually called).
And such kernel-source-$VERSION.$ARCH.rpm's may/will/should fall also
out
of a rebuild of a kernel-$VERSION.src.rpm.
Bernd
[0]: And Dan pointed it out explicitly right at the start BTW.
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
>
> But we are talking[0] about a kernel-source-$VERSION.$ARCH.rpm's which
> contain
> the kernel sources (read: lots of .c and .h files, etc.) - including a
> matching
> .config and after `make oldconfig` - so that one can build out-of-tree
> modules
> after installing it with "KSRC=" (or whatever the Makefile parameter is
> usually called).
You need certain things of the kernel built before you can build
external modules (if they use a sane build approach).
Just including the .config with the kernel source is far from enough.
Sam
On Wed, 2007-09-12 at 20:16 +0200, Sam Ravnborg wrote:
> >
> > But we are talking[0] about a kernel-source-$VERSION.$ARCH.rpm's which
> > contain
> > the kernel sources (read: lots of .c and .h files, etc.) - including a
> > matching
> > .config and after `make oldconfig` - so that one can build out-of-tree
> > modules
> > after installing it with "KSRC=" (or whatever the Makefile parameter is
> > usually called).
> You need certain things of the kernel built before you can build
> external modules (if they use a sane build approach).
> Just including the .config with the kernel source is far from enough.
ACK.
That all must be done/prepared correctly for the kernel-source-*.rpm.
And nobody said it is trivial or easy.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On 12.09.2007 20:03, Bernd Petrovitsch wrote:
> On Wed, 2007-09-12 at 10:31 -0700, Dan Stromberg wrote:
>> On Wed, 12 Sep 2007 19:09:26 +0200, Bernd Petrovitsch wrote:
> [...]
>>> Fedora BTW abandoned kernel-source* and they have now a website with a
>>> description
>>> how to produce a configured kernel source tree (e.g. for out-of-tree
>>> modules).
That explanation is IMHO a bit misleading. Fedora ships kernel-devel
packages for all their kernels. Those contain everything from the
source-tree that's needed to build out-of-tree modules -- Makefiles for
example, but no real sources.
Well, to be more precise: that is enought for out-of-tree modules that
get shipped with proper Makefiles/Layout, which is the case for nearly
every external module these days. The "website with a description how to
produce a configured kernel source tree" exists as well, for people that
want to build kernels the way the Fedora builds them, but want to apply
additional patches/other sources.
>> So this is as smooth as producing kernel-source RPM's gets?
> I had no problems with the kernel-source.*.rpm approach.
I think the Fedora approach has many benefits -- I always wondered why
it never went upstream like a "make install_develstuff" that install all
the needed bits to
/lib/modules/$(uname -r)/build/
CU
knurd
Hi knurd.
> I think the Fedora approach has many benefits -- I always wondered why
> it never went upstream like a "make install_develstuff" that install all
> the needed bits to
> /lib/modules/$(uname -r)/build/
Last time I saw the patch is was to ugly to consider.
Now that is maybe a year ago and I would be happy to take another look
should someone submit it to me.
Sam
On Sep 12 2007 20:23, Bernd Petrovitsch wrote:
>On Wed, 2007-09-12 at 20:16 +0200, Sam Ravnborg wrote:
>>>
>>> But we are talking[0] about a kernel-source-$VERSION.$ARCH.rpm's
>>> which contain the kernel sources (read: lots of .c and .h files,
>>> etc.) - including a matching .config and after `make oldconfig` - so
>>> that one can build out-of-tree modules after installing it with
>>> "KSRC=" (or whatever the Makefile parameter is usually called).
>>
>> You need certain things of the kernel built before you can build
>> external modules (if they use a sane build approach). Just including
>> the .config with the kernel source is far from enough.
>
>ACK. That all must be done/prepared correctly for the
>kernel-source-*.rpm. And nobody said it is trivial or easy.
Trivial as far as SUSE goes. Install the binary package and you get all
the symvers, modvers, and everything of the O= part that is needed. That
is because symvers are per-binary image and not per-source.
Remain the Makefiles, which are in (the big) kernel-source rpm :-/
Jan
--
On Wed, 12 Sep 2007, Jan Engelhardt wrote:
>
> On Sep 12 2007 20:23, Bernd Petrovitsch wrote:
>> On Wed, 2007-09-12 at 20:16 +0200, Sam Ravnborg wrote:
>>>>
>>>> But we are talking[0] about a kernel-source-$VERSION.$ARCH.rpm's
>>>> which contain the kernel sources (read: lots of .c and .h files,
>>>> etc.) - including a matching .config and after `make oldconfig` - so
>>>> that one can build out-of-tree modules after installing it with
>>>> "KSRC=" (or whatever the Makefile parameter is usually called).
>>>
>>> You need certain things of the kernel built before you can build
>>> external modules (if they use a sane build approach). Just including
>>> the .config with the kernel source is far from enough.
>>
>> ACK. That all must be done/prepared correctly for the
>> kernel-source-*.rpm. And nobody said it is trivial or easy.
>
> Trivial as far as SUSE goes. Install the binary package and you get all
> the symvers, modvers, and everything of the O= part that is needed. That
> is because symvers are per-binary image and not per-source.
>
> Remain the Makefiles, which are in (the big) kernel-source rpm :-/
>
>
>
> Jan
If his base package was RedHat, he can just download the sources
he wants, from ftp.kernel.org, un-tar the *.gz file into /usr/src,
then copy the .config used to build the existing kernel from /boot.
It is called /boot/config-`uname -r`. Copy that to the new
kernel tree as ".config" then chdir to that tree and execute
`make oldconfig`. Some questions will have to be answered because
the newer kernel will have additional drivers.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On 09/12/2007 01:09 PM, Bernd Petrovitsch wrote:
> Fedora BTW abandoned kernel-source* and they have now a website with a
> description
> how to produce a configured kernel source tree (e.g. for out-of-tree
> modules).
>
The kernel-devel package is all that's needed for out-of-tree modules.
Hi Sam!
On 12.09.2007 22:03, Sam Ravnborg wrote:
>> I think the Fedora approach has many benefits -- I always wondered why
>> it never went upstream like a "make install_develstuff" that install all
>> the needed bits to
>> /lib/modules/$(uname -r)/build/
> Last time I saw the patch is was to ugly to consider.
Do you have a pointer to that patch?
Note that in Fedora it seems all (most of) the logic is afaics in the
rpm spec file itself and thus not suitable for the kernel :-/
> Now that is maybe a year ago and I would be happy to take another look
> should someone submit it to me.
Maybe I should take a closer look at it sooner or later myself...
Cu
knurd
On Thu, Sep 13, 2007 at 07:09:18PM +0200, Thorsten Leemhuis wrote:
> Hi Sam!
>
> On 12.09.2007 22:03, Sam Ravnborg wrote:
> >> I think the Fedora approach has many benefits -- I always wondered why
> >> it never went upstream like a "make install_develstuff" that install all
> >> the needed bits to
> >> /lib/modules/$(uname -r)/build/
> > Last time I saw the patch is was to ugly to consider.
>
> Do you have a pointer to that patch?
See: http://lkml.org/lkml/2007/9/12/331
Chris Wedgwood posted it today.
Sam
On 13.09.2007 19:22, Sam Ravnborg wrote:
> On Thu, Sep 13, 2007 at 07:09:18PM +0200, Thorsten Leemhuis wrote:
>> On 12.09.2007 22:03, Sam Ravnborg wrote:
>>>> I think the Fedora approach has many benefits -- I always wondered why
>>>> it never went upstream like a "make install_develstuff" that install all
>>>> the needed bits to
>>>> /lib/modules/$(uname -r)/build/
>>> Last time I saw the patch is was to ugly to consider.
>> Do you have a pointer to that patch?
> See: http://lkml.org/lkml/2007/9/12/331
> Chris Wedgwood posted it today.
Missed that -- thx for the pointer and sorry for the noise.
Cu
knurd