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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
