terry-s

Thanks for the hint. I still have the ...13 kernel as a boot option. Would the point that you're suggesting be achieved, if I boot again with ...13 and reinstall ...14? (I assume that means uninstall first and then install again.) If not, is there another specific kernel I should use instead? (I'm getting lost among all the kernel variants I'm afraid).

I'm updating a new mandriva installation, taking the kernel from -13mdv (legacy) to the bugfix -14mdv, and I'm getting a problem with kernel modules not working any more. So far, I did the update on a desktop machine (in order to solve the hangup bug when opening-up/closing down with a USB device plugged in). The new -14mdv kernel boots up fine and I get the GUI to start fine. (The box also shuts down without a hangup/freeze when the USB device is still plugged in -- which I understood to be the purpose of the bugfix. So far so good, but that's still not quite problem-free, becase in the presence of the USB device during shutdown, the video display goes to snow. It does at least shutdown though, and there was no 'improper shutdown' to cause complaint at the next bootup.) But one effect of the kernel update now is that the kernel modules (non-updated) 'complain' during init. They give exit messages with 'bad build' message no.8. Any ideas what can I do about this? In part it's been a good lesson already, because some of the non-functioning kernel modules identified themselves as not needed at all. So I could simply uninstall their packages without loss, for quicker boot/init time (e.g. not-needed drivers for not-present video hardware). However, the HAL daemon is one of the 'bad build' non-installers. I can't uninstall that (even for the sole purpose of re-installing) because urpmi would want to take away, uninstall, zillions of other important packages at the same time as it removes HAL. I'm afraid that if I let this happen, the cure would be worse than the disease.... I would like to get HAL back to order again (partly because in the present state the machine takes an appreciably longer length of time than it did before to recognise a newly-plugged USB device... I'm guessing that possibly the absence of the effective HAL kernel module could be contributory). Also, on another machine (laptop) I am contemplating doing the update, to the bugfix kernel -14mdv (legacy), the laptop is currently at -13mdv. But the laptop depends crucially on a kernel module for its wireless network connectivity. So I don't want to risk doing a kernel update there, until I'm confident that the question is solved of fixing up kernel modules to play happily with the new 'bugfix' kernel. I installed the stripped kernel sources for the new kernel when updating the kernel for the desktop -- because I guessed that might be important for getting kernel modules to play ok. But that doesn't seem to be effective at least on its own. I can't find any other instructions for adapting kernel modules to an updated kernel -- and any useful pointers would be appreciated. Terry [moved from Installing Mandriva by spinynorman]

Hi, I'm interested in this topic too, because I'm upgrading kernel from -13mdv (legacy) to the bugfix -14mdv, and I'm also getting a problem. So far, I did the update on a desktop machine (in order to solve the hangup bug when opening-up/closing down with a USB device plugged in). The new -14mdv kernel boots up fine and I get the GUI to start fine. (The box also shuts down without a hangup/freeze when the USB device is still plugged in -- which I understood to be the purpose of the bugfix. So far so good, but that's still not quite problem-free, becase in the presence of the USB device during shutdown, the video display goes to snow. It does at least shutdown though, and there was no 'improper shutdown' to cause complaint at the next bootup.) But one effect of the kernel update now is that the kernel modules (non-updated) 'complain' during init. They give exit messages with 'bad build' message no.8. What can I do about this? In part it's been a good lesson already, because some of the non-functioning kernel modules identified themselves as not needed at all. So I could simply uninstall their packages without loss, for quicker boot/init time (e.g. not-needed drivers for not-present video hardware). However, the HAL daemon is one of the 'bad build' non-installers. I can't uninstall that (even for the sole purpose of re-installing) because urpmi would want to take away, uninstall, zillions of other important packages at the same time as it removes HAL. I'm afraid that if I let this happen, the cure would be worse than the disease.... I would like to get HAL back to order again (partly because in the present state the machine takes an appreciably longer length of time than it did before to recognise a newly-plugged USB device... I'm guessing that possibly the absence of the effective HAL kernel module could be contributory). Also, on another machine (laptop) I am contemplating doing the update, to the bugfix kernel -14mdv (legacy), the laptop is currently at -13mdv. But the laptop depends crucially on a kernel module for its wireless network connectivity. So I don't want to risk doing a kernel update there, until I'm confident that the question is solved of fixing up kernel modules to play happily with the new 'bugfix' kernel. I installed the stripped kernel sources for the new kernel when updating the kernel for the desktop -- because I guessed that might be important for getting kernel modules to play ok. But that doesn't seem to be effective at least on its own. I can't find any other instructions for adapting kernel modules to an updated kernel -- and any useful pointers would be appreciated. Terry

