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