dselect: improper dependancy resolution behavior?
I am hand selecting my packages, but I am having a problem with libncurses4 and libncurses5. Until I know more about this, I suppose it won't harm anything to just install both versions. However, if I try to remove libncurses4, the dependancy resolution also forces the removal of nvi. It is my understanding the nvi is the linux version of vi, which I prefer to use above any other editor. Will nvi work with libncurses5? If so, will it hurt anything to 'manually' force the removal of libncurses4 in the future? dselect - main package listing ## the following packages are installed and marked for install: *** Req base libncurses5 5.0-6.0pota *** Req base ncurses-base 5.0-6.0pota *** Req base ncurses-bin 5.0-6.0pota ## the following packages are not installed, but marked for install: n* Imp oldlibs libncurses4 4.2-9 n* Std admin ncurses-term 5.0-6.0pota Thanks in advance for your help. - gladimir
kernel config: pcmcia and network device support?
I'm probably just looking for a 'shove' here, but I'm having a problem determining which network driver to build into my kernel. Note: My networking is operating fine with whatever the default settings for kernel-2.2.19pre17 'compact' happen to be. I have a 3Com 3C589C Etherlink III pc card in my laptop. I am trying to complete my first attempt at configuring a linux kernel, and I am stuck in 'network device support'. I do have the pcmcia-cs v3.1.22-0.2 package installed (kernel version 2.2.19pre17). In the 'network device support' menu: M dummy net driver support In the 'ethernet (10 or 100Mbit)' menu: [*] ethernet (10 or 100Mbit) other options that don't really match my situation My best newbie interpretation of /var/log/messages suggests that 3c59x.c, pcnet32.c, and via-rhine.c are being loaded as modules in my current (default) kernel. However, I am not sure which one of these )if any) is actually doing me any good since none of them do any good until the card services startup and find my adapter with IO port probes. Any help, suggestions, or advice would be greatly appreciated. - gladimir
modprobe: Can't locate module char-major-10-135 (daemon.log)
I have tracked this down to the point that I know it is an alias for the real time clock, and that it only occurs soon after switching to run-level 6 and run-level 0. I also know that the alias exists in two files, that I know of; /etc/modules.conf and /etc/modutils/arch/i386. Removing the alias from i386 has no effect. I have seen a few people suggesting that I should edit modules.conf, but the modules.conf file has comments stating that it should never be edited manually. Is it either safe or effective to manually edit this file? If not the modules.conf file, then which file do I edit to affect this workaround until I can compile rtc in the kernel? Thanks in advance for any help. - gladimir
pci ide device drivers; compiling drivers?
I am slowly making my way through /var/log/messages, and I ma trying to correct the following error: PCI_IDE: unknown IDE controller on PCI bus 00 device 40, VID=1095, DID=0643 My disk controller happens to be: CMD Technology 646U2 Ultra DMA Controller Maybe I've been staring at my computer for too many hours, but I can't find anything that I might recognize as a straight forward, ready-to-go driver for this controller. However, I have found send several source files for this driver (example follows), so I would like some instructions or a link instructing me on compiling and installing the driver. http://www2.linuxforum.net/lxr/http/source/drivers/block/cmd646.c Thanks in advance for any help in this matter. - g
compiling drivers, kernel; configuration strategy...
The immediate problem I am trying to address is the following error reported in /var/log/messages: PCI_IDE: unknown IDE controller on PCI bus 00 device 40, VID=1095, DID=0643 I have downloaded and expanded my kernel source code (2.2.12), which did include the desired driver source: /usr/src/kernel-source-2.2.12/drivers/block/cmd646.c However, there appeared to be no precompiled module file as far as I could tell, and 'modconf' only has 5 entries in the block category (cmd64x is not one of them). I ran the following command for compiling the driver, as suggested on a website: gcc -DMODULE -D_KERNEL_ -O6 -c cmd646.c This produces several screens of error messages and I can't seem to capture them by appending ' cmd646.out' to the end of the command. In any event, this leads to the greater question of strategy. Am I correct in assuming that these sorts of issues should be worked out before I finally re-compile kernel for my system? Thanks in advance for any help, corrections, tips, and advice on different configuration approaches. - g
NFS related error; do I need NFS?
The following error is being reported in /var/log/messages: rpc.statd forgot to set AF_INET in udp sendmsg. Fix it! The rpc.statd daemon appears to be loaded in the nfs-common rc scripts. I do plan to enable samba on my linux machine, eventually; but I don't think I have any reason to be running any NFS daemons. As far as I can see, I will never be sharing files between *nix machines or doing any remote mounts or anything else that I commonly associate with NFS. So, I have two questions: 1) Do I need NFS on this linux machine? 2a) If so, how do I make this error go away? 2b) If not, what is the process for removing the nfs-common scripts from the system initialization? Thanks for you help. - g
RE: NFS related error; do I need NFS? --Solved!
Yea! That's one boot problem out of 5 completely solved! I ran dpkg --status nfs-common as suggested and found the name of the package, which was nfs-common, amazingly enough. I started dselect and went right to the select screen where I located the nfs-common package and marked it for purge. This led me to a dependancy resolution screen where I also marked the nfs-server to be purged. I accepted these changes and let dselect remove the packages, which it did without error or complaint. Finally, I rebooted and everything works as it did before, except for the lack of the rpc.statd error messages. Thanks to Jeremy Gaddis, I feel like there might be hope to resolve the other boot problems on my new linux installations. - g -Original Message- From: Jeremy Gaddis [mailto:[EMAIL PROTECTED] Sent: Saturday, July 14, 2001 4:36 PM To: [EMAIL PROTECTED] Cc: Debian-User (E-mail) Subject: Re: NFS related error; do I need NFS? On Sat, 14 Jul 2001, Gladimir wrote: 1) Do I need NFS on this linux machine? The general rule is if (a) you don't know what a service is, or (b) you don't know if you need it, you probably don't. If you did need it, you'd know. Disable rpc.statd, rpc.nfsd, portmap(per), and any other RPC-related daemons that might be running. Running unneeded rpc.* services has caused more than one machine to get compromised. 2a) If so, how do I make this error go away? Uninstall the package that provides rpc.statd. 2b) If not, what is the process for removing the nfs-common scripts from the system initialization? Remove the packages that provide rpc.statd, rpc.mountd, portmap, and the other RPC services that are installed. I don't recall the package names right off-hand, but it's nothing that `dpkg --status filename` won't tell you. HTH. j. -- Jeremy L. Gaddis [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: dselect and getting kernel source files...
I am new to linux and 2.2.12 is what came on my O'Reilly CD, but I think it should be more than capable of running the apache web-server and inn usenet server that I intend to setup on it. Chances are that I will upgrade the kernel in the process of tuning my existing kernel, eventually. I already have bin86 on my system, and dselect also made me aware of this dependancy; but thanks for the heads up. - g -Original Message- From: David Z Maze [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2001 8:42 PM To: debian-user@lists.debian.org Subject: Re: dselect and getting kernel source files... Gladimir [EMAIL PROTECTED] writes: G The default debian installation did not install my kernel source G files, so I am using dselect to get those files. I'd just get a kernel tarball off of ftp.kernel.org or a mirror and unpack it somewhere handy. G I found the source files and marked kernel-source-2.2.12 for G installation, (Why something so ancient? My stable box is running 2.2.19.) G Here is my current situation: G _* kernel-source-2.2.12 G __ tk8.2-dev (suggested) G __ tk8.0-ja-dev (suggested) G __ tk8.0-dev (suggested) G __ kernel-package (suggested) G G Now, I am inclined to only select the kernel-package because I have no G intention of running a GUI on this machine. Am I correct in assuming the G tk-dev files are for writing X interfaces, for kernel management, using tcl? 'make xconfig' uses it, but nothing else. G Am I correct in assuming that kernel-package is still very useful without a G GUI? Yes, in fact. nods Also, on x86, you'll need the bin86 package if you don't have it installed. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: dselect and getting kernel source files...
I am new to linux and 2.2.12 is what came on my O'Reilly CD, but I think it should be more than capable of running the apache web-server and inn usenet server that I intend to setup on it. Chances are that I will upgrade the kernel in the process of tuning my existing kernel, eventually. I already have bin86 on my system, and dselect also made me aware of this dependancy; but thanks for the heads up. - g -Original Message- From: David Z Maze [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2001 8:42 PM To: debian-user@lists.debian.org Subject: Re: dselect and getting kernel source files... Gladimir [EMAIL PROTECTED] writes: G The default debian installation did not install my kernel source G files, so I am using dselect to get those files. I'd just get a kernel tarball off of ftp.kernel.org or a mirror and unpack it somewhere handy. G I found the source files and marked kernel-source-2.2.12 for G installation, (Why something so ancient? My stable box is running 2.2.19.) G Here is my current situation: G _* kernel-source-2.2.12 G __ tk8.2-dev (suggested) G __ tk8.0-ja-dev (suggested) G __ tk8.0-dev (suggested) G __ kernel-package (suggested) G G Now, I am inclined to only select the kernel-package because I have no G intention of running a GUI on this machine. Am I correct in assuming the G tk-dev files are for writing X interfaces, for kernel management, using tcl? 'make xconfig' uses it, but nothing else. G Am I correct in assuming that kernel-package is still very useful without a G GUI? Yes, in fact. nods Also, on x86, you'll need the bin86 package if you don't have it installed. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
which rc file for hdparm commands?
I am slowly working my way through the HOWTO files on the linux documentation site, beginning with Config-HOWTO, which recommends starting with my kernel and hard disk performance. The problem is that section 2.6 recommends adding hdparm commands to the following file: /etc/rc.d/rc.sysinit Of course, I have no such file on my system, and it would be futile to visit all 7 of the rc#.d directories and grep for the hdparm command because that command was not on my system until a few moments ago. Would the hdparm command add any performance (i.e. 32 bit access) to a 1997 pentium system with 1.5GB hard drive? If so, where is the appropriate place to enter hdparm commands? Thanks in advance for your help. - g
dselect and getting kernel source files...
The default debian installation did not install my kernel source files, so I am using dselect to get those files. I ran dselect, performed an update, and went to the selection screen. I found the source files and marked kernel-source-2.2.12 for installation, but I was sent to the dependency resolution screen to muddle through some suggestions. Here is my current situation: _* kernel-source-2.2.12 __ tk8.2-dev (suggested) __ tk8.0-ja-dev (suggested) __ tk8.0-dev (suggested) __ kernel-package (suggested) Now, I am inclined to only select the kernel-package because I have no intention of running a GUI on this machine. Am I correct in assuming the tk-dev files are for writing X interfaces, for kernel management, using tcl? Am I correct in assuming that kernel-package is still very useful without a GUI? Thanks in advance. - g
