pmpatrick

smp kernels seem to be a hassle with some recent 2.6 kernels and that's what you need for detecting and utilizing multiple cpus. IIRC some relatively recent changes in the kernel smp broke some third party modules like ndiswrapper and the win4lin kernel patch as well as some others. It may be all sorted out now by I know it was an issue when mdv 2006 came out. Basically, the third parties are rewriting their modules so they work with the new smp implementation. As to issues specifically with the new duo core processors. I really don't know. The above smp issues effected both multiple cpus and intel HT cpus. It really wasn't a kernel issue per se but a question of third party module devs having to rewrite a lot of code because of the significant smp kernel changes.

IIRC that should be mountable as a usb storage device. If the device is showing up in harddrake, that's almost surely the case. Try connecting the device and power it on then run this in a console: $ su <Enter root password> # fdisk -l Post the output here. Also post your /etc/fstab file here with the device connected and powered on.

The notion that not broadcasting SSID enhances security is an urban myth; it does nothing. Anyone with commonly available tools can get your SSID is seconds. Save your self some hassle and turn it back on. Your only real security comes from your WPA encryption as WEP can now be cracked in minutes instead of hours. Check out these articles for a more thorough discussion of this issue: http://www.oreillynet.com/pub/a/wireless/e...lsshacks_chap1/ http://blogs.zdnet.com/Ou/index.php?p=43

I don't think reinstalling will help and it may do some damage. udev should be starting automatically during boot. I suspect udev is trying to do so but something else is interfering with it or hanging it up. This is probably a timing issue since you can later start udev and all is well. You can try opening a console immediately after booting up and running: $ dmesg That will print out all the kernel boot messages. Look for some indication that udev is having problems in there. The quick and dirty fix is to put the following at the end of /etc/rc.d/rc.local: /sbin/udevstart rc.local is the last init script to run and the above starts udev at the end of the init process so nothing else should interfere with udev at that point.

Hate to follow my own post, but I thought anyone interested in this topic may want to look at this thread on the pclos forum: http://www.pclinuxos.com/forum/index.php?topic=3043.0 It explains how to get a portable version of pclos on to a usb hard drive and have it be bootable. The kernel and hardware redection issues have already been worked out and since pclos is very close to mandriva, this looks like the easiest option for making your own portable hard drive with a bootable linux distro capable of doing on the fly hardware detection.

You could do that but you would have to configure the nic on the unix box which consists of getting the nic driver loaded if one is available and then configuring the network through that interface. Then you would have to get the NFS services running and configured on the unix box. In short, you would pretty much have to know what you are doing on that unix system. If you don't have documentation on that unix system or are fairly conversant with *nix, this would all be difficult. All that being said, I've never run into a unix environment that wasn't networked. Unix was designed to operate on networks. That unix system almost certainly has networking capabilities but getting it all configured without some documentation on the system would be hard. The above is standard unix stuff. You have a complicating factor here. You say you are running "Xenix" on those boxes. I associate that name with SCO and SCO uses a proprietary xenix filesystem. Given SCO's litigious nature you are not likely to find any open source support for that filesystem. There are other flavors of xenix by different vendors but SCO is the most prominent. Xenix was an early form of unix designed to run on x86 hardware. See: http://www.computerhope.com/unix/xenix.htm You can try sticking the hard drive in your linux box but if your Xenix is from SCO, it won't be able to read it. Also, I believe SCOXenix uses a proprietary networking system called OpenServer IIRC; standard NFS used by most unix systems may not be available on SCOXenix.

Let's backup here a minute. From your original question, you appear to be networked to a collection of unix machines and want to get data off one of them. Is your linux box connected to the network and do you have access/sysadmin privileges on the unix network? If the answer is yes to the above, then you can setup a network share on the unix box for your linux box and access the share through NFS which uses a TCP/IP; then it won't matter what filesystem is on the unix box. Linux and unix are both NFS compliant and should be able to be networked. The discussion in the thread so far seems to be premised on the assumption that you have physically removed the hard drive from the unix box and installed it on your linux box and are trying to mount the drive. If that's not what you are doing, all the advice you have gotten so far is irrelevant.

In kde you can also hit Ctrl-Esc to bring up the process table which lists all running processes. From there you can select and kill whatever process you want. It's similar to Ctrl-Alt-Del in windows but the process table window has a lot more options and displays a lot more info. I find it more convenient than running the console commands as the info is consolidated in a nice window display.

This is a much more complicated problem than you've been led to believe. Check out this article for details: http://www-128.ibm.com/developerworks/linu...lnxw02aFireBoot Now that's with a 2.4 kernel that uses devfs and the script at the end of the article references rescanning the scsi bus and restarting devfs. I don't know how you would modify that for a 2.6 kernel which uses udev instead of devfs. The key is creating a custom initrd.img which loads all the usb modules necessary to mount the usb drive and to rescan the scsi bus to get around some timing issues. Without that, you won't be able to detect your root filesystem on the usb drive. The above will give you a bootable mandiva install on a usb drive if properly implemented. However, I don't know how portable that would be. When thrown on a new box, you will have to go through a lot of hardware redetection which may or may not go smoothly; the standard mandriva distro wasn't really designed for this. The install on the lacie from mandriva is undoubtedly a customized version. You would probably be better off with a livecd and a usb flash drive for a persistent home. IIRC PCLOS has this functionality; it's based on mandriva and free: http://on-disk.com/product_info.php/products_id/69 I believe kanotix and knoppix also have this fuctionality.

