Compiling a kernel
cothrige
the reference and searched online (some searches involve such common
terms they never return anything useful) I have really been unable to
find a clear answer. I hope someone here can help.
In the past, as a Slackware user, I never installed an OS where I
didn't immediately compile a new kernel. Slack uses a 2.4 kernel, and
I use some peripheral items which seem to require, or at least greatly
prefer a 2.6 kernel. The process I used was very simple, and I got
quite used to it. I downloaded the sources from www.kernel.org and
opened them up in /usr/src/. I then would run 'make menuconfig',
'make' and 'make modules_install.' I copied the bzImage into /boot,
as well as the System.map and config file. I edited lilo.conf, ran
/sbin/lilo and rebooted into the new kernel. All usually went well
and I rarely had to look back.
However, I cannot find out if this will work in Debian. (I am using
grub so obviously the lilo thing would not) The entire system behind
everything seems so much more detailed and complex than Slack that I
have my doubts this will work at all. Do I have to use kernel sources
from Debian? And will this completely throw off dependency situations
in apt? Or, is there maybe a Debian tool to compile a kernel which is
intended to be used rather than this "classic" method? While things
seem fine with the kernel installed from apt, better than fine
actually, I figure the day is going to come when I will need to
compile a new kernel, and I would like to know if possible what to
expect. Not to mention just plain how to do it.
Many thanks in advance,
Patrick
Andrei Popescu
> I am sure this is a really stupid question, but having read through
> the reference and searched online (some searches involve such common
> terms they never return anything useful) I have really been unable to
> find a clear answer. I hope someone here can help.
I never compiled on Debian, but I watched many threads so I hope I can
give you a few pointers.
The Debian Way (tm) to compile a kernel is using make-kpkg. This will
create a .deb which you can install using 'dpkg -i'. I haven't done
this myself, but the archives of this list contain many examples.
AFAICT this can be done with sources from kernel.org as well.
The default Debian kernel needs an initrd because it has many things
compiled as modules. You might be able to avoid the initrd if you
compile most (or everything) in. YMMV
You can compile a kernel from scratch using the classic method. After
you copy the image in /boot just run update-grub and it will add it to
your boot menu. You might want to read the notes in
/boot/grub/menu.lst if you want/need to add boot options.
HTH,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Seweryn Kokot
For more than a year I compile my kernels the way you described
(universal vay) and I have no problems. Of course there is a debian
way but it's not a must.
Regards,
Seweryn
Tim Post
Its relatively easy .. and you can make it a bit easier on yourself.
Untar from kernel.org in /usr/src
be sure ncurses-dev and ncurses are present
make menuconfig and configure your kernel
now make (or make -j xx, where xx = # of cpu's if > 1) [ fancy gcc hacks
go here if your brave ]
if modular - make modules_install
make install (will copy vmlinuz and friends to /boot)
I typically use grub, however I think it will update lilo for you if
present and in use.
Then make your initrd if needed and tweak as needed, verify /etc/modules
is what you want it to be and you should be good to go. Cross your
fingers and reboot.
Really very little difference at all. "make help" is also very helpful.
HTH
Best,
-Tim
John O'Hagan
[...]
> In the past, as a Slackware user, I never installed an OS where I
> didn't immediately compile a new kernel. Slack uses a 2.4 kernel, and
> I use some peripheral items which seem to require, or at least greatly
> prefer a 2.6 kernel. The process I used was very simple, and I got
> quite used to it. I downloaded the sources from www.kernel.org and
> opened them up in /usr/src/. I then would run 'make menuconfig',
> 'make' and 'make modules_install.' I copied the bzImage into /boot,
> as well as the System.map and config file. I edited lilo.conf, ran
> /sbin/lilo and rebooted into the new kernel. All usually went well
> and I rarely had to look back.
>
> Or, is there maybe a Debian tool to compile a kernel which is
> intended to be used rather than this "classic" method? While things
> seem fine with the kernel installed from apt, better than fine
> actually, I figure the day is going to come when I will need to
> compile a new kernel, and I would like to know if possible what to
> expect. Not to mention just plain how to do it.
Hi Patrick,
I always compile my own kernels the Debian (testing) way like this:
-Install the latest Debian linux-source package (currently
linux-source-2.6.17); or you can use vanilla source as you describe
-Make a symlink /usr/src/linux to the resulting
folder /usr/src/linux-source-2.6.17 (is this step still necessary?)
-Configure the kernel
-In /usr/src/linux, run "make-kpkg buildpackage kernel-image" (there are other
options, in the man page)
-Install the resulting .deb packages in /usr/src with dpkg -i
- Reboot into your new kernel
This will build a kernel without an initrd, so you must compile in all drivers
for the the boot disk(s). Or use the --initrd option.
If you are recompiling a kernel with the same version name, you must
move /lib/modules/[$KERNEL_VERSION] out of the way (you are warned if you
forget!), or you can use the --revision or --append-to-version options to
avoid this.
HTH,
John
cothrige
> Hi Patrick,
Hello John,
> I always compile my own kernels the Debian (testing) way like this:
>
> -Install the latest Debian linux-source package (currently
> linux-source-2.6.17); or you can use vanilla source as you describe
> -Make a symlink /usr/src/linux to the resulting
> folder /usr/src/linux-source-2.6.17 (is this step still necessary?)
I have wondered this too. I always do it, but it seems like I read
something somwhere suggesting that it is not needed.
> -Configure the kernel
> -In /usr/src/linux, run "make-kpkg buildpackage kernel-image" (there are other
> options, in the man page)
> -Install the resulting .deb packages in /usr/src with dpkg -i
Will I still have to configure grub? And will update-grub work or
will I have to manually edit menu.lst? I am still getting the hang of
grub. It was never a part of Slackware and so I had become very
comfortable with lilo.
> - Reboot into your new kernel
>
> This will build a kernel without an initrd, so you must compile in all drivers
> for the the boot disk(s). Or use the --initrd option.
I prefer to go without initrd myself. Just seems a tad faster, though
probably my imagination.
> If you are recompiling a kernel with the same version name, you must
> move /lib/modules/[$KERNEL_VERSION] out of the way (you are warned if you
> forget!), or you can use the --revision or --append-to-version options to
> avoid this.
This is new to me. Will these flags stop clobbering of my modules?
If so, that is a very cool feature. I forget to move my modules at
least half of the time and it really stinks. I think it is because in
Slack since I was going from a 2.4 to a 2.6 it never seemed to
matter. I am going to do some reading on this.
Many thanks for the help.
Patrick
Ron Johnson
Hash: SHA1
On 10/22/06 09:36, cothrige wrote:
> * John O'Hagan (johno...@iprimus.com.au) wrote:
>> Hi Patrick,
>
> Hello John,
>
[snip]
>> If you are recompiling a kernel with the same version name, you must
>> move /lib/modules/[$KERNEL_VERSION] out of the way (you are warned if you
>> forget!), or you can use the --revision or --append-to-version options to
>> avoid this.
Or edit the CONFIG_LOCALVERSION line of /usr/src/linux/.config.
> This is new to me. Will these flags stop clobbering of my modules?
Yes.
> If so, that is a very cool feature. I forget to move my modules at
> least half of the time and it really stinks. I think it is because in
> Slack since I was going from a 2.4 to a 2.6 it never seemed to
> matter. I am going to do some reading on this.
- --
Ron Johnson, Jr.
Jefferson LA USA
Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFO4QjS9HxQb37XmcRApgKAJ9JxmTNiMF3qWjIyWqYVVhysdnHqQCgzFzB
Gg12/+mviMDqkuNrTpKfTOw=
=nrBp
-----END PGP SIGNATURE-----
cothrige
Hello Tim,
[snip]
> Then make your initrd if needed and tweak as needed, verify /etc/modules
> is what you want it to be and you should be good to go. Cross your
> fingers and reboot.
This makes me think. Recently I have gotten in the habit, after
installing the kernel and all the associated parts, of running
generate-modprobe.conf to get all the modules covered. But, it seems
that there is no modprobe.conf in Debian, and so I wonder if there is
a similar tool or method to generate the information covering the
modules? Before I ran this I would have to really hunt around to
cover the alsa stuff and so on, and so it was a nice shortcut.
Thanks a lot,
Gilles Mocellin
> * Tim Post (tim....@netkinetics.net) wrote:
>
> Hello Tim,
>
> [snip]
>
> > Then make your initrd if needed and tweak as needed, verify /etc/modules
> > is what you want it to be and you should be good to go. Cross your
> > fingers and reboot.
>
> This makes me think. Recently I have gotten in the habit, after
> installing the kernel and all the associated parts, of running
> generate-modprobe.conf to get all the modules covered. But, it seems
> that there is no modprobe.conf in Debian, and so I wonder if there is
> a similar tool or method to generate the information covering the
> modules? Before I ran this I would have to really hunt around to
> cover the alsa stuff and so on, and so it was a nice shortcut.
This modprobe.conf is modularized in several files (you can add one)
in /etc/modprobe.d/.
John O'Hagan
> * John O'Hagan (johno...@iprimus.com.au) wrote:
>>[snip summary of Debian kernel compilation]
> Will I still have to configure grub? And will update-grub work or
> will I have to manually edit menu.lst?
[...]
Installing the kernel-package generated by make-kpkg will automatically detect
and update grub, and add itself to menu.list. How easy is that?
Regards,
John
Tim Post
a successful build. Its really as easy as make, make modules_install ,
make install and a mkinitrd (if you need one).
If using GRUB, remember by default the selection menu is hidden. You'll
need to comment out the "hiddenmenu" line, and of course turn on pretty
colors.
/etc/modules is a newline delimited list of modules that are loaded at
boot time.
You can further tweak how modules are loaded by modifying your initrd
directly. You'll need to do this if you use things like AoE/iSCSI to
access the root file system you pass to your kernel (i.e.
root=/dev/etherd/e3.0) or any service that loads and unloads its own
modules to start / stop but must be on in order to boot. You shouldn't
need to unless you have a custom / unique setup, but here's how anyway -
Just mount it :
mkdir /tmp/initrd-mnt
modprobe loop
mount -o loop -t cramfs /boot/my.initrd-img.x.x.x /tmp/initrd-mnt
Then simply pico the file named "linuxrc", or edit the file containing
the list of modules. You'll see the modprobe lines loading modules, feel
free to add or detract :) This is really handy to get things like
AoE/iSCSI or cluster file systems going prior to mounting the root fs or
any other odd boot needs.
Just remember, linuxrc isn't smart, its mission is only to load modules
and pivot over to the root fs you specify... so make sure you add some
logic to deal with mod load failures if they happen (if you tinker, that
is).
Kernel hacking is quite a bit easier on GNU distributions (like Debian)
once you get used to the differences from whitebox / gentoo. Not saying
its not fun on those flavors, I just happen to really prefer GNU.
Many more comprehensive step by step kernel building tutorials are
easily found via Google .. this should be enough to get you going with a
degree of confidence however :)
HTH
Best,
-Tim
cothrige
> depmod should be called by the makefile upon make modules_install after
> a successful build. Its really as easy as make, make modules_install ,
> make install and a mkinitrd (if you need one).
>
> If using GRUB, remember by default the selection menu is hidden. You'll
> need to comment out the "hiddenmenu" line, and of course turn on pretty
> colors.
Okay, a touch of confusion on this. I am unfamiliar with grub, only
having started using it with this install of Debian and that having
been setup by the Debian installer. Right now the menu is not hidden,
but are you saying that a 'make install' of the kernel will add
hiddenmenu to my configuration? BTW, I have never used make install,
kinda scary I suppose, and so don't know much about it. Probably
won't use it now either, unless it is highly recommended.
> /etc/modules is a newline delimited list of modules that are loaded at
> boot time.
What is the difference between this and the modprobe.d files? I
notice that my system has both (alsa, nvidia and such in modprobe.d
and loop is all that is in modules). The man pages didn't seem to
clarify why both are needed.
> You can further tweak how modules are loaded by modifying your initrd
> directly.
[snip]
I have never used initrd, at least not when I have compiled a kernel.
To be entirely honest I have never fully understood just what it
does. I was under the impression it was for things like booting from
reiser fs and having to load modules to do it. However, that always
made me wonder why a person would just not compile in the reiser
support, and so I have naturally assumed that I was dead wrong on why
it existed and what it accomplished. But, since I have never seemed
to need it, i.e. my system has always booted fairly predictably
without it, I never tried to learn more.
> Kernel hacking is quite a bit easier on GNU distributions (like Debian)
> once you get used to the differences from whitebox / gentoo. Not saying
> its not fun on those flavors, I just happen to really prefer GNU.
I am going to open my mouth and prove my total ignorance, as I have
never even approached any kernel hacking. But, what is a 'whitebox'
and how is it different from GNU? I would have thought that Gentoo
was a GNU distro.
Many thanks,
cothrige
>
> Installing the kernel-package generated by make-kpkg will automatically detect
> and update grub, and add itself to menu.list. How easy is that?
Now that it is a nifty feature. I suppose there is certainly
something to be said for the Debian approach to this after all.
Patrick
cothrige
>
> This modprobe.conf is modularized in several files (you can add one)
> in /etc/modprobe.d/.
Ahh yes, I see that. I would think I could run
'generate-modprobe.conf > ~/modprobe.conf' and then split the info up
as I need it. Shouldn't be too impossible I would think.
Thanks,
Andrei Popescu
> I have never used initrd, at least not when I have compiled a kernel.
> To be entirely honest I have never fully understood just what it
> does. I was under the impression it was for things like booting from
> reiser fs and having to load modules to do it. However, that always
> made me wonder why a person would just not compile in the reiser
> support, and so I have naturally assumed that I was dead wrong on why
> it existed and what it accomplished. But, since I have never seemed
> to need it, i.e. my system has always booted fairly predictably
> without it, I never tried to learn more.
initrd's are especially useful for distros, because a kernel with all
stuff compiled in is not an option (too big), but you still need some
of the modules very early in the boot process, when the root filesystem
is not accessible yet. For your particular system you can afford to
compile everything in, because you know exactly what you need and what
you don't.
Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
Damon L. Chesser
Not just reiserfs but say if your hard drive type was a modual (ide,
sata, etc). Yes it is cleaner perhaps to hard code it in, but on the
other hand, if you miss one item in the chain, you get kernel panic. I
would suggest you install kernel-package and read the README in
/usr/share/doc/kernel-package . It has a rather complete walk through
on how to do it the debian way, including the initrd.
Make-kpkg will in fact make all the moduals, add them, and the kernel
and make a .deb you then use dpkg -i kernelname.deb to install, and
that will modify grub for you (or lilo I suspose). Comes in real handy
if you have more then one box with the same hardware, just transfer the
.deb and install it. Plus now your system knows it is installed and if
you use the make-kpgk --append-to=customename_or_number_here then apt
will not replace your kernel (unless you happen to name it something
that matches a apt-getable kernel. Real nice.
I hope that helps.
--
Damon L. Chesser
da...@damtek.com
da...@okfairtax.org
cothrige
>
> initrd's are especially useful for distros, because a kernel with all
> stuff compiled in is not an option (too big), but you still need some
> of the modules very early in the boot process, when the root filesystem
> is not accessible yet. For your particular system you can afford to
> compile everything in, because you know exactly what you need and what
> you don't.
That does make sense. I can see how it would make sense in that
situation. It should have occurred to me, but I suppose I was just
not taking the time to look at it from all sides. Thanks for the
clarification.
Patrick
Yura
kernel-source-2.6.11. Is it the newest?
Jameson C. Burt
Debian.
At least one comment should send up a warning:
if the approach becomes too intricate, or requires specialization,
very likely you read minute details that you should never need learn
(unless you're creating Debian packages).
Indeed, to follow such minute details would create configuration files
that would hinder later trying standard Debian approaches.
In particular, the standard Linux kernel package approach to installation from README in
every tar file from ftp.kernel.org
should become fewer steps under Debian.
To get the latest Linux kernels, you can still get your kernels from
ftp.kernel.org, although this may not seem as straight forward.
The Debian kernel packages are infrequently coordinated with another
package like an nvidia 3D XWindows driver.
I myself put ftp.kernel.org kernels in /usr/local/src/kernels,
since I run out of room in /usr/src
(EACH uncompressed kernel package takes 600MB -- almost 1GB).
In the past, you probably ran "make xconfig" or one of its equivalents
-- you can still do this before continuing with the standard Debian
approach.
Although, if you follow standard Debian
procedure with packages only, you get almost every module compiled so "make xconfig"
might become something you merely run and immediately exit.
With a previous Debian kernel package installed and running,
and with a new kernel, you probably want to coordinate
the options of the new kernel with your running kernel.
That is, you want to get a corresponding .config file,
so copy your running kernel's (uname -a) config file something like
cp /boot/config-2.6.17-2-486 .config
to the directory where your kernel package resides
(with a particular kernel setting, you once could find these in
/proc/config.gz, but I haven't seen these in a year).
Then, before any "make xconfig", run
make oldconfig
to which you probably select the "M" or module answer to most
questions, although some questions only allow yes/no.
When booting, some application with "apple" (probably looking for an apple network)
was hanging bootup for about 1 minute, so I eventually removed that from
the kernel.
It's surprising how many new options get added with each new kernel,
so "make oldconfig" can take 30 minutes, or even 2 hours if you go from a running
2.4.* kernel to a 2.6.18 kernel (then, you need to rethink all this).
I recently installed (largely the Debian way) kernel 2.6.18.1,
which isn't available in the current Debian testing version (etch)
and anything beyond 2.6.16 probably never will be in etch
since etch is being stabilized to become "stable" in the next few
months.
You are probably installing testing (etch), since stable is quite old
now, and its kernels are archaic.
When I compile my kernels, I always do something like
CONCURRENCY_LEVEL=2 make-kpkg --initrd --append-to-version \
'-jameson2-oldconfig' kernel-image
for 2 processors to finish more quickly, but with 1 processor you
might just run something like
make-kpkg --initrd --append-to-version '-jameson2-oldconfig' \
kernel-image
Each time, I sequentially change my name with a sequence number from
jameson2 to jameson3, jameson4, jameson5, ...,
so my modules go into a different directory
(modules get installed into their own directories like /lib/2.6.18.1-jameson2-oldconfig/)
This lets lets grub run my old kernels with their modules in their own
/lib/* directory.
Each such module directory uses about 50MB.
On compiling with --initrd, I finally drank the coolade last year.
Before, I tried to have no modules, compiling needed modules into the
kernel itself.
Since almost everyone now compiles oodles of modules, mostly uneeded,
but unknown uneeded, instructions now usually talk about modules.
As others in this thread have mentioned,
when booting, some necessary modules must be accessed right away,
so you are better off compiling with --initrd.
You mentioned NVidia.
I presume you have an Nvidia card with 3D acceleration.
Without using NVidia's binary driver, you will find XWindows using the
open-source "nv" WWindows driver,
and being slow even though you don't run games.
To install NVidia's driver, you either most use an older kernel
corresponding to Debian's packages that help with NVidia's binaries,
or you must run an NVidia executable.
I have tried both.
Since I use kernels newer than Debian has in testing (etch),
I go to nvidia.com, get NVidia's driver, then run it.
While getting an executable from nvidia.com directly worked well,
I noticed that it must have overwitten a few Debian installed files.
So when I upgrade Debian, I am prepared (but haven't seen)
for possible graphics oddities, in which case I would rerun nvidia.com's
executable to re-ovewrite those files.
You have heard from many of us, some complementing others information,
some giving non-Debian approaches, and you don't really know who to
listen to.
YOU NEED TO GO TO A DEBIAN DOCUMENT (which has more thought even than
these email-lists); eg,
"Compiling a New Kernel" at
http://www.debian.org/releases/stable/i386/ch08s05.html.en
which corresponds to
www.debian.org --> "installation manual"
--
Jameson C. Burt, NJ9L Fairfax, Virginia, USA
jam...@coost.com http://www.coost.com
(202) 690-0380 (work)
LTSP.org: magic "mysterious and awe-inspiring even though
we know they are real and not supernatural"
David A.
cothrige
> You have gotten a couple DIFFERENT approaches to installing a kernel on
> Debian.
> At least one comment should send up a warning:
> if the approach becomes too intricate, or requires specialization,
> very likely you read minute details that you should never need learn
> (unless you're creating Debian packages).
Yes, I am trying to avoid extremely involved approaches just so I
don't do things I won't know how to undo later. I always try to
understand just how I can backtrack after some action in order to
avoid real lasting irreparable damage. Eventually that was what
became of my foray into Gentoo, or at least partly, and I would hope
to avoid doing that again.
[...]
> It's surprising how many new options get added with each new kernel,
> so "make oldconfig" can take 30 minutes, or even 2 hours if you go from a running
> 2.4.* kernel to a 2.6.18 kernel (then, you need to rethink all this).
It has certainly surprised me, again and again. If I go any period at
all with a kernel, by the time I go back to recompile a new one I am
mired in reading trying to understand what all of these new options
do. This time I had a string of errors and then a kernel panic in the
process of hammering out what some of it out.
> I recently installed (largely the Debian way) kernel 2.6.18.1,
> which isn't available in the current Debian testing version (etch)
> and anything beyond 2.6.16 probably never will be in etch
> since etch is being stabilized to become "stable" in the next few
> months.
My install of etch has 2.6.17, so they must be moving pretty fast.
But, like you, I compiled the 2.6.18.1 today and it is running fine at this
time. Thanks to all the help I received from those such as yourself
here at this list.
[...]
> Each time, I sequentially change my name with a sequence number from
> jameson2 to jameson3, jameson4, jameson5, ...,
> so my modules go into a different directory
> (modules get installed into their own directories like /lib/2.6.18.1-jameson2-oldconfig/)
> This lets lets grub run my old kernels with their modules in their own
> /lib/* directory.
> Each such module directory uses about 50MB.
Many thanks for this tip. Since my new kernel was different from the
previous, I upgraded from 2.6.17 to 2.6.18, I did not need to worry
about that. But, it will be very handy when I need to compile again
and don't want to clobber all of my modules. This is the second very
useful tip in that area I have read on this list.
> On compiling with --initrd, I finally drank the coolade last year.
> Before, I tried to have no modules, compiling needed modules into the
> kernel itself.
> Since almost everyone now compiles oodles of modules, mostly uneeded,
> but unknown uneeded, instructions now usually talk about modules.
> As others in this thread have mentioned,
> when booting, some necessary modules must be accessed right away,
> so you are better off compiling with --initrd.
Or you could use my method mentioned above, and just wait for kernel
panics. ;-) I actually did manage to have a fairly modular kernel with
those absolute necessities builtin. And because the old kernel and
modules are still on board if something fatal does go wrong at least I
can go back and begin again. Or, I hope I can.
> You mentioned NVidia.
> I presume you have an Nvidia card with 3D acceleration.
> Without using NVidia's binary driver, you will find XWindows using the
> open-source "nv" WWindows driver,
> and being slow even though you don't run games.
> To install NVidia's driver, you either most use an older kernel
> corresponding to Debian's packages that help with NVidia's binaries,
> or you must run an NVidia executable.
> I have tried both.
> Since I use kernels newer than Debian has in testing (etch),
> I go to nvidia.com, get NVidia's driver, then run it.
I actually did this with the Debian kernel. It is always what I did
with Slack and so I am used to it. I had installed Ubuntu a couple of
weeks ago, (no offense to the Ubuntu folks but I wasn't crazy about
it), and I worked the better part of two days trying to get my nvidia
card working. I read page after page of howtos and fora or list
messages, and none agreed on how to do it, except that you would hose
your system if you used the drivers from nvidia. Well, I hosed the
system doing it the "ubuntu" way, because just as I try to avoid I
ended up doing things I didn't understand and so could not undo. One
error stacked up on another and pretty soon it was bye-bye Ubuntu.
With this install of Debian I decided to stick to what I know, and
grabbed the binary installer direct from NVidia. I ran that, and in
less than two minutes I was up and running. No complaints from Debian
and no complaints from NVidia. Oh, except for one because I had tried
to compile it before I updated the system fully and so I had a gcc
which didn't match the kernel, but that was fixed in no time.
> While getting an executable from nvidia.com directly worked well,
> I noticed that it must have overwitten a few Debian installed files.
> So when I upgrade Debian, I am prepared (but haven't seen)
> for possible graphics oddities, in which case I would rerun nvidia.com's
> executable to re-ovewrite those files.
Exactly what I have planned to do in the case there is a problem.
But, so far, there hasn't been one. And perhaps that will remain the
case.
> You have heard from many of us, some complementing others information,
> some giving non-Debian approaches, and you don't really know who to
> listen to.
> YOU NEED TO GO TO A DEBIAN DOCUMENT (which has more thought even than
> these email-lists); eg,
> "Compiling a New Kernel" at
> http://www.debian.org/releases/stable/i386/ch08s05.html.en
> which corresponds to
> www.debian.org --> "installation manual"
Many thanks for the info and the links. I will go and see what they
say, for future reference. I am sure that there are immense loads of
info out there, and I have tried to glean what I can before troubling
the list. Though, I do have to compliment this list in general for
being one of the most generous I have ever had the good fortune to
interact with. The reputation which preceded Debian users was that of
an arrogant lot with keyboard shortcuts to type RTFM with one stroke.
But, this has been the opposite of my experience reading and posting
here. If this list is any indication of the Debian user community in
general, it is certainly one of the finest.
Many thanks again for all the help, and I will be sure to read the
info at the links you included.
Patrick
Michael D. Norwick
>You have gotten a couple DIFFERENT approaches to installing a kernel on
Debian.
>At least one comment should send up a warning:
Yes, a level-minded user.
>On compiling with --initrd, I finally drank the coolade last year.
Before I tried to have no
>modules, compiling needed modules into the kernel itself. Since
everyone now compiles
>oodles of modules, mostly uneeded, but, unknown uneeded, instructions
now usually talk
>about modules. As others in this thread have mentioned.
I just finally succumbed to the Jim Jones thing in the last couple of
days after years of
building non-initrd kernels on Debian due to a strong dislike of devfs.
I do not know if it
is intentional on the part of the Debian development team to force
initrd on the population,
but, I have found it quite difficult, and very time consuming, trying to
build and boot a non-
initrd kernel from the 2.6.1x series. No need for the rtfm/google is
your friend' stuff I have
most of the current Debian docs from packages, self edited
OpenOffice.org libraries, and
web picked pdf's.
All I wanted was to locally build a trusted 2.6.18 series kernel with
CITI_NFS4 patches.
After several build iterations on a -rc6 source tree. The one that
finally booted without a
'kernel panic: vfs: error root fileysystem not found' error, was a
'make-kpkg --initrd'
build.
Per usual, the alsa system still won't greet me when KDE starts, though
all the modules are
loaded, but this thing runs as a kerberos slave with our ldap database
replicated to it. So
sound sucks, and I guess I don't need it (more like, I don't have time
to screw with it).
I guess while I'm ranting; Linux was promoted years ago as being able
to run on outdated
hardware. My budget does not allow me to purchase the latest hardware
pushed down to
us by Intel, AMD, and MS, every millisecond. But it sure seems like Linux
(all distributions) and the 'BSD's for that matter, have developed a
preference for
recent (within the last three years) hardware. Maybe I'm confusing
'able' and 'useable'.
Oh well, I think there might be something for me in 'man kernel-img.conf'.
Michael
Chris Bannister
> With this install of Debian I decided to stick to what I know, and
> grabbed the binary installer direct from NVidia. I ran that, and in
> less than two minutes I was up and running. No complaints from Debian
> and no complaints from NVidia. Oh, except for one because I had tried
> to compile it before I updated the system fully and so I had a gcc
> which didn't match the kernel, but that was fixed in no time.
Apparently the binary installer from NVidia messes with the libraries on
the system and is not the recommended method for installing.
Read http://home.comcast.net/~andrex/Debian-nVidia/
The Debian way is certainly a lot easier. Now where has that nvidia-glx
package gone?
--
Chris.
======
" ... the official version cannot be abandoned because the implication of
rejecting it is far too disturbing: that we are subject to a government
conspiracy of `X-Files' proportions and insidiousness."
Letter to the LA Times Magazine, September 18, 2005.
cothrige
>
> Apparently the binary installer from NVidia messes with the libraries on
> the system and is not the recommended method for installing.
>
> Read http://home.comcast.net/~andrex/Debian-nVidia/
>
> The Debian way is certainly a lot easier. Now where has that nvidia-glx
> package gone?
>
Well, that is exactly the problem. I tried several times initially to
install it via apt but it could never do it. IIRC, there was no
nvidia-glx package and so it would not install. This was a test of an
installation BTW which ended up being only temporary. When I finally
committed and gave over my main partition to Debian I decided to
simply try it the old fashioned way and see how it went. So far so
good, though I expect that may change at any time. Many thanks for
the howto though. The next time I compile a kernel I will try it the
Debian way, just to see how I perhaps messed up the first time.
Patrick
David Baron
> On Mon, Oct 23, 2006 at 11:31:46PM -0500, cothrige wrote:
> > With this install of Debian I decided to stick to what I know, and
> > grabbed the binary installer direct from NVidia. I ran that, and in
> > less than two minutes I was up and running. No complaints from Debian
> > and no complaints from NVidia. Oh, except for one because I had tried
> > to compile it before I updated the system fully and so I had a gcc
> > which didn't match the kernel, but that was fixed in no time.
>
> Apparently the binary installer from NVidia messes with the libraries on
> the system and is not the recommended method for installing.
>
> Read http://home.comcast.net/~andrex/Debian-nVidia/
>
> The Debian way is certainly a lot easier. Now where has that nvidia-glx
> package gone?
Nvidia's own gives me twice the frame rate of Debian's nvidia-glx (Sid).
Nvidia is looking for some Xorg SDK to tell it where to place its module. Not
finding that, it uses the default /usr/lib which means interference with/by
xorg glx packages. Each time you put in new Xorg stuff, simply rerun their
installer. A bit of a bother but as you said, a few minutes.
Examin their "advanced" options. There may be a way to tell it where to
install the glx stuff. Then simply have xorg.conf check modules there
first :-)
Alan Ianson
When I (cough) installed nvidia's own installer I installed xorg-dev first so
it could figure out where to put stuff. I'm running with an m-a installed
module now and am having good results. Wish I had checked the frame rate but
it seems to be working well in any case.