pmpatrick

Try the change you suggest to see if it works. I think you should be alright re other associations. IIRC those associations are usually done by device file(eg. /dev/cdrom or /dev/dvd) rather than mount point.

Please post your fstab file and the exact error message. If LinDVD is looking at /mnt/cdrom2 and there is no way to alter this behavior, you can always create a symbolic link to /mnt/dvd by running the following as root: # ln -s /mnt/dvd /mnt/cdrom2 However, all the other dvd players I've used want the device file for the dvd drive(/dev/dvd), not the mount point. /dev/dvd is just another symbolic link to the real device file, in your case /dev/hdc. You can usually create the needed links in /dev to get around these types of problems if that's what's going on but you need to get the error messages to be sure.

Try running k3b as root and go into k3bsetup from the "Settings" menu. A standard kde install should include kdesu. What error message do you get if you run: $ kdesu k3b Setting the security level too high might stop kdesu from operating as well. You can check the security level by running as root: # draksec Anthing greater than "High" causes lots of usability problems.

When you go into swap, you will really see the system slow down. How much ram do you have?

The current nvidia driver is not compatible with the 3d desktop effects AFAIK. The 9*** series of drivers which are in beta now are suppose to fix that. The 8*** series of drivers have some real issues as well.

We're getting the same behavior from various mirrors so I conclude there is probably an error in the hdlist that is being reproduced on all mirrors. The error is being reproduced across mirrors so they must all be rsyncing the the same erroneous tree.

I have this one on my desktop and it works great with the linux native madwifi driver: http://www.newegg.com/product/product.asp?...N82E16833127118 It has an atheros based chipset and the madwifi driver is the native linux driver for that. It works out of the box with PCLinuxOS which includes the madwifi drivers and should for any other distro that comes with madwifi preinstalled. There is an rpm for madwifi for mandriva which works fairly well in the standard station mode("sta"). I've also configured this card to act as a wireless access point("ap" mode) with the most recent madwifi drivers which you have to compile from source.

Same error message here from another mirror which also appears after the updated packages have installed.

Replace the entire kabc directory with the one you want to use from your old system instead of copying the contents of kabc over to your new kabc directory. I've done this many times this way and it has always worked for me.

wakish, the chances of you being hacked in linux in the weird, destructive manner you describe and your windows and data partition being intact is practically zero IMHO. I'm fairly certain this is a hardware problem. It might be the bios chip as noted above. Other things to check, your ram(mtest) and your hard drive(manufacturer's hard drive diagnostic utilities). You may also want to check your power supply but you need special equipment for that.

Try reinstalling your ati driver. An xorg update seems to break all the linking to the OpenGL libraries with the nvidia driver. Reinstalling fixes that. I'm guessing your having the same problem with your ati driver.

Which graphics card and driver are you using? When using the nvidia driver you will often get that error after installing update X packages from xorg. You may not notice it for a while since everything else works fine, just OpenGL is messed up. The solution is to reinstall the nvidia driver.

If this started after you installed gnome, then I would suspect gnome as the culprit. Gnome runs a daemon called "gam_server", aka "gamin" that polls the filesystem every couple of seconds for alterations. Gamin has been known to cause problems in the past on some setups, in particular, excessive cpu usage. It could just be something like that or may be completely normal under gnome. There may be other gnome specific services for monitoring the filesystem which may be causing periodic disk reads. I doubt turning swap off will help as the activity is problably a disk read rather than a disk write to swap. I also doubt that there is a problem with your hard drive unless you are experiencing other erratic systems. If you want to check the hard drive, download the diagnostic utilities from the hard drive manufacturer's website and run the diagnostics. That's usually the best way to tell.

Madwifi works very well for me when compiled from source. I'm using kernel 2.6.11-6mdksmp in LE2005, aka mdk 10.2. The rpms worked as well but only in station(sta) mode. I wouldn't try to use the mandriva control center configuration tools on it, however. After installing the drivers , whether through rpm or source, what output do you get with: # modprobe ath_pci # ifconfig

