pmpatrick

If kde runs a little slow on that hardware, you may want to take a look at zenwalk: http://www.zenwalk.org/ It's a rolling distro based on slackware that's designed for more modest hardware. I have it on a PIII 500MHz with 256MB of ram and it runs great. It installs Xfce by default but kde can be installed from their repo after the initial install as can gnome. Other kde based distros were pretty sluggish on this hardware compared to zenwalk.

Do you get the same error if you log into a gui as root? If not, try running as an ordinary user: $ kdesu kwrite It seems to work better for me than firing kwrite up driectly from a root konsole.

Check your security level by running as root: # draksec Anything above "High" will cause permission problems and is unecessary for desktops.

Here's one of the best ssh tutorials I've seen on the net: http://www.suso.org/docs/shell/ssh.sdf It's a good starting point and may point you in the right direction. However, from your description it sounds like you would be better off setting up an sftp server rather than try to shoehorn ssh into doing a job it really wasn't designed to do.

These are well known brute force attacks on ssh that came out last year: http://www.whitedust.net/article/27/Recent...orce%20Attacks/ If you google you will find plenty of info on this phenomena and countermeasures. I think the best counter is to dump passwords for ssh altogether and use key based authentication: http://www.securityfocus.com/infocus/1810

Fdisk -l lists all the partitions linux recognizes, whether they are mounted or not. Comparing your fdisk output with your fstab, I can deduce the following. It looks like you moved the drive that was on hdc to the promise controller and it is now hdf and then you put another drive on hdc containing only one FAT32 partition. Hda is where you have linux installed and that was not moved. That's just for starters. The drive on the promise controller is probably not jumpered correctly as well since hdf indicates that the hard drive is configured as a slave drive on the promise ide1 channel with nothing on that channel configured as master which would be hde in linux unless you have an optical drive there now. Having an optical on the promise controller is not a good idea and may be part of your problem if that is the case. You also seem to have lost sdb which may either be a sata drive, an external usb mass storage device or scsi drive. I need to now your starting configuration in detail, i.e. what drives were on which ide channel and whether they were master or slave. And exactly what you moved were. I also need to know what sda and sdb are. I think the misconfigured drive on the promise controller is your main problem. You also have some erroneous entries in you fstab for hdc since that has been moved to the promise controller. That can cause the boot process to hang but shouldn't give a kernel panic. Double check your jumpering on the promise drive and for the time being make the following edits to fstab commenting out some potentially troubling entries: /dev/hda5 / ext3 defaults 1 1 #/dev/hdc1 /mnt/Amov1_1 vfat nls=iso8859-15,rw 0 0 #/dev/hdc5 /mnt/Amov1_2 ntfs nls=iso8859-15,rw 0 0 #/dev/hdc6 /mnt/Amov1_3 vfat iocharset=iso8859-15,codepage=850 0 0 /dev/sda1 /mnt/BIG_DISK auto defaults 0 0 #/dev/sdb1 /mnt/PEN_DISK auto defaults 0 0 /dev/hdb /mnt/cdrom auto user,iocharset=iso8859-15,codepage=850,noauto,ro,exec,users 0 0 /dev/hdd /mnt/cdrom2 auto user,iocharset=iso8859-15,codepage=850,noauto,ro,exec,users 0 0 /dev/hda7 /mnt/disk_2 vfat nls=iso8859-15,iocharset=iso8859-15,codepage=850,rw 0 0 /dev/hda8 /mnt/disk_3 vfat nls=iso8859-15,iocharset=iso8859-15,codepage=850,rw 0 0 /dev/fd0 /mnt/floppy auto user,iocharset=iso8859-15,sync,codepage=850,noauto,exec,users 0 0 /dev/hda1 /mnt/win_src ntfs nls=iso8859-15,ro 0 0 none /proc proc defaults 0 0 none /tmp tmpfs defaults 0 0 /dev/hda6 swap swap defaults 0 0 Commenting out the hdc entries is fstab may help but that hdf drive on the promise controller is just not right. It should be hde if properly jumpered/cabled, i.e., it should be set to master on promise ide1. Edit: Just thought of something else. I have a Promise Ultra 100 card that I have been using in linux for many years. My card specifically states that it will not accept optical drives; attempting to do so causes booting problems in linux and other problems in windows. It's a hard drive only device. Also, the card's documentation states that the boot drive(that would be your current hda drive) must be moved to the promise controller. You obviously didn't do that since your boot drive is still on hda(onboard ide1 master). Your promise card is obviously much newer than mine and may not have the same limitations but check your documentation.

Your hard rive is no longer hda if you moved it to the promise controller; that's what's wrong. Boot into slax again(root login), open a console and run: # fdisk -l Post the output here. That will tell me where your hard drive is as far as linux is concerned. We can make the necessary changes from there.

