I am experiencing random permission 600 applied to /etc. Sometimes I can go a day without being struck, and sometimes only minutes later, after doing chmod 755 /etc, it's back to 600. I thought this might be some protection feature in the kernel to protect against bad memory or mass storage. I have changed out memory, leaving only one stick fully qualified by my motherboard maker, but to no avail. I can't play with the disks right now. I reduced the number of processes to those listed in the attached file. Is this a normal feature due to marginal hardware, a misinstalled application or is my system hacked?

—Stan Katz, stan@cloud9.net

Hardware issues will (almost) never cause filesystem changes in this manner and certainly not in such a consistent manner. It's time to look for applications (possibly malignant) that may be causing the problem. You need to examine your other log files—something might be a hint there. You only included messages through the system boot, nothing from its operation. Start by looking in all crontab files, tracing out processes that are run from it. Also compare the system dæmon binaries you are running, as well as other regularly used tools, against those on your installation media to verify that they have not been replaced with a Trojan horse. Finally, check for applications that are setuid root, since those are a sure tip-off that you have been compromised. However, it's unusual for a Trojan horse to restrict the permissions on a directory. Without access to the system, its log files and the ability to examine the files installed, we cannot further analyze the problem.

—Chad Robinson, crobinson@rfgonline.com

You almost certainly have a cron job that is resetting the permissions, or worse, a cracker kernel module that is messing around with your system. You should try chmod 755 /etc; chattr -i /etc to make /etc immutable, which hopefully will help make whatever program is resetting the permissions fail (for a cron job, you may even get an error by mail). Typing rgrep -r chmod /etc /var/spool/cron may also give you a clue as to what is changing the permissions.

—Marc Merlin, marc_bts@valinux.com

This is not a feature. Sounds like a Trojan or misinstalled program. This is a difficult problem to find. Try to do an lsof /etc to see if any program is currently holding the directory open. This may give you a clue. Next, shut down various services/programs until you find the offending program. It might be easier to re-install your version of Linux from scratch.

—Christopher Wingert, cwingert@qualcomm.com

I can't access my tape! Running dmesg shows:

scsi0 : Adaptec AHA274x/284x/294x
        (EISA/VLB/PCI-Fast SCSI) 5.1.33/3.2.4
       <Adaptec AHA-294X Ultra SCSI host adapter>
scsi : 1 host.
  Vendor: ARCHIVE  Model: Python 28454-XXX  Rev: 4ASB
  Type:   Sequential-Access    ANSI SCSI revision: 02
  Vendor: FUJITSU   Model: M1606S-512       Rev: 6236
  Type:   Direct-Access        ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 3, lun 0
scsi : detected 2 SCSI generics 1 SCSI disk total.
(scsi0:0:3:0) Synchronous at 10.0 Mbyte/sec, offset 15.
SCSI device sda: hdwr sector= 512 bytes.
Sectors= 2131992 [1041 MB] [1.0GB]

I can access the SCSI disk but not the tape. Both eth0 and aic7xxx are on interrupt 9. I have SCSI tape support compiled in the kernel. This is all on a P133.

—Andy Prowse, azp80@amdahl.com

Normally, dmesg(8) should show a line referencing st0 as a device found in the summary, just below the entry about sda. See the example below from my own system:

Detected scsi tape st0 at scsi0, channel 0, id 6, lun 0

Your tape drive is being discovered as a “generic” device, but you cannot use mt(1) without the tape driver active. Check your kernel compilation options. Depending on your kernel version, this should be under “SCSI support” and named “SCSI tape support”.

—Chad Robinson, crobinson@rfgonline.com

I installed Red Hat 7.2 with a network card and successfully connected to the Internet with a cable modem connection hosted on another machine in the network. Now I need to connect to a dialup account. The modem is correctly configured (I can log in successfully). But when I try to work with the dialup account, I am unable to connect to its mail server because my Linux box is using eth0 routes as the default routes. How do I change the routing tables to fix this? I already checked the box to make ppp0 the default connection, but that did not solve the problem.

—Kelvin Barnes, Kelvin.Barnes@att.net

You have a default route going to your Ethernet interface that is superseding the default route added by PPP. You can try route del -net default before bringing your PPP interface up, and then it should work. You also can use the Red Hat GUI to bring eth0 down and back up.

—Marc Merlin, marc_bts@valinux.com

Recently, several attempts to run vi /etc/filename resulted in vi freezing and Telnet/SSH not responding to break commands (Ctrl-C, Ctrl-B, Ctrl-D). I logged in to the server again and tried to kill the process. The man pages said that if kill didn't work, it was probably a result of the kill command being a part of the shell. So I tried /bin/kill <pid>, /usr/bin/skill <pid>, /usr/bin/killall vi with 9, 15 and several other signals. Running top and killing the process via top didn't work either. It has been a couple of days and about a dozen vi processes are still running. I need a license to kill!

—Peter D'Souza, souza@broadleaf.net

If a process is stuck in kernel state due to a kernel or network problem, you will not be able to kill it, even with kill -9. In that state, you can usually only reboot to get rid of the process.

—Marc Merlin, marc_bts@valinux.com

Why can I not get startx to work on a Toshiba Satellite Pro 4600 that uses a Trident CyberBladeXP video card? I am running Red Hat 7.2., and I get the following error:

Fatal server error:
No Valid modes found.

—Troy, coder@starmail.com

There is one update from Red Hat's site that mentions solving a problem with your video card. Please try to upgrade the necessary packages and try again. You can find more information about it at rpmfind.net/linux/RPM/redhat/updates/7.2/i386/Xconfigurator-4.9.39-2.i386.html.

—Mario Bittencourt Neto, mneto@buriti.com.br

When I run DragonLinux everything loads perfectly until Space Freed:. Then it says:

Warning:Unable to open an initial console
Kernel Panic:no init found.
Try passing init= option to kernel.

—Alok Bhatt, dkbhatt@eth.net

You may have corrupted the root filesystem after you finished installing. I suggest that you reinstall Linux and make sure that you make a filesystem on all Linux partitions. If you experience the same problem again, then you need to contact the DragonLinux people.

—Usman Ansari, usmansansari@yahoo.com

I thought I'd take the opportunity to e-mail you about configuring Red Hat 7.0 to be able to use Japanese. I have a 109-key Japanese keyboard and am using a Japanese 106 keymap that works okay, despite being unable to use the Japanese-English switch key. I enabled deadkeys and installed all the Japanese language packets during installation. These packets, WNN and Kanna packets, among others, start up on boot but don't activate for some reason. Any help would be appreciated. I think I could solve it by getting the right keyboard map. Japanese characters will appear on most software in KDE and GNOME, but getting output from the keyboard is the problem.

—Graeme Jensen, magic@zae.att.ne.jp

I recommend you use a distribution that has been widely tested with Japanese. You'll have better odds with those things working out of the box. I have to admit I'm not sure which is the Japanese distribution of choice today, but you may want to give Turbolinux a try.

—Marc Merlin, marc_bts@valinux.com