I have no problem with the gui. But fdsik -l gives a lot more info than you will see in mcc/diskdrake and IMHO, I needed to see that info in order to more effectively help michaelc. In particular, I wanted to see the fdisk report of the total hard drive size, the partition structure, any anomalies picked up by fdisk and the start and end blocks for every partition on the drive. You won't get all that info in diskdrake and what he would get in diskdrake, he would have to interpret and describe accurately in a return post, which may or may not happen. With a straight copy and paste of the fdisk output, there's nothing for him to interpret and the status of the drive is stated in accurate detail. I'm not insisting anyone learn the cli, but here it's a superior tool for troubleshooting the problem, particularly when the troubleshooting has to be done over the internet on a forum.

Also note, I edited my above post; it should be "other=/dev/hda1", not "image=/dev/hda1".

Yeah, the windows entry doesn't look right either. Try this: other=/dev/hda1 label=Windows table=/dev/hda read-only This assumes your windows install is on hda1 and the boot drive is hda.

The problem with the mirroring type of raid is that if something goes wrong on the first hard drive, the error will be copied to the second hard drive almost immediately. For example, if you erroneously delete all your media files on drive 1 then drive 2 media files will also be deleted. The redundancy of mirror type raid is designed to protect you from hard drive failure, not from your own mistakes or others mischief. That's why people say it's not a substitute for a backup.

Once the kernel loads, linux kisses the bios hard drive size limitations goodbye. You should see the entire drive. What's the output of: # fdisk -l Also, if you used the dd command to transfer data from one drive to your 40GB drive you can have those types of problems re erroneous size reports. Same thing goes for partimage which uses dd.

Why bother moving it out of your home directory? Unless you have multiple users that need to use firefox, I see no reason to move the firefox directory anywhere.

If it's a cd-r it's obviously a pirated version. MS doesn't distribute install cds on cd-r. It may also have some bios checks and refuse to boot on "unauthorized" systems or may just be a bad or marginal copy as alluded to above.

If you are seeing the wireless access points, ndiswrapper is probably loaded and working. You can try connecting from the command line if you know the essid you are trying to connect to. It's pretty easy. Open a console and run: $ su <enter root password> # iwconfig wlan0 essid <insert essid name> # iwconfig wlan0 key <insert WEP hex key> Note, skip step if WEP is not used # dhclient wlan0 The above assumes the wireless interface is wlan0. If not, substitue the appropriate interface name, eg. eth0, etc. The above will not work with WPA; for that you need wpa supplicant. WEP, both 64 bit and 128 bit, generally works fine with ndiswrapper but there are sometimes issues with 128 bit WEP and ndiswrapper. Also, the above assumes wlan0 is set up for dhcp rather than statically configured and dhclient is being used. That's true for mandriva and most linux distros but slackware and slack based distros use dhcpcd instead of dhclient. If nothing else, running the above will give you some info on what is going wrong if you can't connect. If you get no errors when running the above, you should be connected.

Edit this section like so: # Specifies the number of deciseconds (0.1 seconds) LILO should # wait before booting the first image. # #delay=20 # You can put a customized boot message up if you like. If you use # `prompt', and this computer may need to reboot unattended, you # must specify a `timeout', or it will sit there forever waiting # for a keypress. `single-key' goes with the `alias' lines in the # `image' configurations below. eg: You can press `1' to boot # `Linux', `2' to boot `LinuxOLD', if you uncomment the `alias'. # # message=/boot/bootmess.txt prompt nowarn # delay=100 timeout=100 That's the typical lilo.conf setup. You probably had your "delay" set too short. The above should give you a ten second delay before automatically booting the default OS.

Check the output of: # ifconfig Make sure your nic drivers are loaded as well. Looks like your network is just misconfigured; the ifconfig output will tell you more.

Here's a good article on setting up ssh_config and sshd_config files: http://howtos.linux.com/guides/solrhe/Secu...p15sec121.shtml To get more verbose output on your failed ssh login attempts add the "v" switch or, for even more, the "vv" switch, eg: $ ssh -lvv <username> <ip address> With this output you can usually get a fairly good idea of what's going wrong.