It's a simple problem IMHO. You appear to have moved your hard drive from your onboard ide controller to your Promise controller. Linux identifies hard drives and partitions by where they are on the ide bus. For example, when you did your install say the hard drive that you installed to was on the primary onboard ide channel as master and you installed to the second primary partition on that drive. Linux would designate that as /dev/hda2 and all your config files will reference /dev/hda2 as the location of your root partition. Now lets say you move your hard drive to the first ide channel on your promise card. Linux now identifies that drive as /dev/hde and the root partition as /dev/hde2. Unfortunately, when you go to boot, all your config files are still referencing your root partition as /dev/hda2, i.e. your lilo bootloader is looking for the root partition on /dev/hda2 but there is nothing there now because you moved the drive to the promise controller which linux sees as /dev/hde2. The result is a kernel panic(no init found error message) which is merely linux telling you it can't find the root partition where it expects it to be on /dev/hda2. Basically, what you have to do is edit two config files, /ect/fstab and /etc/lilo.conf, to bring them in line with the new position of the hard drive on the ide bus. The easiest way to do that is with a bootable livecd like knoppix or slax. That will allow access to these files so you can make the necessary changes to these files so the system can find your partitions again in their new location. So for a first step in correcting this problem, download slax here: http://slax.linux-live.org/download.php Slax is nice because it's a smaller download(192 MB) and boots into a kde desktop. Once you get this far and have a bootable slax cd, post back and I'll walk you through the steps to correct the problem using slax.

Can you estabolish a connection without any encryption enabled? If not, it may be a configuration issue having nothing to do with your encryption key. Also, post what wireless nic you are using, which distro, the version of ndiswrapper and the windows driver you are using. If you are running windows, I assume you have confirmed that you can connect OK under windows.

Is your hex key 10 or 26 characters in length? The 26 character length hex key indicates 128 bit encryption and that can give problems with ndiswrapper with some drivers; it's just not as well supported depending on the version of ndiswrapper and the driver you are using. The 10 character length key indicates 64 bit encryption(also referred to as 40 bit encryption by some vendors) and generally works better and is well supported with ndiswrapper.

Have had the same problem here with mdv 2006. I'm using the nvidia driver with kde and have done all the updates. I've managed to isolate the problem to kdm. If I use gdm instead, the problem goes away but then you don't get the shutdown dialogs that you normally get when running kde. Instead, you are limited to logging out from kde which brings you back to gdm and you can shutdown from within gdm without issues.

When you wiped the drive, mandriva was able to create a partition within the 130 Gb bios limit at the beginning of the drive as I mentioned above and complete the install. That's why it's booting now. Previously, windows occupied all that space making it impossible for mandriva to create a bootable partition within the bios limit. I doubt that you will get windows to install on the back end of your hard drive as that is probably not within the bios 130 Gb limit. You can give it a try, but you may run into problems re the bios limit. Even if you are able to install windows, your bootloader will be overwritten by windows and you will not be able to boot into linux. There are ways to restore it which aren't that complicated afterwhich, you will have to edit your bootloader config file to add an entry that will boot windows. Here's what I would suggest instead. Delete all your partitions. Create one primary reiserfs partition at the beginning of the drive that is 20GB in size and a second linux swap partition right after that about 1GB in size. This will be mandiriva's eventual home but don't install mandriva there just yet. Next, do your windows install on the remaining unallocated space. Windows should leave your reiserfs and swap partitions alone and create a partition for itself after your linux partitions. Finally, install mandriva on the 20 Gb reiserfs partition. This procedure should allow both windows and mandriva to have bootable partitions within the bios limit and by installing mandriva second, it will pick up your windows installation and make a boot entry for it in your bootloader.

With the non-working usb device connected and powered on, run: # lsmod and: # fdisk -l and post the output here.

Looks good to me. If you want to know what your system sees directly run: $ free -m The will list your ram total and ram usage in megabytes.

How did you partition your install? In order to boot, the partition containing your kernel( the /boot directory) must be within the bios limit of the first 130 GB. If you just have one large root partition and a swap partition, it may not boot. If you can set up your install so you have a seperate /boot partition at the beginning of the hard drive, that should work. The good news is, once the kernel is loaded, linux kisses the bios hard drive size limit good bye and will see the entire 160 GB. However, in order to load, the kernel must be in a partition within the bios size limit. That appears to be what error 18 is telling you to do:

First off, even if the driver is completely wrong for your card, it should still load without error so that's the first thing to get straightened out. Your post indicates that you installed ndiswrapper from source. That error indicates to me that there may be a mismatch between your kernel and kernel source, assuming you compiled ndiswrapper from source. Just to give to give me some basic info, please post the output of these commands: $ uname -a $ rpm -qa | grep kernel $ rpm -qa | grep ndiswrapper

