pmpatrick

Remove the line in fstab for sda5 that you created. Check your security level per my post in this thread: https://mandrivausers.org/index.php?showtop...amp;hl=security Try resetting your security to "Standard" and rebooting. That seemed to do the trick in the above thread.

You can also take a look at knowit: http://knowit.sourceforge.net/ and TuxCards: http://www.tuxcards.de/ I believe both are available in the3 contrib urpmi repo.

If you have your install cds/dvd you can try doing an upgrade install over your present mdv installation. It might recreate your /lib for you without too much thinking.

All three of those files are just dynamic links to the actual library files on my system: libdl.so.2 --> libdl-2.4.so libc.so.6 --> libc-2.4.so librt.so.1 --> librt-2.4.so If you have the files on the right of the arrow in your /lib, you should be able to recreate the links by running the following as root: # cd /lib # ln -s libdl-2.4.so libdl.so.2 # ln -s libc-2.4.so libc.so.6 # ln -s librt-2.4.so librt.so.1 or in general: # ln -s <target> <link> Edit: If you have a good livecd you can check your /lib for the above files and recreate the links per the above.

There has just been too many kernel problems with truecrypt and the devs don't seem to welcome any input from the larger OSS community, at least that's what I've been reading on some debian boards. As a result, I've started using cryptsetup with LUKS as outlined in this article: http://feraga.com/library/howto_use_crypts..._luks_support_0 This has native linux kernel support and I've run into far fewer problems with it. It's worked fine on mandriva since 2005, pclos, kanotix/sidux. Had some trouble with slackware but that was probably due to not having the necessary kernel modules compiled in my custom 2.6 kernel. Check out this wiki for more on supported distros: http://www.saout.de/tikiwiki/tiki-index.ph...roSupportStatus Also, recent versions of FreeOTFE for windows appear to support linux created LUKS encryption although I haven't tried this myself: http://www.freeotfe.org/

I'm inclined to think so, at least with kde and probably gnome as well. I believe most window managers and DEs have to update the status of the filesystem every few seconds to keep current. I know I sometimes see a lag in kde when using konqueror and doing a lot of file operations at the command line.

Not here. The broadcom bcmxx driver hasn't worked with my card on any distro I've tried; I always wind up going with ndiswrapper which works fine. I've come to hate that driver.

I don't have a problem with what they did. I'm just offering it as an explanation for the discrepancies in the md5sums of the isos from unofficial sources.

I know that mandriva's early seeders program got really screwed up this time. The original early seeder isos were downloaded about two weeks ago and then everyone received an email from mandriva saying the isos were changed at the last minute. As a result, the previously downloaded isos were no good for early seeder purposes. It could be that some of the ftp sites you mention are distributing the old mdv2007.1 isos from the early seeders program. I only have the powerpack dvd iso so I can't directly check the md5sum.

I get the same messages in mdv2007.1 re ipv4 and ipv6. Not sure what it's about. For a different distro to try, I'd suggest slackware. It's much more command line/old school than most distros. The init configuration is more like BSD than linux. Also, most distros today seem to be based on either slackware, debian or RH so knowing the slack way can come in handy. Finally, nothing seems to run faster than slackware and that includes source based distros like gentoo.

The install is fine. It was just a boot loader problem with grub and it will only occur with certain hard drive configurations I suspect. I had grub installed on my first pata drive, hde and mdv2007.1 installed on my first sata drive on sda12. I have another pata drive on hdg and a second sata data drive on sdb. I suspect that grub tends to give the drive whose mbr it's installed on the designation hd0 so hde was hd0 in all conditions. At boot time it must have looked to the bios setup hard drive boot sequence and doled out the hdx numbers to the other drives based on their bios boot order. That information is apparently lost or inaccessible after the kernel loads and if you do any grub operations then, the hdx numbers are assigned differently. That's clearly the source of the problem. You are looking at a situation where you have multiple hard drives, some pata and some sata. That's where the problem is likely to occur.

Just installed mdv2007.1("Spring Edition) on my test partition and in general. I am favorably impressed. As some of you may know, mandriva has moved away from lilo in mdv2007.1 and is now using grub for the default bootloader. Although I've used lilo for over seven years and am familiar with it, I decided to take the plunge and give grub a try. Big mistake. On reboot after installation, I wound up with an error 22 message and a blinking cursor. Couldn't even get to a grub prompt to see what was going on. Wound up restoring my lilo from my mdv2007 install and creating an entry for mdv2007.1 there. Rebooted into mdv2007.1 without a problem but decided to investigate what went wrong with grub. Thought I'd pass along what I found as I've encountered the identical problem in debian based sidux. This is a problem you may encounter if you have both pata and sata drives in your system and use grub. It is a problem with grub and not mandriva as the same problem has been reported on ubuntu: https://bugs.launchpad.net/ubuntu/+source/grub/+bug/8497 and mepis: http://www.mepis.org/node/12536 And I've seen the same thing on sidux. Essentially, the problem arises from grub's attempt to identify and label the bootable hard drives on your system. When you have both sata and pata drives, this identification occurs differently at boot time than after the kernel is loaded. To illustrate, I have two pata hard drives on hde and hdg and two sata drives on sda and sdb. mdv2007.1 is installed sda12. During installation, grub designated sda as hd2 with root at (hd2,11) and that was reflected in menu.lst. I confirmed this again after I rebooted by running: # grub grub> find /boot/grub/stage1 and sure enough, it came back with (hd2,11). I reinstalled grub but made a grub boot floppy so I could investigate things if I got another error 22. Sure enough, that's exactly what happened, error 22. Rebooted with the grub floppy I made and ran from the grub prompt: grub> find /boot/grub/stage1 but this time it came back with (hd1,11). That, in a nutshell is the problem. I believe, I found the source of the problem as well. By checking device.map, it is clear that with kernel loaded which is the state the system is in when grub is installed during the installation, the hard drives are enumerated as follows: (hd0) /dev/hde (hd1) /dev/hdg (hd2) /dev/sda (hd3) /dev/sdb In short, the pata drives come first followed by the sata drives. However, at boot, the bios setup seems to control this enumeration. In my bios setup, I had the boot order for the hard drives set as follows: hde sda hdg sdb and using my grub boot floppy, I confirmed that the enumeration from the floppy grub prompt was: (hd0) /dev/hde (hd1) /dev/sda (hd2) /dev/hdg (hd3) /dev/sdb I could boot from the grub floppy with: > root (hd1,11) > kernel (hd1,11)/boot/vmlinuz root=sda12 > initrd (hd1,11)/boot/initrd.img > boot But running grub from a console after booting gave: grub> find /boot/grub/stage1 (hd2,11) I went back and changed the boot order in my bios setup to: hde hdg sda sdb and booted with the grub floppy. Then the enumeration changed in line with mdv2007.1: (hd0) /dev/hde (hd1) /dev/hdg (hd2) /dev/sda (hd3) /dev/sdb I booted back into mdv2007.1 reinstalled grub and rebooted. It finally worked. The moral of the story, if you have both pata and sata drives and get an error 22 with grub, get ready to spend several hours playing with your new and improved Grand Unified Boot Loader. :blink: [moved from software - arctic]

Please post the native resolution of your new monitor and the ouptut of the following command run as root: # 915resolution -l That should list your intel graphics chipset(probably 855) and the currently supported resolutions. It's a lengthy file, but we will probably need to see your graphics configuration file as well. Please post /etc/X11/xorg.conf.

The ifconfig output shows the network interface for your nic, eth0, is not being created. That would generally indicate an improper driver module for your nic or the module not loading. Just so I can confirm you have your chipset on the nic right, please post the output of: $ lspci | grep Ethernet If that gives no output, just post the output of: $ lspci That will give you everything on the pci bus. Note, everyone is assuming that you have a standard nic in a pci slot or one onboard built into the motherboard. If that's not the case or if you have multiple nics, please indicate that.

I've seen several reports that Dell is going to start selling preloaded linux laptops: http://www.desktoplinux.com/news/NS8436091466.html Given Dell's stated approach in the above article, you could probably get most major distros to run on one of those dell linux laptops without too much trouble.

Let's start with the basic stuff. Post what nic you are using and the output of: # ifconfig The above must be run as root and will give info on all network interfaces that have drivers loaded. Getting a little deeper, post the contents of /etc/sysconfig/network-scripts/ifcfg-eth0 and /etc/modprobe.conf. The first is the network configuration script that is actualy automatically edited when you use mandriva control center and the second is one of the files that determine what driver is loaded for eth0. In modprobe.conf, look for a line that says "alias eth0 <module name>". You can confirm that your nic module actually loaded by running as root: # lsmod which will print out all loaded modules. Finally, if the correct module is loaded for your nic and eth0 shows up in ifconfig, try pinging your router with: $ ping -c3 192.168.1.1 That's the ip for all the linksys routers I've used unless you have manually set it to something different. If you can ping the router, this would confirm that you have the correct driver loaded for your nic and it's working properly. In that case you will need to take a closer look at ifcfg-eth0 or it could be a dns problem.

According to these instructions: http://madwifi.org/wiki/UserDocs/FirstTimeHowTo you shouldn't have to do ./configure before running "make". I would reread tyme's post; that error message is usually associated with not having your kernel source installed. No kernel module will compile without the kernel source. Finally, the madwifi rpm that comes with mandriva may not be available in the free edition and it's not very good anyway. Compiling the latest madwifi driver is a better course than using the mandriva rpm IMHO.

Try rebooting with the lower security setting and see if it works. If not, I think you would have to delve into the udev rules in /etc/udev/rules.d which are all XML configuration files. Those files should control mounting behavior. You could also try making yourself a member of the "disk" group since any usb drive device files generated by udev would probably be members of the "disk" group.

What did you set your security level at? If you're not sure, open a console and run: $ su <enter root password> # draksec Mandriva's graphical security application, draksec, will open a window. Try reseting your security level to "Standard" and see if that helps. The problem is that you are dealing with external hard drives here which don't have persistent settings in fstab that you can edit. Such drives are dynamically mounted when attached and powered on and a transient fstab entry is auto-generated for the device according to certain "udev rules" in mdv 2005 and 2006. For 2007, there is no entry in fstab for dynamically mounted drives so there shouldn't be anything to edit. When the device is removed, the fstab entry should disappear. There may be some ways around this problem but I'm hoping that resetting your security level to "Standard" will solve the problem.

There's a program called KeyTouch that can help configure a lot of those extra keys on many keyboards. You can download the rpm here: http://rpm.pbone.net/index.php3/stat/4/idp...0.i586.rpm.html I use it on my Logitech keyboard and it works great. Your particular model is listed as supported.

When opening the burned disk in windows explorer you should see a directory tree with some subdirectories, not just a single iso file. If you are not seeing that, either the disk has not been properly burned or your optical drive cannot read your cd-r or dvd-r media for any number of reasons. Some drives just have compatibility problems with certain brands of media. If you have access to another computer, see if that box can read your burned disks. Also, have you had any other burning problems in windows?

Could be the display manager locking up or blocking the attempt. Rather than fool with it, reboot and hit the Esc key when you see the lilo boot selection screen. That will take you to a boot prompt at which you should type: linux 3 and hit the Enter key. In the above, "linux" refers to the lilo boot entry which by default is "linux" in mdv2007. If you've customized this lilo label, just use that instead of "linux". The "3" obviously refers to run level 3 and causes the system to boot to a non-graphical command line login, i.e. X is never started so you don't have worry about shutting it down before doing your nvidia driver installation. Just login as root at the login prompt and do your installation.

Get a livcd like knoppix that has gpart and parted included. Parted has some partition recovery tools that you can try and gpart is a utility for reconstructing damaged or deleted partition tables. The general procedure is described in this howto which is geared toward ubuntu but it can be adapted for knoppix: http://ubuntuforums.org/showthread.php?p=2210436 Here's another link that deals with gpart usage: http://enterprise.linux.com/enterprise/06/...d=47&tid=89 It doesn't work all the time and these tools don't work so good with recovering extended partitions, but it's worth a shot.

Yes, mcc can be started from the command line but you get a primitive ncurses version that you can only navigate with the keyboard, i.e. no mouse support. It still works though. If you are just reconfiguring your graphics setup, you can also run: # XFdrake to bring up an ncurses version of the graphics setup portion of mcc.

tyme, the method in your link doesn't work with LE2005/mdv10.2. You have to do everything they say in the link plus add these steps: # rm /etc/localtime # ln -s /usr/share/zoneinfo/America/<insert your city timezone> /etc/localtime You have to do this for all earlier mandriva/mandrake systems as well as earlier RH based systems. In these systems, /etc/localtime is a binary instead of a link to the appropriate time zone info file. The above two steps remove the localtime binary and create the appropriate link.