Re: Kernel Headers for 2.6.11
On 9/20/05, Zaq Rizer [EMAIL PROTECTED] wrote: Sorry to sort of butt in here, but I've been trying to get my nvidia drivers fixed for some time now and am stuck at a certain point. Hoping you can point me in the same direction you took, since you recently got your setup working. To be honest I'm not completely sure what you are doing. I just followed the directions from http://home.comcast.net/~andrex/Debian-nVidia/ going the Debian way using module-assistant. I used the stock 2.6.12 debian kernel and it all worked without a hitch. Then I updated the X server configurations The Debian way (with dpkg-reconfigure) except I'm running xorg instead of xfree86. Parts 3b,3c I didn't even have to do since I already had a GUI going it was just using VGA @ 640x480 so 3b was done and I tried 3c by rebooting instead (the lazy way out, but it works). The one thing to keep in mind, which you can probably skip with some appropriate command line flags that I don't know, is that when doing the module-assistant thing you need to be running the kernel that you are trying to build the module for. Aethon
Re: Segfaults as non-root user
Wiping out my zshrc fixed the ls bug, however, the dpkg-buildpkg error still remains. In dmesg: dpkg-parsechang[19135]: segfault at 00f0 rip 2b7922bb rsp 7fde93d0 error 4 -John On Tue, Sep 20, 2005 at 10:13:25AM -0700, John C. McCullough wrote: I recently installed the amd64 port onto an intel EM64t SMP machine. I am running the 2.6.12.6 kernel. The same issue occurs using the debian-packaged 2.6.11-em64t-p4-smp kernel. I cannot test on the 2.6.13 kernel due to a driver issue in the raid controler. The system was installed using a slightly modified unstable cd image and then packages from the testing branch were installed. The raid board on the machine is not supported until the 2.6.11 kernel and I was having difficulty getting a kernel satisfying that onto a testing installation cd. So far, I have found a few programs that segfault, particularly zsh and dpkg-buildpkg when run as a non-root user. They behave normally when run as root. In zsh the problem appears as: ~ % cd /tmp/test /tmp/test % ls -la /tmp/test total 12 drwx--x--x 3 john john 4096 2005-09-20 09:55 . drwxrwxrwt 7 root root 4096 2005-09-20 09:54 .. drwx-x 3 john john 4096 2005-09-20 09:55 pkgs /tmp/test % /tmp/test % cd pkgs /tmp/test/pkgs % ls zsh: 4707 segmentation fault ls /tmp/test/pkgs % And any attempts to execute commands elsewhere results in a segmentation fault. However, if the full path is used, the segfault does not occur: ~ % cd /tmp/test/pkgs /tmp/test/pkgs % ls -la total 6516 drwx-x 3 john john4096 2005-09-20 09:55 . drwx--x--x 3 john john4096 2005-09-20 09:55 .. drwx--x--x 18 john john4096 2005-09-20 09:54 zsh-4.2.5 -rw--- 1 john john1468 2005-09-20 09:54 zsh_4.2.5-19_amd64.changes -rw--- 1 john john 2119662 2005-09-20 09:54 zsh_4.2.5-19_amd64.deb -rw--- 1 john john 338405 2005-09-20 09:54 zsh_4.2.5-19.diff.gz -rw--- 1 john john 675 2005-09-20 09:54 zsh_4.2.5-19.dsc -rw--- 1 john john 2624122 2005-09-20 09:54 zsh_4.2.5.orig.tar.gz -rw--- 1 john john 672170 2005-09-20 09:54 zsh-doc_4.2.5-19_all.deb -rw--- 1 john john 865214 2005-09-20 09:54 zsh-static_4.2.5-19_amd64.deb /tmp/test/pkgs % This only seems to occur in specific directories, though I have not yet determined whath distinguishes them from others (/usr/local/bin is fine though /usr/local/lib/site_perl isn't). The problem is not limited to zsh, though I haven't done a complete test of all programs for example (running from tcsh): /tmp/test/pkgs/zsh-4.2.5 dpkg-buildpackage dpkg-parsechangelog: failure: tail of debian/changelog died from signal 11 dpkg-buildpackage: unable to determine source package is Running as root, or through sudo, is sucessful. The same with zsh and the change directory issue. Has anyone experienced this before who can offer some help? The likely course of action for me is to go back to the 32-bit debian or to try another 64bit distribution. However, I am willing to try to diagnose this for a little while. Thanks, John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: remove unwanted modules
On Wed, Sep 21, 2005 at 12:24:06AM -0500, Marc DM wrote: Stupid questions : How can I find out which modules my system actually needs and disable the ones I don't need. How can I know if a module I'm disabling at startup isn't needed for another module that I plan to load? Thanks. And I won't ask anymore stupid questions for the rest of the week. You can check the use count from lsmod: Module Size Used by nls_utf82432 0 it87 29472 0 i2c_sensor 3712 1 it87 i2c_isa 2688 0 i2c_dev12288 0 powernow_k811088 0 freq_table 5192 1 powernow_k8 ^ This column If the count is 0, it means the module is not being used, either because the device it supplies isn't currently being used, or because you don't need it. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Segfaults as non-root user
* John C. McCullough [EMAIL PROTECTED] [2005-09-21 09:55]: Wiping out my zshrc fixed the ls bug, however, the dpkg-buildpkg error still remains. In dmesg: dpkg-parsechang[19135]: segfault at 00f0 rip 2b7922bb rsp 7fde93d0 error 4 looks like the bug I've seen on my system with random programs, too. Just look here: http://lkml.org/lkml/2005/6/15/241 http://forums.gentoo.org/viewtopic-t-360230.html -John Jochen -- diesen tag / begehen / wie einen grund / oder wie ein fest ohne grund zu einem fest / ohne festen grund -- Ernst Jandl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Headers for 2.6.11
On Tue, Sep 20, 2005 at 10:51:57PM -0400, Zaq Rizer wrote: Sorry to sort of butt in here, but I've been trying to get my nvidia drivers fixed for some time now and am stuck at a certain point. Hoping you can point me in the same direction you took, since you recently got your setup working. Steps I have taken thus far: Following Adam Majer's instructions, which are roughly 1) Get the latest nvidia-graphics-drivers package files from experimental 2) dpkg-source -x nvidia-graphics-drivers_1.0.7667-3.dsc cd nvidia-graphics-drivers* fakeroot dpkg-buildpackage 3) [This part I might have mucked up] -- Use the old instructions for building the custom nvidia-kernel module as per the AMD64 HOWTO available at [https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id272586] But it's during this step #3, which Adam also recommended, applying [MAKEFLAGS=CC=gcc-3.4 make-kpkg --append-to-version -1-amd64-k8 modules_image (from within /usr/src/linux-headers-2.6.12-1-amd64-k8] that I get the following error: make[1]: Entering directory `/usr/src/linux-headers-2.6.12-1-amd64-k8' scripts/Makefile.build:13: scripts/basic/Makefile: No such file or directory make[2]: *** No rule to make target `scripts/basic/Makefile'. Stop. make[1]: *** [scripts_basic] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.12-1-amd64-k8' make: *** [stamp-kernel-configure] Error 2 Naturally, attempting to install the nvidia-glx, et al, packages fails because I need nvidia-kernel-1.0.7676. Any help you or Adam Majer can provide is greatly appreciated. Well for me compiling has worked just fine when I use module assistant (and have gcc-4.0 installed since that is what the debian 2.6.12 kernels use and hence require, unless you rebuilt it with 3.4 or someone else did). apt-get install gcc-4.0 (just in case you didn't already) m-a -t prepare (sets up kernel headers and build essentials and such) m-a a-i -t nvidia (builds and installs the module and it's dependancies) Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Headers for 2.6.11
On 9/21/05, Zaq Rizer [EMAIL PROTECTED] wrote: On Wed, 2005-09-21 at 01:10 -0500, Aethon wrote: On 9/20/05, Zaq Rizer [EMAIL PROTECTED] wrote: Sorry to sort of butt in here, but I've been trying to get my nvidia drivers fixed for some time now and am stuck at a certain point. Hoping you can point me in the same direction you took, since you recently got your setup working. To be honest I'm not completely sure what you are doing. I just followed the directions from http://home.comcast.net/~andrex/Debian-nVidia/ going the Debian way using module-assistant. I used the stock 2.6.12 debian kernel and it all worked without a hitch. So you're running the 7174 version of the nvidia module? I was under the impression you were running the most recent. I'm just running the 7174 version. It works just fine, so I'm not going to try to fix something that isn't broken. Aethon
New Install works great! My experience.
I spend a lot of time trying to figure out if I should try 64bit. For those of you searching. I installed amd64 stable and upgraded to unstable. Everything works great! Good job to the AMD64 team! The only snag I hit was udev. udev wanted 2.6.12 or higher, though it didn't show up as a dependency. However I didn't have that, and didn't know until half gnome was installed. Not sure if there was a better way, but I just removed udev and all the broken packages it brought with it. Then put on the new 2.6.12 kernel and viola! the latest mkisofs also caused a seg fault. I moved to the version just prior to that and works fine. Epiphany works fine. Evolution, well I'm using it now. totem gstreamer plays mp3s, mpegs, dvd no prob. rt2500 works great. nforce4 and 6600gt work great. Nvidia driver install was a snap (built using deb packages) now I just need to get ut2004 working. MD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: remove unwanted modules
On Wednesday 21 September 2005 12:53 am, Hamish Moffatt wrote: On Wed, Sep 21, 2005 at 12:24:06AM -0500, Marc DM wrote: Stupid questions : How can I find out which modules my system actually needs and disable the ones I don't need. How can I know if a module I'm disabling at startup isn't needed for another module that I plan to load? Thanks. And I won't ask anymore stupid questions for the rest of the week. You can check the use count from lsmod: Module Size Used by nls_utf82432 0 it87 29472 0 i2c_sensor 3712 1 it87 i2c_isa 2688 0 i2c_dev12288 0 powernow_k811088 0 freq_table 5192 1 powernow_k8 ^ This column If the count is 0, it means the module is not being used, either because the device it supplies isn't currently being used, or because you don't need it. Or with regards to the modules loaded in the initrd, change /etc/mkinitrd/mkinitrd.conf to have the line MODULES=dep instead of =[all,most] and then regenerate the initrd. That's what I've done anyway and it works great. One issue with newer kernels is that is seems to load all IDE drivers regardless since they aren't yet tagged as unloadable (shows [permanent] in lsmod). How can one indicate to initrd (or yaird) selectively which ide modules to load? Joel Johnson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
nvidia + openGL + java
I am trying to get jogl, the openGL for java extension, working. Since it requires a native file (jogl.so) which I can only find for x86, I am working in a 32 bit chroot. When I ran an example, it crashed giving a segfault in the libGL.so file. This was currently provided by nvidia-glx so I removed it and the program ran fine (without hardware acceleration I expect). I compiled my own nvidia-glx package (version 7174) using standard apt-get source --compile but the same error occurs I am guessing this is a bug in the nvidia libGL file but I have only experienced the error in 32-bit, so maybe this is the wrong place to post. Has anyone had success compiling/using jogl on amd64/know where I can get source for this so I can test in 64bit mode? Many thanks Hugh Here is the error I get when running: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x5c35baba, pid=5634, tid=1558608816 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode, sharing) # Problematic frame: # C [libGL.so.1+0x2caba] # # An error report file with more information is saved as hs_err_pid5634.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Headers for 2.6.11
On Wed, Sep 21, 2005 at 08:41:44AM -0400, Zaq Rizer wrote: Wow ... I don't understand why that worked, but it worked. I'll look into the how and why later. Thanks so much, Len! Should I follow a similar method to update my nvidia-glx package in my 32bit chroot or can I just install the experimental i386 debs for this? install the matching nvidia-glx in the chroot. I don't know if the chroot will have issues with not seeing the kernel modules package inside the chroot, even though it doesn't actually need it. I suppose you could just install it in the chroot to, or use a meta package (I forget what tool can make those) to pretend to have what it wants installed inside the chroot. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#329355: Kernels compiled from kernel-source-2.4.27 can't boot on x86_64.
Hello, the amd64 port does not support 2.4 kernels, and there are no plans top change this. During the initial porting, We wanted NPTL and TLS support in libc6 in the first place, and considering the rudimentary support x86_64 had in 2.4 kernels at that time (this might have changed in the meantime, I did not look at 2.4 kernels for ages) we choose to just drop compatibility. I suggest we close this bug, or set it at least to wontfix, since etch will likely release without any 2.4 kernel on most architectures. On Wed, Sep 21, 2005 at 01:39:18PM +0300, Nikos Ntarmos wrote: Debian Release: 3.1 Architecture: amd64 (x86_64) Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: remove unwanted modules
On Wed, Sep 21, 2005 at 10:22:00AM -0500, Mike Dobbs wrote: to not add eth1394 I added this line into /etc/modprobe.conf : install eth1394 /bin/true If you create /etc/modprobe.conf you disable the use of /etc/modprobe.d which is what debian uses. This is not a good idea. Make your changes in a new file under /etc/modprobe.d instead. Also the common way that I know of ti disable someting is to either blacklist it from discover/hotplug (so you can still load it manually if you want to), or do 'alias eth1394 off' in a modprobe.d/ file. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: remove unwanted modules
On Wed, Sep 21, 2005 at 11:16:48AM -0700, Joel Johnson wrote: But that still doesn't get to the issue of how mkinitrd decides which IDE modules should be included when set to only include dependent modules. Any insights? That would be controlled by mkinitrd's config. You can actually manually list excactly which modules to load if you want. You can also write a new better mkinitrd if you want (yaird is one other option for example) and it sounds like mkinitrd may need replacing anyhow for initramfs and no devfs in 2.6.13 for some setups in the future. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: remove unwanted modules
You can check the use count from lsmod: Module Size Used by nls_utf82432 0 it87 29472 0 i2c_sensor 3712 1 it87 i2c_isa 2688 0 i2c_dev12288 0 powernow_k811088 0 freq_table 5192 1 powernow_k8 ^ This column If the count is 0, it means the module is not being used, either because the device it supplies isn't currently being used, or because you don't need it. This is useful info. Thanks. Or with regards to the modules loaded in the initrd, change /etc/mkinitrd/mkinitrd.conf to have the line MODULES=dep instead of =[all,most] and then regenerate the initrd. I actually had to do this on a Tyan Thunder K8W (S2885) in order to get it to mount /home on the sata controller at boot (LVM over Raid1). It would always complain of not being able to find any md devices when loading lvm. I think this is because the sil3114 module was being loaded by hotplug later on in the boot process, long after disks are mounted. to not add eth1394 I added this line into /etc/modprobe.conf : install eth1394 /bin/true I try to stay away from modprobe.conf because of the commemts at the top of the file, so I'm working with modutils.d and mkinitrd.conf Marc DM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Headers for 2.6.11
In a chroot, you still need nvidia-kernel-foo in order to install the nvidia-glx package. I've created an i386 .deb of nvidia-glx and nvidia-kernel-source, and, you're right, the -glx package requires an i386 nvidia-kernel-7676.deb ... Look into 'equivs', to generate an nvidia-kernel package to suit yoru needs, and allow nvidia-glx to install. No idea how to make this work ... is it as difficult as it seems? Plus, doesn't the nvidia-glx-ia32_1.0.7676-1_amd64.deb package provide the necessary libs to satisfy OpenGL-wanting applications within the sid-ia32 chroot to operate? They're placed in /emul ... can I copy them to the chroot's /usr/lib directory? Thanks SO MUCH for your help. :) Zaq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 sources.list file
okay... I think I now have figured out why the system refuses to install amd64 packages, perferring the i386 packages: it still thinks it's an i386 system. So, I spent about 3 hours hunting down where I could change what the system thinks of itself, and found nothing. Basically, I need to change the system such that it will install the amd64 packages instead of the i386 ones (all the errors were apparently b/c the amd64 mirrors didn't have a package list for i386 packages, which was what apt and kynaptic and kpackage were all looking for (I think through dpackage, but I'm still not sure...)) So, does anyone know what to do? I'm pretty much stumped myself, so any input, even a pointer to a file I should su root / nano would be great. Thanks for listening to my pathetic newbie problems, and have a great day!
Re: remove unwanted modules
You can check the use count from lsmod: Module Size Used by nls_utf82432 0 it87 29472 0 i2c_sensor 3712 1 it87 i2c_isa 2688 0 i2c_dev12288 0 powernow_k811088 0 freq_table 5192 1 powernow_k8 ^ This column If the count is 0, it means the module is not being used, either because the device it supplies isn't currently being used, or because you don't need it. This is useful info. Thanks. Or with regards to the modules loaded in the initrd, change /etc/mkinitrd/mkinitrd.conf to have the line MODULES=dep instead of =[all,most] and then regenerate the initrd. I actually had to do this on a Tyan Thunder K8W (S2885) in order to get it to mount /home on the sata controller at boot (LVM over Raid1). It would always complain of not being able to find any md devices when loading lvm. I think this is because the sil3114 module was being loaded by hotplug later on in the boot process, long after disks are mounted. to not add eth1394 I added this line into /etc/modprobe.conf : install eth1394 /bin/true I try to stay away from modprobe.conf because of the commemts at the top of the file, so I'm working with modutils.d and mkinitrd.conf Marc DM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amaroK: No engine works
--- Johannes Klug [EMAIL PROTECTED] wrote: Am I the only one having problems with amaroK? Sometimes it crashes after selecting an engine, sometimes it appears to hang, and it does not play a single note all of the time. No, you're not the only one. My amarok has been giving me grief as well. I used to use the xine engine, which worked like a dream, now that's entirely broken and I must use the gstreamer engine, which, imo, is dreadfully slow. Track changes take a few seconds. Any advice for me? Here's the best I can do, as I'm also a bit confused by amarok's wretched behavior: QUICK SOLUTION: killall amarokapp rm ~/.kde/share/config/amarokrc rm -rf ~/.kde/share/apps/amarok restart amarok -- set the engines as you wish. repeat until you find an engine that works. SAFE SOLUTION: killall amarokapp then, some ideas - modify ~/.kde/share/config/amarokrc to use another engine, keep trying other options until you find one that works. strace amarok -- watch debugging output (wasn't very helpful for me, but it's a thought) rm ~/.kde/share/apps/amarok/xine-config I had to do this a few times, as the xine config was corrupt (or something) causing amarok to bomb. HTH Thank you! Johannes You're welcome. Zaq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nvidia + openGL + java
--- Hugh Waite [EMAIL PROTECTED] wrote: When I ran an example, it crashed giving a segfault in the libGL.so file. This was currently provided by nvidia-glx so I removed it and the program ran fine (without hardware acceleration I expect). I compiled my own nvidia-glx package (version 7174) using standard apt-get source --compile but the same error occurs Have you tried any other OpenGL applications within your chroot? If glxgears or some-such application also gives a segfault, you can be certain there's some problem with the nvidia-glx package you installed. Otherwise, maybe it's specific to the jogl? Just a thought. Also, perhaps try stracing the segfault. Zaq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Headers for 2.6.11
On Wed, Sep 21, 2005 at 12:15:17PM -0700, Zachary Rizer wrote: I've created an i386 .deb of nvidia-glx and nvidia-kernel-source, and, you're right, the -glx package requires an i386 nvidia-kernel-7676.deb ... No idea how to make this work ... is it as difficult as it seems? Plus, doesn't the nvidia-glx-ia32_1.0.7676-1_amd64.deb package provide the necessary libs to satisfy OpenGL-wanting applications within the sid-ia32 chroot to operate? They're placed in /emul ... can I copy them to the chroot's /usr/lib directory? Requirements for libs yes, but won't make the package system happy. Using the equivs package means you can install the proper i386 nvidia-glx package in the chroot, without having to build an i386 kernel package as well, since the equivs package will provide the dependancy it needs. ie: /tmp/nvidia-kernel-equivs.control: Section: misc Priority: optional Standards-Version: 3.5.10 Package: nvidia-kernel-equivs Version: 1.0.7174 Maintainer: Len Sorensen [EMAIL PROTECTED] Provides: nvidia-kernel-1.0.7174 Architecture: all Description: Fake package for nvidia-kernel-modules Fake package to satisfy nvidia-glx dependancies for chroot use. debdev1:~# equivs-build /tmp/nvidia-kernel-equivs.controlA stuff happens Out comes: nvidia-kernel-equivs_1.0.7174_all.deb Install with dpkg -i and you satisfy the requirements of the chroot to then install nvidia-glx. Change names and version numbers to match your needs. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Ocfs2-Tools on Debian Sarge (AMD64)
Hello, the official package ocfs2-tools is not available for Sarge ; and the oracle's package is only for i386 platform. So I try to compile from sources (I had to install some packages like e2fslibs-dev, uuid-dev, and pkg-config). But I have a lot of errors. How can I do to have ocfs2-tools ? Have I to change to the testing distribution ? Here some of the errors : extent.c: In function `check_eb': extent.c:86: attention : format long unsigned int, arg __le64 (arg 5) include/main.h:52:18: glib.h : Aucun fichier ou répertoire de ce type include/main.h:54:31: readline/readline.h : Aucun fichier ou répertoire de ce type include/main.h:55:30: readline/history.h : Aucun fichier ou répertoire de ce type In file included from include/main.h:157, from main.c:26: include/utils.h:36: erreur: erreur d'analyse syntaxique avant « GString » (sorry, errors are in french) Thanks ! Olivier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#329355: Kernels compiled from kernel-source-2.4.27 can't boot on x86_64.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again. On Wed, Sep 21, 2005 at 07:55:27PM +0200, Frederik Schueler wrote: the amd64 port does not support 2.4 kernels, and there are no plans top change this. ACK. I guess I missed that part in the release notes... I re-read the whole thing anew just now. There is no concrete statement that 2.4 will never ever run on x86_64. The sentence For the AMD64 architecture only a 2.6 kernel is available could be interpreted as we only build the 2.6 kernel but, hey, here's the code for an earlier one too. I also read that chapter 4 about moving up from a 2.4 to a 2.6 kernel and it doesn't seem as if one couldn't go the other way round either. Anyway, if it weren't for this wretched sata controller thing, I would've gone straight for a 2.6 kernel. BTW the bug report was automagically raised to 'serious' status by reportbug (no builds of kernel-image-2.4.27 could be found -- obviously -- so it thought it was something more than what it actually was). Oh well... Back to 2.6, then. Sorry for the noise. \n\n -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Nikos Nikolai Ntarmos [EMAIL PROTECTED] iD8DBQFDMbX9m6J1ac+VFgoRAmKuAKCT+ZAypHQrOOBBsCVUW/SuIU3ZBACePK9t 3mTDtXozh67uJJMs36vzjik= =nEj6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Headers for 2.6.11
--- Lennart Sorensen [EMAIL PROTECTED] Requirements for libs yes, but won't make the package system happy. Using the equivs package means you can install the proper i386 nvidia-glx package in the chroot, without having to build an i386 kernel package as well, since the equivs package will provide the dependancy it needs. ie: /tmp/nvidia-kernel-equivs.control: Section: misc Priority: optional Standards-Version: 3.5.10 Package: nvidia-kernel-equivs Version: 1.0.7174 Maintainer: Len Sorensen [EMAIL PROTECTED] Provides: nvidia-kernel-1.0.7174 Architecture: all Description: Fake package for nvidia-kernel-modules Fake package to satisfy nvidia-glx dependancies for chroot use. debdev1:~# equivs-build /tmp/nvidia-kernel-equivs.controlA stuff happens Out comes: nvidia-kernel-equivs_1.0.7174_all.deb Install with dpkg -i and you satisfy the requirements of the chroot to then install nvidia-glx. Change names and version numbers to match your needs. Len Sorensen Len, you are fantastic. Thanks SO MUCH! It works perfectly and I've learned quite a bit. nvidia 4368492 12 - NVRM version: NVIDIA Linux x86_64 NVIDIA Kernel Module 1.0-7676 Fri Jul 29 13:15:16 PDT 2005 GCC version: gcc version 4.0.2 20050917 (prerelease) (Debian 4.0.1-8) I'll test out some 32bit games when I get home. Thanks again, Zaq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 sources.list file
On Wed, 21 Sep 2005 12:15:18 -0700 lordSauron [EMAIL PROTECTED] wrote: okay... I think I now have figured out why the system refuses to install amd64 packages, perferring the i386 packages: it still thinks it's an i386 system. In addition to what Len Sorensen said on a doing a fresh install, here's how I've successfully upgraded a couple of i386 systems to the amd64 port without having to set everything up again. Beware, the following general steps are from memory: - Run dpkg --get-selections my_installed_packages on your current i386 system. - Store /etc/*, /home/*, /var/log/*, /var/www/*, and whatever else you want to keep (don't forget the newly created my_installed_packages file) in a safe place, e.g. on another drive where you can get at them from a fresh installation. - Check again that you haven't forgotten anything important on your current system. - Install sarge using a netinst CD image; i.e. the fresh install Len Sorensen mentioned. - When the fresh install is finished, copy the my_installed_packages file to the system. - Remove architecture dependant packages from your my_installed_packages file (e.g. kernel-image, linux-image, alsa-modules ...). Apt may refuse to install them, however, so this step may be unnecessary. - Run dpkg --set-selections my_installed_packages to mark your previously installed packages for installation. - Run e.g. apt-get update ; apt-get upgrade (possibly also apt-get dist-upgrade). Aptitude may do a better job of this. - Copy your stored directories and files back, taking care when restoring /etc/* as there may be architecture dependant settings. You should be able to performed the last two items in the reverse order, but I don't remember in which order I did this. Good luck! -- Regards, Kaare - http://www.nightcall.dk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
media player
Hello I was wondering if anyone could give some advice on a good media player to view films. Thanks for your help Clyde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Headers for 2.6.11
On Wed, Sep 21, 2005 at 01:21:31PM -0700, Zachary Rizer wrote: Len, you are fantastic. Thanks SO MUCH! It works perfectly and I've learned quite a bit. Me too. Now I know how to use equivs. One of those things I knew existed but never used before. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: media player
Hi, On 9/21/05, hjalmar [EMAIL PROTECTED] wrote: I was wondering if anyone could give some advice on a good media player to view films. what about mplayer? You'll most probably have to download and compile it yourself, but it works pretty well on my box. Bye, Michael
Re: media player
On Wed, Sep 21, 2005 at 11:25:27PM +0200, hjalmar wrote: I was wondering if anyone could give some advice on a good media player to view films. I use mplayer from the marillat archive at ftp.nerim.net, although for many files you need codecs that only windows has which means running mplayer i386 in a chroot to use those, at least at this time. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 sources.list file
On Sept. 21st, Kaare Olsen wrote: okay... I think I now have figured out why the system refuses to install amd64 packages, perferring the i386 packages: it still thinks it's an i386 system. In addition to what Len Sorensen said on a doing a fresh install, here's how I've successfully upgraded a couple of i386 systems to the amd64 port without having to set everything up again. Beware, the following general steps are from memory: - Run dpkg --get-selections my_installed_packages on your current i386 system. - Store /etc/*, /home/*, /var/log/*, /var/www/*, and whatever else you want to keep (don't forget the newly created my_installed_packages file) in a safe place, e.g. on another drive where you can get at them from a fresh installation. - Check again that you haven't forgotten anything important on your current system. - Install sarge using a netinst CD image; i.e. the fresh install Len Sorensen mentioned. - When the fresh install is finished, copy the my_installed_packages file to the system. - Remove architecture dependant packages from your my_installed_packages file (e.g. kernel-image, linux-image, alsa-modules ...). Apt may refuse to install them, however, so this step may be unnecessary. - Run dpkg --set-selections my_installed_packages to mark your previously installed packages for installation. - Run e.g. apt-get update ; apt-get upgrade (possibly also apt-get dist-upgrade). Aptitude may do a better job of this. and a little apt-get dselect-upgrade :-) http://www.debian.org/doc/manuals/quick-reference/ch-package.en.html this techniques works really great but expect that a few packages will remain unavailable in the new arch (amd64) which is not problematic at all 'still, from time to time re-run the dselect-upgrade and you might find that yet another package has found it's way to AMD64 lately there was valgrind and qemu few more to come very soon... -- Cyril Chaboisseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: remove unwanted modules
On 09/21/05 12:24:06AM -0500, Marc DM wrote: Stupid questions : How can I find out which modules my system actually needs and disable the ones I don't need. How can I know if a module I'm disabling at startup isn't needed for another module that I plan to load? Thanks. And I won't ask anymore stupid questions for the rest of the week. But why do you want to do this? A full modules directory in /lib/`uname -r` only takes up ~40M. And who knows when you'll plug in some new USB device or something and wish you had that module handy. The only way you're going to get an accurate list is if you know what all of the modules are used for. And stripping out the modules with a 0 reference count won't be enough, for instance ide-cd currently has a ref count of 0 on this machine because there's no disc mounted. Hmmm and somehow tulip has a ref count of 0 as well even though I know I'm using that NIC... Anyway, you'll pretty much have to go through the lsmod output and run modinfo on each module and decide whether it's important enough to keep or not. Regards, Marc DM Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: media player
Yannick - Debian/Linux ha scritto: Hi, I've made the .deb for mplayer available on aMule's network (ed2k). (because those .deb aren't available as debian way (using apt-get) right now until october for a mysterious reason...) Why don't you use Bittorrent? It's so fast. Try Azureus (from its homesite, not from debian), you'll see. Creating a torrent is so easy. -- Alessandro Dal Grande Student In The University Of Padua - Computer Science Linux Registered User #359258 System: GNU/Linux Debian Sid Pure64 on [EMAIL PROTECTED] Chat: Psi ICQ) 150487234 Jabber) [EMAIL PROTECTED] Put the fan back into computing signature.asc Description: OpenPGP digital signature
Re: remove unwanted modules
Jim Crilly wrote: But why do you want to do this? A full modules directory in /lib/`uname -r` only takes up ~40M. And who knows when you'll plug in some new USB device or something and wish you had that module handy. Actually, I wanted to know just for knowing purposes. The other reason I wanted to know is because I'm using Debian with a single Opteron246 to create a router to handle traffic between 4 vlans and the internet. So I wanted to make sure that I didn't have any modules in there that might be a potential security threat nor any that would degrade performance solely due to its presence. Know of any? Marc DM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Migrate running IA32 system to Debian AMD 64?
[EMAIL PROTECTED] wrote: I have a running critical production server, running Debian Sarge 32 Bits version. If it is critical then don't touch it. I would like to migrate to Debian-AMD64 system, There is no easy way to change architectures without reinstalling. how can I do it, without interrupting for more than 5 minutes my services which are running on it? You can't do it. I will even go so far as to say you cannot do a fresh installation in five minutes. Changing from one architecture to another would take longer. Is this possible? No. Bob signature.asc Description: Digital signature
Re: Migrate running IA32 system to Debian AMD 64?
On 9/20/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I would like to migrate to Debian-AMD64 system, how can I do it, without interrupting for more than 5 minutes my services which are running on it? Last Saturday, I implemented a process converting data from one of our systems to a new protocol version. My part of that effort was on the database side, and involved about a 1 hour outage, which was added to several hours of sysadmin effort... For that change to involve 1 hour of database outage required that some of us clever folks start planning how to do this about a year ago. You're without hope in this, at least based on the methodology you seem to think you're using. Point #1. You need another server to do this. If you can't get one, you can't have a five minute outage. Point #2. You need to have a REALLY CLEAR inventory of what services you need to migrate. It is entirely likely that there will be some that can be migrated painlessly, possibly even without any evident outage. You need to have a plan for each and every service that is to be migrated. Otherwise the migration will fail. We have one server at work running an ancient (and now totally unmaintainable!) Debian release; a project to shift services off of it in 2003 has still not completed. We got databases off of it, but there is still an Apache instance running a bunch of little CGI apps that haven't been successfully run anywhere else :-(. Planning and intent took place, but it turned out to be just too painful to migrate everything off the box. -- http://www3.sympatico.ca/cbbrowne/linux.html The true measure of a man is how he treats someone who can do him absolutely no good. -- Samuel Johnson, lexicographer (1709-1784)
Re: Migrate running IA32 system to Debian AMD 64?
On Wed, 2005-09-21 at 23:14 -0400, Christopher Browne wrote: On 9/20/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [snip] there is still an Apache instance running a bunch of little CGI apps that haven't been successfully run anywhere else :-(. Planning and intent took place, but it turned out to be just too painful to migrate everything off the box. They are either monitoring some ancient bit of undocumented h/w, or are scarily written Perl 4, or both. -- - Ron Johnson, Jr. Temporarily not of Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. To be stupid, selfish, and have good health are three requirements for happiness, though if stupidity is lacking, all is lost. Gustave Flaubert signature.asc Description: This is a digitally signed message part
Re: amd64 sources.list file
basically I should reinstall using an amd64 disk?
Re: remove unwanted modules
On 09/21/05 09:06:44PM -0500, Marc DM wrote: Jim Crilly wrote: But why do you want to do this? A full modules directory in /lib/`uname -r` only takes up ~40M. And who knows when you'll plug in some new USB device or something and wish you had that module handy. Actually, I wanted to know just for knowing purposes. The other reason I wanted to know is because I'm using Debian with a single Opteron246 to create a router to handle traffic between 4 vlans and the internet. So I wanted to make sure that I didn't have any modules in there that might be a potential security threat nor any that would degrade performance solely due to its presence. Know of any? Just a guess, but if a module was known to be a security problem it would most likely have been removed or fixed =) And since you need to be root (or at least have CAP_SYS_MODULE) to load/unload modules, the box will already be compromised by the time they can load any potentially malicious modules. And as for performance, I really doubt any modules would slow anything down to the point where you would notice. Most of the modules that might affect performance require you to do something to activate them, like even if you load every iptables module available it won't matter unless you have rules to make them do something. Especially with a box as fast as an Opteron. You might end up with a little less free memory if you load a few modules that you don't plan on using, but most modules are only few K each anyway. Marc DM Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