Could it be something like a timing/staging issue, e.g. like the normal process for storing the sound levels, whatever that is, but operating at a wrong time, e.g. maybe something like before the sound hw/driver has properly started up, or after it has shut down, and some zeros are getting delivered to be stored in the soundlevel file instead of the proper levels? Terry

Glad it worked for you! T :D

Well I just tried it again, and it says GeForce3 - G... . There's a linebox that's not very big there, I can't get anything else to display with the keyboard keys, none of my keys will scroll anything and there's no mouse availability, but perhaps as you suggest there's a longer message somewhere in there, and if there is it could be mentioning GeForce4 as well, only I can't see it! :-)

I suggest storing the good sound settings (when you have fiddled enough to get them) into a private file of your own, using # /usr/sbin/alsactl store -f /etc/asound.state1 . (The normal file is asound.state, but in my case something is overwriting that with a pesky zero soundlevel.) Then, get these settings back to work at the end of each startup by adding the following line: /usr/sbin/alsactl restore -f /etc/asound.state1 into the users' startup script /etc/rc.d/rc.local. Make sure rc.local is executable if necessary with a chmod +x command. I assume your basic hw driver is after all getting loaded automatically with /etc/modprobe.preload , if not the alsactl stuff won't work. Good luck, Terry

The review seems puzzling and to me rather mean. With 2007.1, I've just come to Mandriva from Gentoo. As far as I can see, the linux distro isn't yet born that doesn't have some glitches, and to me 2007.1 is looking good overall. (I had tried a previous Mandriva release, and the DVD stubbornly wouldn't boot on my machine, so it got abandoned. I have to say, the rc3 CD for 2007.1 also seemed to need to be coaxed not to hang on boot (it took a bit of keyboard-hammering and warm-rebooting, maybe an uninitialised variable floating about somewhere!) -- but when it got there it was good.) I've been finding the software update tools very smooth and easy to use, the font management in particular is thoughtful and ingenious! I've been a fan of portage, and urpmi (even though lacking some of the user information and a good 'pretend' dummy install feature -- I was amazed when it downloaded and dumped instead of just saying what it 'would do') seems as nearly as close as makes little difference. I've found the forums a helpful place (thanks AdamW) and recalcitrant sound and video cards have yielded. So I'm impressed amd thinking of converting more systems if I can, and joining the club. Terry

Just to follow up the previous post, my similar problem with X/startx/GUI is now solved, a similar solution might work for you. (There was no possibility that bad media were to blame in my case.) If you want to try a similar solution: you might start by identifying which video drivers are essential for your card (general forum and Google search if you don't already have the info), check which relevant packages you currently have in your system using "# rpm -qa | grep <core of card name/type>"; uninstall all those video driver packages (using urpme from a # root prompt); reinstall just the ones you need (with urpmi from a # root prompt); and use "# XFdrake" to reconfigure. Details are in thread https://mandrivausers.org/index.php?showtopic=40843 . Good luck Terry

Thanks, Adam. That worked ok. The correct set of driver packages (for nvidia GeForce4 440MX) turns out to be the nvidia96xx series. The working rc3 install additionally had nvidia and kernel packages for the not-needed nvidia71xx and nvidia97xx series as well, but these clearly did no harm at that stage. The smarturpmi.sh update script (used for moving from rc3 to official release) for some reason unknown pulled in both of two (not-needed) dkms-nvidia??xx packages, for the 71xx series and 97xx series, on top of all the rest. That looks as if it did the damage. In regard to your specific advice, I used urpme to try to remove all the nvidia-lreated packages. urpme refused to remove the nvidia??xx-kernel packages, which are still there, and clearly they are doing no harm. urpme did remove all of the others, and after that, the dkms-nvidia96xx and nvidia96xx packages reinstalled ok with urpmi. I also used XFdrake (it indicated that it 'thought' my card was GeForce3), but I'm not sure that it had any work to do here, because xorg.conf had not been changed in the update and was still pointing to the nvidia96xx driver. Terry

But didn't alsaconf show you what the name of the module was? What name did you use (or see delivered on the screen) when you successfully got the sound hw working on a one-time basis? Whatever, it should be the same name for use with the startup loader. Good luck.

Help! Could someone clarify the current way of installing the special binary drivers for the video cards: There are so many 'nvidia'-related packages, and I can't find out where to see what they all do. There is a howto about nvidia binaries ( https://mandrivausers.org/index.php?showtopic=4567 ), it seems to have been written quite a long time ago. Is it all still current, or is it for doing something that the newer packages now also do? (I think I might have by far too many nvidia packages installed, but can't see how to thin it all out.) Thanks in advance Terry

Sounds likely to be a good step ... :)

I think you may want to look at /etc/modprobe.preload instead ... Terry

(No, it turned out that /etc/X11/xorg.conf had been conserved -- no cause there.) Terry

The name of the file in which to add the module name (see my previous comment): sorry, I think it should have been /etc/modprobe.preload , (not /etc/modules.preload). Terry

More diagnostics: Comparing with backup, /etc/X11/xorg.conf was not altered at all by the update. The module & module path specified in xorg.conf was for nvidia96xx, and both the path and the file at the end of the path had the same name before and after the update. But curiously enough, although the nvidia96xx package version had been changed during the update from -1.0-9631.3mdv2007.1 to -1.0-9631.6plf2007.1, the date of the module file had gone backwards in the update, so-- :in (updated partition) video driver ls -al /usr/lib/xorg/modules/extensions/nvidia96xx/*9631 : -rwxr-xr-x 1 root root 671548 Mar 13 15:43 /usr/lib/xorg/modules/extensions/nvidia96xx/libglx.so.1.0.9631* :(backup) video driver was ls -al /usr/lib/xorg/modules/extensions/nvidia96xx/*9631 : -rwxr-xr-x 1 root root 675436 Mar 26 17:51 /usr/lib/xorg/modules/extensions/nvidia96xx/libglx.so.1.0.9631* Could this be a bad update of the nvidia96xx package? Could I revert this package? On the other hand, other folks also are getting into trouble with starting up X/GIU, with the same kind of messages as mine (e.g. see thread https://mandrivausers.org/index.php?showtopic=38062 ), and they don't have an update history. So what to do next to find the cause of the trouble? Terry

I got a very similar problem, when there was no possibility that bad media were to blame. In my case there had been a successful install from CD, X/KDE had been working ok, this was followed by what would hopefully have been an incremental update (over the net -- no more CD burning) from 2007.1rc3 to 2007.1official. The update process used a script relying on urpmi, and among other things the process trashed some config files. In that or another way I am getting the same error when I try to start the GUI -- the one that tells of failure to load the module, the named module does not exist. The details are in thread https://mandrivausers.org/index.php?showtopic=40843 . I'm still looking for the cause and a solution. Maybe the next thing for me is look to see if /etc/X11/xorg.conf was trashed in the update -- compared with a backup that I kept on another partition. Best of luck anyway Terry

I had a similar issue. Part of my solution was to edit /etc/modules.preload (have I got that file location right?) to add another line to the list of modules, giving the name of the essential hw sound module that was found by alsaconf. That should then mean the basic sound hw driver gets loaded each time. If that isn't enough, you might also need to check that alsa is set up to be started on boot (my system is now set to start alsa on boot -- and it then claims to have stopped alsa again, but curiously enough that doesn't affect the sound). You will probably also need to go into KDE to 'enable' the sound system in KDE. And the last hurdle I had to jump to get some sound each time was that the sound was all looking fixed up, but no sound was coming out, and I found that for some reason still unknown, on every startup, the PCM playback channel level was being reset to zero sound volume! (I found that one out by fiddling with alsamixer and alsactl, to examine, set and store sound levels.) In the end I had to fix it with a kludgy workaround script in rc.local, to make sure the relevant channel level was hoiked back up to an audible level by doing an 'alsactl restore -f' from a reliable sound-state file, at the end of startup! I hope this helps. Terry

Additional info: 1: I have found backup files that I kept from before trying the update from 2007.1rc3 to 2007.1official. They allowed me to address/fix problem number 1, about the bash configuration: I managed to restore the config files (in '/root/') for the 'root' user -- because comparison with backup showed that these had somehow been erased during operation of the smarturpmi.sh update script. This restoration now allows the root user to call 'urpmi' without giving the full path, like before the update. (Also, the original X11-related path entry is also included back in the root user path, and I wondered if that might help with the GUI problem and finding the nvidia driver, but it doesn't.) The problem with the GUI and startx is still there. 2: The backup also tells me a bit more about the package history: out of the nvidia packages listed in the previous message in answer to your 'rpm -qa' question, two were newly added during the update: dkms-nvidia-71xx and dkms-nvidia-97xx. Four of the other nvidia packages (the ones now with 'plf' in their names) were slightly later numerical versions of packages in rc3. Before the update, there had been earlier 'mdv' versions of these packages. Maybe this offers a clue about what I could try next? Thanks in advance for any hints. Terry

Hi, neighborlee, can you say which partitions do you have on your hard-disk, and where did you 'put' Mandriva and your other OS? Which option did you choose to install grub? Can you still boot into your other OS? Did you make a 'grub' floppy disk? (fwiw, although I'm new to Mandriva, I've used grub quite a lot, and find it v reliable. I double-boot with another OS but I find that one awkward to tangle with, so I've installed a useful boot manager for that OS, it has a friendly GUI which can easily be used to set a handover to another OS on another partition. When making a linux install, e.g. recently Mandriva, I always leave the MBR (on hda) unchanged. When the option for installing the linux bootloader comes up, I avoid the usual default option 'hda', and instead choose to put grub on to the initial sector of the partition holding the linux distro (hda3). In that position it's a secondary boot loader. Then, before first boot of the linux distro, e.g. Mandriva, I boot the other OS and use the UI for the main bootloader to set up a new handover option for Mandriva. Then, on next reboot, the boot manager shows an option (or even a default) to go over to the grub secondary boot loader for Mandriva. This keeps all settings and boot arrangements for the linux OS on the linux partition itself, no need to mess with the MBR, and only adds a couple of seconds to the boot process. Has worked reliably every time.)

Thanks: here they are: "# rpm -qa | grep nvidia" yields:--- nvidia71xx-kernel-2.6.17-13mdvlegacy-7184-1mdk nvidia96xx-1.0-9631.6plf2007.1 dkms-nvidia71xx-1.0-7185.1plf2007.1 nvidia97xx-kernel-2.6.17-13mdvlegacy-9755-1mdk dkms-nvidia97xx-1.0-9755.2plf2007.1 nvidia97xx-1.0-9755.2plf2007.1 nvidia96xx-kernel-2.6.17-13mdvlegacy-9631-1mdk dkms-nvidia96xx-1.0-9631.6plf2007.1 nvidia71xx-1.0-7185.1plf2007.1 "rpm -qa | grep kernel" yields:-- nvidia71xx-kernel-2.6.17-13mdvlegacy-7184-1mdk slmodem-kernel-2.6.17-13mdvlegacy-2.9.11-1mdk ndiswrapper-kernel-2.6.17-13mdvlegacy-1.21-2mdv2007.1 ati-kernel-2.6.17-13mdvlegacy-8.34.8-1mdk hsfmodem-kernel-2.6.17-13mdvlegacy-7.47.00.03full-1mdk nvidia97xx-kernel-2.6.17-13mdvlegacy-9755-1mdk kernel-legacy-latest-2.6.17-13mdv nvidia96xx-kernel-2.6.17-13mdvlegacy-9631-1mdk kernel-legacy-2.6.17.13mdv-1-1mdv2007.1 hcfpcimodem-kernel-2.6.17-13mdvlegacy-1.10full-1mdk madwifi-kernel-2.6.17-13mdvlegacy-0.9.2-1mdk kernel-source-stripped-2.6.17.13mdv-1-1mdv2007.1 Terry

I tried to update from 2007.1-rc3 (was working ok) to 2007.1 (official release), and now I can't get X/KDE running any more. Also, the path config info (at least for 'root') looks wiped during the update. Symptoms: (1) # urpmi now gives error "bash: urpmi: command not found" but # /usr/sbin/urpmi --auto-update works as intended (and it confirms all media and packages up-to-date). (2) When I try to get X/KDE back with "$ startx" it fails with errors as follows:- (EE) failed to load module "nvidia" (module does not exist, 0) (EE) no device detected. Fatal server error no screens found XIO: fatal IO error 104 (connection reset by peer) on X server (:0.0) after o requests (0 known processes) with 0 events (then back to the $ prompt). My machine has an Asus A7N8X-X mbd with nVidia GeForce4 440MX AGP video card. Background is that I first installed 2007.1-rc3 shortly before 2007.1 official was released. Install medium was the 'One' live CD. Installation went ok (fixing glitches of hang on startup and failure to power-down). After install, I used package download sites offered by the 'smart urpmi' website for 2007.1-rc3 cooker, and installed the media sites from a root prompt # with the smart urpmi site's own 'smarturpmi.sh' script. When installing software from these sites using the GUI Mandriva Control Center tool, I included downloads of what seemed appropriate nvidia (binary I believe) driver package. All seemed to go very well, video was responding very fast. After release of the official 2007.1 distro, and after reading hints on these forums, I tried to update from 2007.1 rc3 (cooker) to 2007.1 official release by using again the smarturpmi.sh script provided by the smart urpmi site, this time 'tuned' to refer to official 2007.1 release-sites. The script wiped the 2007.1-rc3 media- site-info ok, and uploaded new media-site-info ok, and it went on to update about 38 packages -- including some nvidia-related ones. (I did this from a # console prompt without X running.) There were several 'additional info' messages during the update, they flew past too quickly for me to read them. urpmi now reports that the media and packages are all up-to-date. Then the main problem became clear -- no X/GUI, as mentioned above. Reboot doesn't enable getting back into X/GUI. I wonder which config files are likely broken? is it more broken than that? how do I get back into the GUI? Thanks for any hints. Terry