Re: Customizing the kernel installation process
On Sun, Apr 04 2010, Stephen Powell wrote:
> On Sun, 4 Apr 2010 14:19:08 -0400 (EDT), Manoj Srivastava wrote:
>> On Sun, Apr 04 2010, briand@aracnet.com wrote:
>>>
>>> for the longest time I have downloaded the kernel tarball and built
>>> outside of debian. however I'd like to use the debian nvidia packages,
>>> so I'm trying to build the kernel in the debian framework. however,
>>> rebuilding nvidia for the latest kernel has now become a problem (in
>>> the debian framework), so I'm thinking about dropping back to the
>>> tarball method.
>>>
>>> Maybe I need to be a little more persistent and then write something
>>> about rebuilding nvidia to complement Stephen's work.
>>>
>>> It is very handy having things installed as packages.
>>
>> For what it is worth, I also have an nvidia card. I nowadays
>> just use the kernel git tree. My usual sequence of action is to
>>
>> ,----
>> | % cd /usr/local/src/kernel/linus-tree.git
>> | % git fetch stable
>> | % git co -b my-machine-v2.6.33.2 v2.6.33.2
>> | % make oldconfig
>> | % ./.compile_command
>> | % sudo dpkg -i ../*.deb
>> `----
>>
>> Where .compile command looks like:
>>
>> ,----
>> | #!/bin/sh
>> |
>> | export MODULE_LOC=/usr/local/src/kernel/modules
>> |
>> | # Optionally, refresh the nvidia module
>> | # rm -rf ${MODULE_LOC}/nvidia-kernel
>> | ># (cd /usr/local/src/kernel; tar jfx /usr/src/nvidia-kernel.tar.bz2
>> |
>> | # make sure we get a machine specific name for the image, even if
>> | # I forgot to specify one on the command line
>> | ev=$(uname -n)
>> |
>> | # Use the version extension given on the command line, if any
>> | if [ -n "$1" ]; then
>> | ev=$1
>> | fi
>> |
>> | make-kpkg --rootcmd=fakeroot --append-to-version=-$ev kernel_image
>> | fakeroot make-kpkg --append-to-version=-$ev modules_image
>> `----
>>
>> Once you have your variant of .compile_command, building kernels
>> and nvidia packages is painless :-)
>>
>
> Thanks for participating, Manoj. If you needed to compile a custom
> kernel for some reason, and you were going to use an official Debian
> kernel source package (linux-source-2.6.32, for example), and you
> were going to use make-kpkg to create your custom kernel image, and
> you also wanted to use the proprietary Nvidia drivers, how would you
> do it? That's a specific example that I would like to integrate into
> my HOWTO. If I were smarter, or more experienced, I would probably
> be able to derive the steps from the above. But unfortunately, I'm not.
Oh, if it were me, I would extract the kernel sources, throw
away the ./debian directory, and use exactly the same steps as
above. That way, I'd get whatever patches are applied to Debian, and
yet not have to deal with -tree. -build, or what have you. (Indeed,
just call the script, the first thing it does is remove ./debian, so
you probably have to do nothing).
See, the above approach does not care how you arrived at the
kernel source tree -- I can jump from the bleeding edge rcX tree, to
stable trees, to any other tree I want to add a remote repo for, and
the script works. It would make no difference if you tree was somehow
derived from the official kernel tree sources. make-kpkg and the little
wrapper just don't _care_.
I ... have reservations about the ./debian directory structure
that the official kernel uses, so I can't actually advocate using that.
> Use official Debian packages wherever possible. But if the user has
> a custom kernel, I seem to remember that a kernel module that is
> customized for that kernel has to be built somehow. And I'd like
> make-kpkg do do as much of the work as possible. A single invocation
> of make-kpkg that has both the kernel_image and modules_image targets
> would be ideal. I haven't built a separate modules_image package since
> the days when ALSA was not part of the kernel. That's been a while!
Well, if you don't mind running the whole thing under fakeroot,
you could do:
fakeroot make-kpkg --append-to-version=-$ev kernel_image modules_image
and you are done. You run some stuff nuder fakeroot, but usually thsat
does not matter. Me, since it is a script, I just run make-kpkg
twice. Usually I am not even looking at the screen. So if ever there
is a conerner case that bites fakeroot (comething like that happened a
few years ago), I am covered somewhat better. But then, fakeroot bugs
are now far and few in between, so this is mostly historical reasons.
manoj
--
The sendmail configuration file is one of those files that looks like someone
beat their head on the keyboard. After working with it... I can see why! -- Harry Skelton
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
Reply to: