pmpatrick

Have you installed all your updates? If not, do so now and see if that helps. IIRC there were some updates for mdv2007.1 specifically dealing with HAL.

From the kmenu go to System>Configuration>Configure Your Computer and type in your root password when prompted. This will bring up the mandriva control center(mcc). In mcc go to System>Enable or disable system services. Look for the entry for "haldaemon". Make sure the "on boot" box is ticked. If the hal service is not currently running, hit the "Start" button to get it going now without rebooting. See if that helps.

What type of hard drive did you install, eg. pata, sata, scsi, etc? HAL usually only comes into play for removable storage devices. How did you partition and format the new drive? Also, run this in a console and post the output: $ su <enter root password> # fdisk -l That should list all the hard drive partitions that your system recognizes, whether mounted or not. Finally, post your /etc/fstab file. fstab controls the mounting of partitions.

You can try Wifi Radar. Here's a description: I've used this on Vector linux and other slack based distros and it is really nice. Don't know about cpu consumption/power drain from Wifi Radar but I like it better than the Kwifimanager which never seems to work right for me with ndiswrapper. I know there's an rpm for mdv2007 and assume one exists for mdv2007.1.

It's probably a timing issue; the network isn't fully up when the mount is attempted. That's my best guess. To test, you can put these commands at the end of /etc/rc.d/rc.local: cd /etc/rc.d/init.d/ ./netfs restart rc.local is the last init script to run before X starts so if it is a timing issue putting those commands in rc.local may fix it.

Unless you specifically know what code in the kernel is causing the problem for grub, and it is not the naming convention, it is impossible to intelligently discuss whether the kernel changes causing the problem are worth the aggravation caused to other developers. As I previously stated, there may be very good reasons for those kernel changes and those changes may significantly improve the kernel. I can appreciate the aggravation you have with the moving target the 2.6 kernel has become. However, if you want to use the linux kernel, that's the development model you're stuck with. And if grub wants to claim it can boot linux, their devs should deal with it as well as I'm confident they are.

My point is that I don't think it's solely a problem with kernel changing naming conventions since mdv2007.1 and the earlier versions of ubuntu I linked to used the standard libata with the usual hdx,sdx naming conventions and all those distros report the same aberrant behavior in some mixed environments. As I eluded to above, I believe it must be a problem with at least some linux kernels that used standard hdx,sdx naming, blocking grub from properly communicating with the system bios when grub is installing with the kernel loaded. There may be very good reasons for this behavior in the kernel related to security, stability, whatever. I really don't know, but I don't think it's realistic to expect the kernel devs to rewrite the kernel so the current version of grub works more consistently. The onus should be on grub to adapt to the current characteristics of the linux kernel, just like everybody else. Hopefully, grub 2.0 will clean this up.

Then how do you explain this: https://mandrivausers.org/index.php?showtop...518&hl=grub That's with a stock mandriva 2007.1 kernel. And that problem apparently exists on all debian based distros and suse as well. This is a bug in grub IMHO. You get inconsistent naming by grub in some mixed environments when the linux kernel is loaded as compared to when it is not. Apparently, the linux kernel prevents grub from properly communicating with the system bios when the kernel is loaded resulting in the inconsistent behavior. Now you can blame that on the kernel if you want but to my mind, if the grub devs want to claim grub is a linux bootloader, grub should be able to work with the linux kernel.

mindwave, it's not as big a deal as you might think. I believe what Ixthusdan is referring to is an upgrade install. You put in your mandriva install cd/dvd, boot up with it and select the "upgrade" option. The install routine will detect the presence of the prior install and offer the upgrade option. You don't select any new software to install and the whole deal can be done in 15 minutes. Essentially, all the install routine does is redetect your hardware and reconfigure for that new hardware. I've used this method myself when changing mb/cpu and it works great.

How about: # chmod -R 777 <mount point> with the partition mounted. That will give the world rwx permissions on the partition. That should be OK if you are the only one on the computer.

That sums up my experience as well. Other than that, I can't really get excited about bootloaders. If it boots my OS, I'm happy; if not, I have to fool around with it until it does. I'm probably a little better at fooling around with lilo since I've used it longer but grub is pretty easy to hack once you get the hang of it.

There used to be a bug in grub related to ram. IIRC grub must have certain specific memory registers open in ram in order to work. If something else gloms onto those registers, grub will not load and you will get an error 1 message. This frequently was a problem with onboard graphics adapters that used some of the ram for graphics memory. The bios would frequently assign the registers needed by grub to the graphics adapter. I thought that bug was fixed but perhaps not. Lilo is not so fussy and will load into ram wherever there is space available. waredevil, check out my post here re my adventure with grub: https://mandrivausers.org/index.php?showtop...518&hl=grub I feel your pain.

It's a conflict issue with the open source wireless driver "bcm43xx". Once this thing loads, it prevents ndiswrapper from creating the wlan0 interface. I had the identical problem on my laptop. You can see the bcm43xx driver listed in your lsmod output so it's loading at boot. The problem is bcm43xx loads by default and is set by mandriva and other distros as the default driver for all broadcom chipset wireless cards. Unfortunately, bcm43xx is very buggy in my experience and doesn't work on many boadcom based wireless cards, mine included. Ndiswrapper works much better in my experience. So much for the diagnosis; now for the cure. You have to stop bcm43xx from loading at boot. Then when ndiswraper loads, it usually creates the wlan0 interface(sometimes it's designated as "ethx" depending on which version of ndiswrapper and udev rules) and your network will come up without having to recreate everything every time you boot. This is called blacklisting a driver and different distros have different ways of blacklisting. In mandriva, you have to edit /etc/modprobe.conf and you need to be root to do that. Open a console, and run: $ kdesu kwrite /etc/modprobe.conf Enter your root password when prompted and kwrite will come up with root privileges displaying modprobe.conf. Add this line to modeprobe.conf: blacklist bcm43xx Save the changes, reboot and see if the bcm43xx driver is not loaded by running: $ lsmod | grep bcm If successful, run as root: # iwconfig that will list all network interfaces and tell you which one(s) have wireless extensions. It'll probably show wlan0 but on my laptop the wireless interface on mdv2007.1 is listed as eth1 when using ndiswrapper with broadcom . I'm curious to see what yours shows. At any rate, once you know the wireless interface name you can reconfigure it if necessary in mcc and it should stick. It may work fine without doing anything further since you already have a ifcfg-wlan0 config file but you may have to reconfigure if the wireless interface has changed names.

