kernel3 + nvidia + squeeze

[rendegast]

Eine kürzliche Einschätzung bzgl. kernel 3 unter squeeze

nvidia bräuchte die Headers,
im Falle des debian-Kernels zieht das den gcc-4.5 und im weiteren die libc aus testing / sid.
Daher leider kein nvidia + (debian) kernel 3 unter squeeze.

muß ich korrigieren.



Ich konnte den kernel 3.0.0 debian + dessen header in squeeze ja installieren.
- dummy-Pakete für multiarch und gcc-4.5, da sonst libc6 2.13, damit testing ins System kommt.

Code: Alles auswählen

ii  gcc-4.5-dummy                           4.5-dummy          dummy fuer die header ab kernel 3.0.0.
ii  multiarch-support-dummy                 1.0                dummy fuer sid-libasound2 fuer sid-qemu-system

Aber eine Bau des nvidia 270.* mittels CC=gcc-4.4 scheiterte,
was ich aufgrund nichtssagender Ausgaben auf Probleme mit dem fehlenden gcc-4.5 schob.

Jetzt einfach den kernel 3.0.4 vanilla kompiliert, gcc-4.4, Target 'deb-pkg', problemlos.
Aber auch hier scheiterte der nvidia 270.*, Meldung wieder sinnlos.
-> Verdacht, das Problem liegt nicht auf Kernelseite.

Ein Versuch mit dem neuesten 280.13 folgte, mit Fehlermeldung:
Dem mit 'deb-pkg' generierten linux-headers fehlt (zumindest für nvidia) einzig die Datei Makefile_32.cpu.



Eine Gegenprobe mit dem 3.0.0-1_3.0.0-3 debian und dem 280.13 verlief dann auch problemlos
in Bau und Funktion.






----------------------------------------------------------------------------------------------
-> Vielleicht ließe sich linux-3.*.* scripts/package/builddeb hier ja praktikabler erweitern:

Code: Alles auswählen

...
# Build header package
(cd $srctree; find . -name Makefile -o -name Kconfig\* -o -name \*.pl > /tmp/files$$)
(cd $srctree; find arch/$SRCARCH/include include scripts -type f >> /tmp/files$$)
(cd $objtree; find .config Module.symvers include scripts -type f >> /tmp/objfiles$$)
...

'-name Makefile' -> '-name Makefile*' wären nur einige kB.
Smart wäre eine Lösung, die oben gefundene Dateien noch auf ihre 'include' abklappert.

[Alternativende]

Hallo,
das ist mir Zuhause leider auch schmerzlich aufgefallen da ich nun leider kein funktionierendes Gnome mehr habe .
Verwenden tue ich logischerweise den aktuellen Kernel aus unstable und die Nvidia Treiber (aktuell 280.13). Also entgegen dem was du geschrieben hast funktioniert es leider nicht bei mir.

Ein aptitude reinstall nvidia-kernel-dkms bricht leider mit folgender Meldung ab:

Code: Alles auswählen

Module build for the running kernel was shipped since the kernel source for this kernel does not seem to be installed.

Natürlich sind die Kernel-headers alle installiert.

Was kann ich da derzeit tun?

[rendegast]

Ich benutze nicht die nvidia-Pakete aus non-free (<-> dkms),
sondern die nvidia-installer *pkg0.run von
ftp://download.nvidia.com/XFree86/Linux-x86/
ftp://download.nvidia.com/XFree86/Linux-x86_64/


dkms hätte das Problem, daß es den kernel-gcc-4.5 des debian 3.0.0 verwenden will?
Das müßte ich nochmal testen,
dann auch die Funktion des dkms mit dem vanilla-Headern.

[Alternativende]

Hmh ja das wollte ich eigentlich vermeiden, weil ich sonst immer manuell bei einem Kernelupdate den Treiber neu installieren muss und mir die neuen Treiber eigentlich nichts bringen, nur leider geht es ja im Moment überhaupt nicht.

[rendegast]

So, auch das durchgespielt, und es liegt bei Dir wohl an der "Fehlinterpretation" der gcc-Version.

Beim Installieren von nvidia-kernel-dkms (testing/sid) werden die Kernel in absteigender Reihenfolge versucht zu verarbeiten:
3.0.0-1 / 3.0.4
(2.6.39-(bpo.)2)
(2.6.32-5)
und läuft direkt beim ersten Kernel durch den nicht existierenden gcc-4.5 an die Wand.
EDIT Die "älteren" 2.6er würden nicht mehr beachtet. Siehe auch unten.



Ein
'CC=gcc-4.4 dkms build -m nvidia -v 280.13 -k 3.0.0-1-686-pae'
funktioniert nicht, der cc wird später festgelegt.
Lösung:
/usr/src/nvidia-280.13/dkms.conf modifizieren:

Code: Alles auswählen

MAKE[0]="......"

->

Code: Alles auswählen

MAKE[0]="......"
MAKE[1]="...... CC=gcc-4.4"
MAKE_MATCH[1]="3\.[0-9]\.[0-9]-.*-686-pae"
MAKE[2]="...... CC=gcc-4.4"
MAKE_MATCH[2]="3\.[0-9]\.[0-9]-.*-amd64"

(beide debian-kernel in eine regex war mir "zu regex" )
Dann kann
'dpkg-reconfigure nvidia-kernel-dkms' o.ä., auch das angesprochene Kernelupgrade aufgerufen werden.
Aber auch einzeln
'dkms build -m nvidia -v 280.13 -k .....'
'dkms install -m nvidia -v 280.13 -k .....'
Geskriptet (EDIT "280.13" -> "280.13.really.275.28-1"):

Code: Alles auswählen

#!/bin/sh
#NV_VER="$(dpkg -l nvidia-kernel-dkms | awk '$1=="ii" {print $3}')"		# mit "280.13.really.275.28-1" ad Absurdum
. /var/lib/dpkg/info/nvidia-kernel-dkms.postinst
NV_VER="$DKMS_VERSION"

for i in /boot/config-* ; do dkms build -m nvidia -v "$NV_VER" -k "${i#/boot/config-}" ; done
for i in /boot/config-* ; do dkms install -m nvidia -v "$NV_VER" -k "${i#/boot/config-}" ; done
dkms status

Alternativ eine so modifizierte Kopie der ursprünglichen dkms.conf einbinden:
'dkms build -m nvidia -v 280.13 -k ..... -c Kopie'
'dkms install -m nvidia -v 280.13 -k ..... -c Kopie'
(dann klappt es aber nicht mehr mit dem kernel-Upgrade)






------------------------------------------
EDIT Zurückrudern

Beim Installieren von nvidia-kernel-dkms (testing/sid) werden die Kernel in absteigender Reihenfolge versucht zu verarbeiten:
3.0.0-1 / 3.0.4
2.3.39-(bpo.)2
2.6.32-5

Weil beim angewendeten 'dpkg-reconfigure' alle (zuvor per 'dkms' hinzugefügten) Module entfernt wurden,
dachte ich das würde dann auch auf das folgende Installieren zutreffen.
Pustekuchen!
Dieses !%&#$!!-dkms macht nur die Module für die beiden 3er, weil "neuester" und "current",
die anderen "älteren" kernel nur explizit händisch.
Beim kernel/dkms/nvidia-Upgrade werden aber hoffentlich alle berücksichtigt?

[Alternativende]

Wow! Vielen Dank für diesen Lösungsansatz. Ich drucke mir das jetzt mal aus und probiere es heute Abend!
DANKE!!

[Alternativende]

Hi,
das hat leider nicht geklappt. Koenntest du die ganze Datei einmal posten?

[rendegast]

Modifizierte /usr/src/nvidia-280.13/dkms.conf :

Code: Alles auswählen

# DKMS configuration for the NVIDIA kernel module.  -*- sh -*-

# The version is replaced at build time by dh_dkms invoked in debian/rules.
PACKAGE_NAME="nvidia"
PACKAGE_VERSION="280.13"

BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
DEST_MODULE_LOCATION[0]="/updates/dkms/"
AUTOINSTALL=yes

MAKE[0]="env CCACHE_DISABLE=1 \
    make -C . LINUXDIR=${kernel_source_dir} KVERREL=${kernelver}"
CLEAN="make -C . LINUXDIR=${kernel_source_dir} KVERREL=${kernelver} clean"




# 20110901, gcc-4.4 statt gcc-4.5 unter squeeze
MAKE[1]="env CCACHE_DISABLE=1 \
    make -C . LINUXDIR=${kernel_source_dir} KVERREL=${kernelver} CC=gcc-4.4"
MAKE_MATCH[1]="3\.[0-9]\.[0-9]-.*-686-pae"

MAKE[2]="env CCACHE_DISABLE=1 \
    make -C . LINUXDIR=${kernel_source_dir} KVERREL=${kernelver} CC=gcc-4.4"
MAKE_MATCH[2]="3\.[0-9]\.[0-9]-.*-amd64"

Skript um alle kernel zu "bedienen" (siehe vorheriges Post), BuildAlle.sh:

Code: Alles auswählen

#!/bin/sh
NV_VER="$(dpkg -l nvidia-kernel-dkms | awk '$1=="ii" {print $3}')"
for i in /boot/config-* ; do dkms build -m nvidia -v "$NV_VER" -k "${i#/boot/config-}" ; done
for i in /boot/config-* ; do dkms install -m nvidia -v "$NV_VER" -k "${i#/boot/config-}" ; done
dkms status

NV_VER ist die Version des installierten Paketes.
(legacy-Versionen wäre wohl auch möglich zu berücksichtigen)








EDIT 20110914
Ergänzung, gleicher Trick für virtualbox, dessen dkms.conf keine explizite Angabe des 'make' hat.
Das wird aus dem dkms-Skript geholt.
Modifizierte /usr/src/virtualbox-4.0.10/dkms.conf :

Code: Alles auswählen

PACKAGE_NAME="virtualbox"
PACKAGE_VERSION="4.0.10"
CLEAN="rm -f *.*o"
BUILT_MODULE_NAME[0]="vboxdrv"
BUILT_MODULE_LOCATION[0]="vboxdrv"
DEST_MODULE_LOCATION[0]="/updates"
BUILT_MODULE_NAME[1]="vboxnetadp"
BUILT_MODULE_LOCATION[1]="vboxnetadp"
DEST_MODULE_LOCATION[1]="/updates"
BUILT_MODULE_NAME[2]="vboxnetflt"
BUILT_MODULE_LOCATION[2]="vboxnetflt"
DEST_MODULE_LOCATION[2]="/updates"
AUTOINSTALL="yes"




# 20110901, gcc-4.4 statt gcc-4.5 unter squeeze
#	generisches Kommando fuer kernel > 2.6.6, aus /usr/sbin/dkms:
MAKE[0]="make -C $kernel_source_dir M=$dkms_tree/$module/$module_version/build"

MAKE[1]="make -C $kernel_source_dir M=$dkms_tree/$module/$module_version/build   CC=gcc-4.4"
MAKE_MATCH[1]="3\.[0-9]\.[0-9]-.*-686-pae"

MAKE[2]="make -C $kernel_source_dir M=$dkms_tree/$module/$module_version/build   CC=gcc-4.4"
MAKE_MATCH[2]="3\.[0-9]\.[0-9]-.*-amd64"

Und nebenbei,
das gerade gelaufene Kernel-Upgrade 2.6.32-5 hat dann auch den von mir NICHT mit virtualbox ausgestattenten xen-Kernel
damit beglückt.










-----------------------------------------------------------------------------------------------------
EDIT, Das Threadthema dürfte hiermit abgehandelt sein,
hiernach geht es off-topic um nvidia und die video-abi-11 des Xserver 1.11 in sid.

(Nebenbei
Auf x.org R7.7 mit Server 1.10,
in sid 7.6 mit Server 1.11 (??))

[Alternativende]

hmh ne leidr auch so nicht. Auch nicht mit gcc-4.6 oder 5. Verwende ja unstable.

[rendegast]

Auch nicht mit gcc-4.6 oder 5. Verwende ja unstable.

Warum bastelst Du dann den walkaround hier ein,
Threadtitel nicht gelesen?

Ein aptitude reinstall nvidia-kernel-dkms bricht leider mit folgender Meldung ab:

Code: Alles auswählen

    Module build for the running kernel was shipped since the kernel source for this kernel does not seem to be installed.

Natürlich sind die Kernel-headers alle installiert.

Wirklich?

Code: Alles auswählen

dpkg -l  |  egrep -v "^ii"
dpkg -l  |  grep linux-

Code: Alles auswählen

apt-cache policy

aptitude update
aptitude -V full-upgrade

In aptitude mal mit F10 die audit-recommendations nachsehen,
und die 'obsoleten'.
Eventuell wurde irgendwann mal etwas auf "HOLD" gesetzt.

[Alternativende]

Ja ist alles installiert. Ich konnte jetzt auch das Modul bauen nachdem ich alle alten Kernel entfernt hatte. Frag mich nicht wieso aber nachdem die alten 2.6er und der 3.0 rc6 Kernel weg waren hat es auch geklappt.

GDM startet nun aber wahrscheinlich nicht, weil ich nvidia-glx und xserver-xorg-video-nvidia aufgrund einer Abhängigkeit nicht installieren kann. Verlangt wird xorg-video-abi-10, aber nur 11 ist verfügbar.

[rendegast]

Verlangt wird xorg-video-abi-10, aber nur 11 ist verfügbar.

Yepp, xserver-xorg-core 1.11, xorg-video-abi-11.

Und auch schon #639737 seit 29.8.



Alternativ der Installer, vorher alle *nvidia*-Pakete entfernen.
Wenn der (etwas später) wieder gegen debian-Pakete getauscht werden soll:
Beim Entfernen den '--uninstall'-Schalter benutzen,
und eventuelle Paketänderungen zurückstellen:

Code: Alles auswählen

	aptitude -v -V reinstall xserver-xorg-core libgl1-mesa-glx libgl1-mesa-dev

(EDIT 'reinstall xserver-xorg-core ...', dabei geht nur um dieses Paket,
nicht dessen Abhängigkeiten oder den ganzen X, und darin speziell die Datei
/usr/lib/xorg/modules/extensions/libglx.so,
welche vom nvidia-Installer gern mal überschrieben wurde (Erfahrungswerte).
Reinstallieren kann nicht schaden.)
Dann erst wieder die nvidia-Pakete:

Code: Alles auswählen

	aptitude -v -V install nvidia-kernel-dkms nvidia-settings

[Alternativende]

Hi,
also du meinst ich müsse erst alle nvidia Pakete entfernen dann den aktuellen xserver neu installieren und dann die nvidia Pakete wieder installieren?
In dem Bugreport wird ja empfohlen wieder den alten Xserver aus testing zu verwenden, aber so ein Downgrade ist ja auch nicht ohne wegen der ganzen Abhängigkeiten.
Oder meinst du ich solle den Installer von der Nvidia Seite nehmen, vorher alle Debian Pakete entfernen und später wenn sich die Schwierigkeiten erledigt haben wieder zu den deb´s zurückkehren?

[towo]

Im Moment gibt es keinen Nvidia-Treiber, der mit Xserver 1.11 läuft.
Dir bleiben also nur 2 Möglichekeiten:

1. Xserver 1.10.x mit Nvidia
2. Xserver 1.11 ohne Nvidia

[Alternativende]

Achso, ok. Heißt ich entferne alle Nvidia Pakete vorerst und installiere den xserver neu. Dieser merkt dann das nvidia nicht mehr verfügbar ist greift zu nouveau und ich warte auf einen funktionierenden Treiber von Nvidia.

[rendegast]

... dann den aktuellen xserver neu installieren ...

'reinstall xserver-xorg-core ...', dabei geht nur um dieses Paket,
nicht dessen Abhängigkeiten oder den ganzen X, und darin speziell die Datei
/usr/lib/xorg/modules/extensions/libglx.so,
welche vom nvidia-Installer gern mal überschrieben wurde (Erfahrungswerte).
Reinstallieren schadet nicht.

Wenn der installer 280.13 dann aber auch nicht mit dem Xserver aus sid kann ~

[Alternativende]

Ach ich werde das einfach mal in Angriff nehmen. Habe mir sicherheitshalber noch notiert wie man nouveau installiert, falls es nicht automatisch klappen sollte und dann wird das schon werden hoffe ich.

Edit:
Ja das hat soweit funktioniert. Habe alle Nvidia Pakete entfernt, die xorg.conf gelöscht und nun funktioniert es zumindest wieder. Nun gilt es zu warten bis es einen vernünftigen Treiber von Nvidia gibt damit ich auch wieder HD Videos schauen kann.

Danke für die nette Hilfe!

[Evox]

Bei mir funktioniert es auch zur Zeit noch! Nutze kein DKMS sondern die Source + m-a + X.org: 1.10.4. DKMS hat seine Mühe mit den Linux3.x.
Xorg* +Abhängigkeiten selber Übersetzt wegen Death Linie - Wheezy /Testing.

Nun gilt es zu warten bis es einen vernünftigen Treiber von Nvidia gibt damit ich auch wieder HD Videos schauen kann.

Funktioniert auch so da das Stable System bei mir mit Nouveau läuft (720p + 1080p)

[Alternativende]

Nun ja die Qualität ist schon was anderes. Sowohl was Qualität als auch die Performance sind doch erheblich schlechter mit dem Standardtreiber.

[rendegast]

weil ich nvidia-glx und xserver-xorg-video-nvidia aufgrund einer Abhängigkeit nicht installieren kann. Verlangt wird xorg-video-abi-10, aber nur 11 ist verfügbar.

Im Moment gibt es keinen Nvidia-Treiber, der mit Xserver 1.11 läuft.
Dir bleiben also nur 2 Möglichekeiten:
1. Xserver 1.10.x mit Nvidia
2. Xserver 1.11 ohne Nvidia

Und auch schon #639737 seit 29.8.

Hilft nicht bei den Installationsabhängigkeiten, aber falls die umgangen werden könnten
wäre die Funktion eventuell herstellbar:

"IgnoreABI" option needs to be enabled, see xorg.conf(5).

(Im changelog zum experimental 285.*, ein allgemeiner walkaround)
auch man-page:

Option "IgnoreABI" "boolean"
Allow modules built for a different, potentially incompatible version of the X server to load. Disabled by default.

Oder wohl die nvidia-Pakete 280.13-4.