Post your laptop make and model. Some laptop manufacturers connect the optical drive to the system other than through the standard ide interface which can cause problems. Older Sony Vaios are known for this. There are some cheat codes you can use to get the install to go but they don't always work.

Solarian, I don't think it's your graphics card as I have an nvidia FX-5900XT. I think you must be right about the fedora fonts; RH always had beautiful fonts as well. Haven't used it since RH9. Maybe it's time to give fedora a try. Let me know how it goes.

Apart from this board, the two things that keep me coming back to mandriva are font rendering and plf. On my hardware, no distro I've tried, and I've tried a lot, can render fonts as good as mandriva; they are just beautiful IMHO. Slackware is almost as good but anything debian based is terrible on my system. And I've tried everything I could find to tweak the font rendering in kanotix and other debians to no avail. If you're staring at a monitor for any length of time, crappy fonts can really get on your nerves. Also, the selection of packages in the legal grey area from plf is simply awesome, especially in the multimedia areas like video, dvd authoring/ripping/copying/viewing, codecs, etc.. Plf makes mandriva so convenient that it is hard to leave; without it I would have left long ago.

The easiest thing to do is put it in /etc/rc.d/rc.local. That's the last init script to run and it runs with root privileges. Just add your commands to the end of the script. You must have some timing issue re loading the usb modules; sticking the reload command in rc.local should work as everything else is loaded by the time it executes.

IIRC you will have to put your hdb back in your box for the above to work. During install mdv backs up your windows bootloader somewhere on hdb and can restore it with the above rescue command but not if hdb is gone.

You have no usb modules loading as has been noted before. IMHO you can fool around with fstab and udev all day and you'll get nowhere without the basic usb modules loaded. Check out your /etc/modprobe.conf file. It should have a line that looks like this: install usb-interface /sbin/modprobe uhci-hcd; /sbin/modprobe ehci-hcd; /bin/true If not add the above line and reboot.

IIRC mdv2006 comes with that driver included. It was part of the cvs xorg and a big reason they went with the cvs version instead of the more stable version.

Go to Kmenu>System>Monitoring>NetApplet. I think that's what you're looking for.

Corel Draw 9 used to be available on linux for a short time. Here's an old review of it dated November 2000: http://www.linuxplanet.com/linuxplanet/reviews/2573/1/ Actually, they ported the app to linux by using wine. Corel discontinued this experiment after a short while but you can still pick up Corel Draw for Linux on ebay.

You're right; looks like they are going to a one year support cycle for everything except their expensive corporate products: http://wwwnew.mandriva.com/security/productlifetime

A couple reasons to upgrade: 1. I don't know how much longer 10.1 will be getting security updates from mandriva but if they stop giving security updates, that's a good reason to upgrade to a newer supported version; 2. USB support for pen drives and other usb mass storage devices is much better starting with 10.2(LE2005) due to the adoption of HAL with udev, although I believe this can be backported to 10.1 using the contrib sources.

I don't think there is anything unusual about the ram/swap split. I'd be more concerned about the cpu spike however; that's not normal. To find out more about what processes are using your ram and cpu cycles open a console and run: $ top That gives a running tally by process of the % cpu and memory usage from highest to lowest. To get a more accurate account of memory usage run: $ free

You may want to take a look at this thread on the pclos board: http://www.pclinuxos.com/forum/index.php?topic=625.0 Pclos is mandriva based and there were problems getting the modules loaded for firewire drive detection. This may indicate similar problems are likely on mandriva. It's not a big deal; you just have to edit your config files to make sure the necessary modules are loaded at boot but you should be aware of the problem. I recently bough a hard drive enclosure from Apricorn and paid extra for dual firewire/usb connectivity. I personally think it was a waste of money as I rarely bother connecting the drive with firewire. If I had it to do over again, I would have gotten the usb2 enclosure only. Firewire is suppose to be a little faster but the real hassle is keeping track of two sets of cables. I have only the two firwire cables that came with the drive but tons of usb2 cables not to mention usb hubs and front side usb ports on the case. It's just easier to use usb. Unless you already have some significant investment in firewire technology, I wouldn't bother.

I haven't used Norton for some time as it was nothing but troubles for me and a resource hog. IIRC Norton runs an mbr check on boot to detect if any changes were made to the mbr. The purpose is to check for boot sector viruses. If Norton detected that the mbr had changed, it would give a warning message on boot and ask if you wanted to restore the original mbr from a backup. Again, this is all from memory. A couple things you can try while waiting. First, try booting windows in safe mode by hitting F8 at boot before windows starts to load. Second, if you made the Norton boot floppies, try booting off those and see if you can do something in there to stop it from halting the windows boot.

Open a console and run: $ su <enter root password> # passwd You will be prompted to enter a password and to confirm it. Type in whatever you want for your new root password.

Posts this file: /etc/fstab It's the text configuration file that controls the mounting and access permissions. If your "D" drive is NTFS, you can only have read permissions. Linux does not support writing to NTFS.