https://bugzilla.novell.com/show_bug.cgi?id=339640#c2 Robert Davies <rob.opensuse.linux@googlemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | --- Comment #2 from Robert Davies <rob.opensuse.linux@googlemail.com> 2007-11-15 09:49:54 MST --- The kernel update to 2.6.22.12 sorted out a number of problems : 1) SaX2 now found the Nvidia driver and configured it, with 3D 2) Networking issues which unfortunately made this Bugzilla be unreliable Bug reporting is much easier when have working workstation. To clarify this Bug report on the NVidia rpm's (and to ignore any SaX2 issues) I think : 1) Install OS 10.3 get 2.6.22.5-30 kernel, but Install use vesa driver not nv for unknown reason. 2) Update to secure system without worrying about 3D driver 3) Install NVidia 3D driver, using the Repositary 4) Run SaX2, fails because kernel module is not in any weak-updates directory, nor the currently running kernel modules Later, when you update to a newer kernel (in this case 2.6.22.12), the 2.6.22.5-30 update directory is noticed, and the weak update created. SaX2 now succeeds to load the nvidia driver, and will install 3D. So it looks to me, that the NVidia rpm's, are not doing the "magic" that the kernel update does, but merely installing files into /lib/modules/2.6.22.5-30/update, as that is what happened on my system. Furthermore they don't warn the Administrator that the currently running kernel is different from ones that the rpm's support. That is the bug I intended to report specific to NVidia rpm's. Perhaps this is meant to be working already? In which case reproduction would be painful due to need to re-install OS 10.3 from scratch, and replicate with same graphics card/monitor etc. Hopefully it is not a hardware specific installation issue, but a general one, that the rpm NVidia driver install does not understand the kernel update mechanism, and assumes 2.6.22.5-30 kernel. Thus expected and easily reproducible. Then a scheme to integrate with SuSE kernel rpm, would be less confusing and more robust. This is intended to try to make clear what I expect should just work, and what should cause warnings to Administrator. It is not intended to be a rigid spec. Scheme to support install & update vendor drivers eg) NVidia 3D : 1) vendor driver installs modules in /lib/modules/nonoss/<vendor> 2) Boot script into runlevel /etc/init.d/kernel-nonoss, checks that the running kernel has the weak update directory hack, if not populate it with symlinks; and set things up so the kernel can load each vendors stuff. The script can loop with multiple <vendor> simply using presence of /lib/modules/nonoss/<vendor>/boot scripts. The vendor script can log a problem, such as likely ABI incompatability ie. kernel changes from 2.6.22 SuSE to some User compiled kernel, or update of kernel major version (eg) 2.7, 3.0 etc). When booted kernel changes only would it need to run scripts stored in /lib/modules/nonoss/<vendor>/boot, Keeping vendor specifics next to the binary kernel driver, and allows it to check the kernel version is not too old or compiled incorrectly for the driver (zcat /proc/config.gz | egrep) so testing ABI compatability. 3) /lib/modules/nonoss/<vendor>/update could include specific vendor scripts required to make the 3rd party vendor stuff work after a kernel upgrade or freshen. Probably just doing similar to boot script, but can use the known fact of kernel upgrade to report to Admin better. 4) On initial rpm install of the vendor driver, the boot script /etc/init.d/kernel-nonoss can be forced to run as if the kernel changed, install the weak update directory, and then the vendor script. That reuses code, seperates Vendor stuff from SuSE kernel, providing a framework for SuSE kernel to support new vendor driver modules, and for vendor rpm's to work both when kernel is upgraded and on installation to an already up to date system. Final point, better error reporting to Admin, will improve the quality of Bug reports and reduce misunderstanding. Please disregard any SaX2 bugs in this report, as I have a seperate Bug Report on my SaX2 issues. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.