Since you have a 130GB hard drive on an old win98 box, I'm guessing you had to use a drive overlay program to get around your bios hard drive size limitation. A bios from that era could typically not handle that large of a hard drive, especially in windows. Drive overlay programs are a software hack to get around that bios size limit and they are frequently a problem when installing any OS, including windows. Post back if this applies or if you have no idea what I'm talking about.

You've probably already done this, but just in case, try plugging the device in on a different port. If you are using a usb hub, try plugging directly into your computer instead of the hub. Also, swap out the usb cable and see if that helps.

Fashions come and fashions go. Distros go in and out of style, sometimes very quickly. It generally doesn't have much to do with technical merit. A few years ago, gentoo was all the rage; you don't see that kind of enthusiasm for gentoo on the net today. Now all the buzz, a lot of it manufactured IMHO, is for ubuntu. This too shall pass; it always does. When the enthusiasm for the new distro dies down, it either fades away or finds its core constituency that sticks with it because they like the way that distro does things and it meets their needs. Others, particularly newbs, move on to the next big thing because that's what's getting the hype at the time they are introduced to linux. Distros like mandriva, RH/fedora, slackware, debian, gentoo, suse and I guess ubuntu at this point, have all, to a greater or lesser extent, withstood the test of time. They have estabolished a core constituency and are going to be around for a while waxing and waning in popularity. If you step back so you can see the forest for the trees, you will see that there's not much seperating all these linux distros; IMHO these distro wars become so bitter precisely because those differences are so small.

You can solve that problem by generating an ssh key. Here's a nice tutorial on ssh that goes into the process in some detail: http://www.suso.org/docs/shell/ssh.sdf That's doing it from a local linux box to a remote linux box. There should be a similar procedure for doing this in a mixed windows/linux environment but I'm not that familiar with ssh configuration in windows. If you're using putty, here's some info on key authentication in windows: http://www.tartarus.org/~simon/puttydoc/Chapter8.html#pubkey The idea is to use the generated keys as the method of authentication instead of user passwords. Once it's set up, you can automaically login without giving the password.

I guess there's no shortage of these sites; here's a couple more for you: http://www.shelldorado.com/ http://www.zazzybob.com/index.html shelldorado is one of my favorites.

But they can detect if prefetching is being used and you will be blocked from some sites if it's on. Here's one of the comments from the extension download page: For the whole story on this extension read the extensive user comments: https://addons.mozilla.org/firefox/1269/comments/ As to the fasterfox defaults, some of the above comments indicate that the "Turbo" mode is activated by default which uses prefetching. There are tips in the user comments about how to turn this off but it appears that you have to affirmatively do so. Perhaps the defaults have been changed since those comments were posted. I think the bottom line is that prefetching is something that works well if only a few people are doing it. Once it becomes widespread, it kills small servers and gets a lot of webmasters up in arms with the greatly increased bandwith load caused by the prefetching.

fasterfox is also banned on some websites due to its prefetching behaviour; it causes a huge increase in bandwith usage for website operators because it downloads every link on the page in the background even though most of those pages will never be viewed by the user. Webmasters hate fasterfox and a few sites will ban you if they detect you are using it others will issue periodic warnings requesting that you uninstall fasterfax.

It's not a question of writing code; it's a question of distributing products containing GPL'd code and that he is surely doing. Nothing prohibits you from selling products containing GPL'd code. People do it every day and they don't have to do some little dance about just selling services not the software. The issue is since it is GPL'd, that practically limits your ability to charge and arm and a leg for the product itself since anyone can reproduce the product as the code is freely available. But that's an economic, not a legal, impediment. That's why companies try to differentiate themselves based on the value added services they can provide. The kicker here is you are selling a product (coupled with a service) containing GPL'd code with Red Hat's trademark and tradename plastered all over it and that they can stop you from doing, i.e. they have a right to protect their tradename and trademark. You can't go around passing yourself off as an authorized RH rep distributing RH GPL'd software without RH's consent. To allow such a situation would be to allow others to profit off of, and potentially ruin, RH's reputation. That's where Centos comes in; they take all of RH's trademarks and references to RH out of RHEL and freely distribute it and there's not a thing RH can do about it. They can even charge as much money for the product as the market will bear and there's nothing RH can do about it. It' perfectly legal under the GPL.

I assume sda(203.9 Gb) and sdc(300 Gb) are sata drives; correct me if that's wrong. Also, post your /etc/fstab; I'm trying to get some idea of your hardware layout. If this thing can be detected as a usb storage device, then you must first have certain usb modules loaded. You can see what modules are loaded by running this as root: # lsmod look for the usb-storage module. If it's not there, no usb storage devices will be detected. To load it run: # modprobe usb-storage You can check with lsmod to make sure it's loaded and try your fdisk -l command again and see if the device is picked up. If it is you're half way home.