Is your ndiswrapper module loading on reboot? Check the output of: $ lsmod If ndiswraper is there, try starting from the command line and see what you get. As root run: # ifup wlan0 Unless your /etc/sysconfig/network-scripts/ifcfg-wlan0 file is disappearing on reboot, it should bring up wlan0. If your ifcfg-wlan0 file is surviving a reboot and you can bring up the network with ifup wlan0, there is probably some timing problem. Post back your results.

For determining whether there is anything physically wrong with the drive, your best bet is to determine the manufacturer of the drive and download their hard drive diagnostic utilities. Seagate and Maxtor have them on their website and I believe Hitachi does as well. These, and many other, utilities have been gathered in a single bootable cd called the Ultimate Boot CD(UBCD): http://www.ultimatebootcd.com/ It's a wonderful tool to have handy.

The filesystem on sdb1 is probably corrupt or at least mandriva thinks it is. Have you had any hard shutdowns with sdb1 mounted? You may want to try a livecd and see if sdb1 can be read from there. If you have the same issue with a live cd, you know the filesystem on sdb1 is corrupted. Here's an article which goes into recovering data on a corrupted ext2/3 filesystem: http://aniraj.blogspot.com/2006/05/data-re...-corrupted.html It goes into the technique of using dd to make an image of the corrupted partition and working on that instead as well as mounting on backup superblocks.

Then it's a gnome/nautilus problem, not a mounting problem. When you say you can't see anything in nautilus, exactly what do you mean? What happens when you navigate to /mnt/win_c in nautilus? Also, as root try running: # draksec The draksec window will come up showing you the security level. Draksec is mandriva's security hardening application. When set too high, it causes all kinds of access problems with windows partitions. Try resetting it to "Standard", reboot and see if the problem goes away.

The asterisk is nothing to be concerned about; it just means that partition has been marked as "bootable". You should see the asterisk under the "Boot" column in the fdisk output. With the fstab entry I gave you before what do you get when you try to manually mount the partition: $ su <enter root password> # mount /dev/sda1 Or you could try a completely manual mounting with: # mount -t ntfs /dev/sda1 /mnt/win_c

Try making the line: /dev/sda1 /mnt/win_c ntfs defaults 0 0 and see if you can access the partition through /mnt/win_c after remounting with: $ su <enter root password> # umount /mnt/win_c # mount /mnt/win_c # ls /mnt/win_c The last "ls" command should list the contents of your NTFS vista partition. If you can access the partition through the above ls command but not as an ordinary user in konqueror, you probably have your security setting set too high. Post back and I'll go into how to reset that so ordinary users can access your vista partition.

Neddie, that's another problem specific to grub. How grub enumerates the drives, i.e. which one is hd0, hd1, etc, can change depending on the state of the system. See my related post on this subject here: https://mandrivausers.org/index.php?showtop...518&hl=grub You seem to have run into a similar problem with the external hard drive, i.e. it shifts from hd1 to hd0 at boot time. I'm wondering whether the same problem would exist with lilo.

The problem is with your initrd as noted in the ibm article. You have to rebuild it with the necessary usb and scsi drivers in order to mount your root partition on the usb hard drive at boot time. Some distros seem to include these drivers in their standard initrd but most don't. If they do, you will be able to install and boot from the usb hard drive. There's no easy way around this; if you don't have the drivers in initrd to mount your root partition at boot time, you will get a kernel panic every time. Note also in the ibm article they further discuss the timing issues and the need to rescan the scsi bus. That dealt with 2.4 kernels using devfs. It's not applicable to 2.6 kernels using udev, but there may be similar issues or not. You would have to rebuild your initrd and see if it worked to find out for sure.

You are going in the right direction. IIRC in the 2.4 kernels there were also timing issues requiring a rescanning of the scsi bus as well; don't know if that is still a problem with the 2.6 kernels. Here's a good, but somewhat dated article from IBM on booting linux from a usb or firewire drive: http://www-128.ibm.com/developerworks/linu...lnxw02aFireBoot

Those types of errors can occur if you compiled the vboxdrv module against a kernel source that is different from the kernel you are running. Check the output of: $ rpm -qa | grep kernel and: $ uname -a Make sure the kernel source you have installed corresponds to the kernel you are using.

Post the output of: # lsmod and also post your /etc/modprobe.conf and /etc/sysconfig/network-scripts/ifcfg-eth0. lsmod will give all modules loaded so we can see if the proper module for your nic loaded which I believe is 8139too. Modprobe.conf will show what modules should be loading and ifcfg-eth0 is the network configuration script. Finally, post the output of: # ifconfig That should give the current status of all your network interfaces. Note, both the above commands must be run as root which I assume you are familiar with since you apparently ran ifup from the command line. If you're not sure what I'm talking about post back and I'll go into more detail. You may also want to post how you are connecting to the internet since I assume that is your real problem. With this info we should be able to figure out what is going on.

I believe it comes in a package called "kdetoys".