Re: Warning: Latest Kernel Sources on Sid
On Monday 08 May 2006 21:33, Greg Folkert wrote:
> On Mon, 2006-05-08 at 18:22 +0300, David Baron wrote:
> > On Monday 08 May 2006 18:11, Greg Folkert wrote:
> > > On Mon, 2006-05-08 at 17:36 +0300, David Baron wrote:
> > > > On Monday 08 May 2006 17:10, Greg Folkert wrote:
> > > > > On Mon, 2006-05-08 at 16:04 +0300, David Baron wrote:
> > > > > > On Sunday 07 May 2006 23:17, H.S. wrote:
> > > > > > > David Baron wrote:
> > > > > > > > You may get the following on modules previously compiled
> > > > > > > > against kernel sources:
> > > > > > > >
> > > > > > > > Kqemu and Nvidia's driver were hit by this. Easy enough to
> > > > > > > > fix--recompile 'em.
> > > > > > >
> > > > > > > I noticed this too. I am using nvidia module. I just did (after
> > > > > > > booting in the new kernel version):
> > > > > > > #> m-a auto-install nvidia
> > > > > > >
> > > > > > > and it seemed to have done the trick.
> > > > > >
> > > > > > The Nvidia driver I downloaded from Nvidia comes with its own
> > > > > > .run file which does more than simply check and recompile the
> > > > > > driver (too much actually for a repeat compile!). Would m-a
> > > > > > "know" to run this?
> > > > > >
> > > > > > Other modules need to be made with various arguments pointing to
> > > > > > kernel source directory, etc.
> > > > >
> > > > > m-a == Debian's Module Assistant.
> > > > >
> > > > > Yes, it will get the stuff proper for the driver.
> > > > >
> > > > > Now the library links are taken care of by the nvidia-glx and
> > > > > nvidia-glx-dev packages.
> > > >
> > > > Neither module effected was from a Debian package, however.
> > > > Kqemu is "non-free" and made from source.
> > > > The nvidia videa driver was downloaded from their site and as I said,
> > > > it has its own installation program. (What is the difference between
> > > > what is on Debian and theirs?)
> > >
> > > The Debian nVidia is a much easier and more updateable version. And you
> > > get an integrated package for Debian for the drivers. ATIs stuff is
> > > there too. Plus TONS of other modules, like wifi, crypto etc... ta
> > > boot.
> >
> > ATI stuff was why I went over to the Geforce.
>
> I was just commenting that IF they can get ATIs crap to work properly
> using m-a... you might consider using it.
>
> I used to run a script I developed myself, to do everything exactly like
> M-A does. When I explained what my script did... well an m-a maintainer
> mentioned that Debian does it with many modules.
>
> > > How long does it take for you to run your installer and get the proper
> > > kernel compiled and/or then the proper headers for the nVidia module to
> > > compile against, how many steps are there?
> >
> > Their installer is simple: run it with root privileges.
> > 1. Checks for precompiled version on their ftp.
> > 2. None? Compiles it
> > 3. Places it in ..../drivers/video
> > 4. Will modify xorg.conf to use this driver. Saves old file just in case
> > 5. Voile.
>
> The point is though:
>
> This was the nVidia Modules and packages, are maintained and
> kept track of by debconf. You don't have to re-run you installer
> *JUST* to get the libc links back (should libc get updated) and
> any real problems, are typically caught before the go into
> incoming.
>
> I remember last year or, nVidia updated the drivers and the installer
> literally removed half of you libraries on your system. That was caught
> by the nVidia package(s) maintainer(s) and never ruined any machine
> except maybe the chroot environment.
>
> > > Are you putting the module where it should go, according to Debian's
> > > policy? If not, then you will always have cruft building up. Plus
> > > you'll no longer have to worry if the installer puts the links in the
> > > proper directories for the video libraries... and the recent changes to
> > > X.org have also been included in compilation of the nVidia Module.
> > > (hint: apt-get install module-assistant)
> >
> > I have it.
> >
> > > Using module-assistant (m-a is a shortname for module-assistant) for
> > > the *CURRENT* Kernel you are running doing:
> > >
> > > m-a update ; m-a a-i nvidia
> > >
> > > Does the update, install of everything needed and compiles and installs
> > > the resulting deb package file.
> > >
> > > Of course, the nvidia-glx and the nvidia-glx-dev will need to be
> > > installed too.
> >
> > Are all these kept more up-to-date and better running than the
> > manufacturer's module? I have heard recommendations for both sides of
> > this.
>
> All I can tell you, since I deprecated my script and switched to m-a, my
> life has been much easier. Upgrades on nVidia versions are trival. Now
> there is something else you should know, there is a Legacy version of
> the nvidia source and glx packages... these are for GF2 and before
> cards... that was a rude awakening (which was also when I started my own
> script)
>
> > > kqemu, isn't a kernel module... I am sorry I mislead you in any way on
> > > that.
> >
> > kqemu IS a kernel module, .ko. Needs be compiled against kernel source
> > and installed in .../drivers/misc.
>
> Are we talking the same package? http://kqemu.sourceforge.net/
>
> Which runs QEmu inside of it?
>
> http://packages.debian.org/unstable/misc/qemu
>
> And it does NOT need to be compiled against the Kernel SOURCE.
There are two kqemus. One is the kernel module to speed up qemu. The other one
is a KDE Kommander shell for running qemu. One of these names needs be
changed :-)
>
> The "kernel-headers-2.6-<arch>" or "smp" added is all the you need. Same
> goes for the nVidia drivers. They only need the Kernel Headers. No need
> to compile your own kernel. There is really no reason to compile your
> own kernel. Not even to compile *IN* modules for you exact hardware.
>
> I stopped doing new kernels all the time when the 2.6 tree popped up in
> Debian. Everything I was patching into the 2.4 kernel (using make-kpkg)
> was already in the 2.6 tree.
>
> The kernel is equivalently fast in mono or module modes. (I can
> guarantee you'll *NEVER* be able to tell if it is faster or not) I have
> been using Debian for quite a few years, in fact I am using an "8 year
> old build" right now on an Athlon64 3500+, I just keep transferring the
> image around and around and around. You could never do that with a
> hard-compiled kernel.
>
> Debian is all about EASE of maintenance, not making it hard to keep
> things updated. It is why I keep coming back to Debian (and UBUNTU for
> my friends and cow-orkers), its all about maint.
I compile the kernel because the stock kernels no loner support realtime-lsm
out of the box and because the newer initrd tools simply did not work on the
installs. My compiled kernel needs no initrd. SO I figured while I am at it,
to get rid of extra modules. No harm keeping them though.
Reply to: