Siduction Forum
Siduction Forum => Upgrade Warnings => Topic started by: devil on 2011/06/17, 14:08:18
-
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630710
greetz
devil
-
Ärgerlich! aber ich hab inzwischen Übung auf nvidia-proprietär zu wechseln. ->läuft
Host/Kernel/OS "aptosidbox" running Linux 2.6.39-1.slh.8-aptosid-amd64 x86_64 [ aptosid 2010-02 Κῆρες - kde-full - (201009132215) ]
CPU Info 2x AMD Athlon X2 Dual Core BE-2350 512 KB cache flags( sse3 ht nx lm svm ) clocked at [ 1000.000 MHz ]
Videocard nVidia C68 [GeForce 7050 PV / nForce 630a] X.Org 1.10.2 [ 1280x1024@50.0hz ]
Network cards Ralink corp. RT2561/RT61 802.11g PCI
nVidia MCP67 Ethernet, at port: d880
Processes 134 | Uptime 3:31 | Memory 731.9/1949.1MB | HDD Hitachi HDT72504 Size 400GB (31%used) | GLX Renderer GeForce 7050 PV / nForce 630a/PCI/SSE2 | GLX Version 2.1.2 NVIDIA 275.09.07 | Client Shell | Infobash v3.36
-
hab ich heut gemerkt und musste ein downgrade von libgl1-mesa-glx zu testing machen ;(
-
reddark,
das sind glaub 2 paar schuhe.
greetz
devil
-
ich denk nicht, den nach einem update heute, hatte ich zwar noch die kwin-effekte, aber z.B. Sauerbraten ließ sich nicht mehr starten. Beim test in der konsole kam "Error: couldn't find RGB GLX visual" also hab ich das downgrade gemacht und alles war wieder gut. Hier fglrx in benutzung ;)
-
Eigentlich nicht.
-
Eigentlich nicht.
Wie jetzt? Bringt mich nicht durcheinander ;)
-
Doch, downgrade auf mesa-glx aus testing funktioniert.
Das eigentlich nicht bezog sich auf devils Post, daß das 2 paar Schuhe wären.
-
aso ;)
-
@towo oder @devel, kann das von euch jemand näher erklären, was es für eine Umstellung ist mit den 32bit: Wird Multiarch jetzt irgendwie anders gehandhabt?
-
Multiarch kann nicht anders gehandhabt werden, Multiarch war gar nicht existent.
-
Und was ist mit dem Bug (oben der Link) gemeint:
"The multiarch move of MESA breaks current diversion handling"
-
Das bedeutet, das mit der, jetzt erfolgenden, Einführung von Multiarch die glx-diversion der binary Blobs nicht mehr funktioniert.
-
So, jetzt müsste ich nur den Unterschied zwischen Multiarch und diversion kapieren. Ich glaub das war wohl meine Frage eigentlich.
Geht es darum, in welcher Weise auf amd64 Architektur Laufanfragen für 32bit Subsysteme beantwortet werden, zB wine oder nspluginwrapper für adobe-flash?
-
früher hiess das zeug ia32 und funktionierte donnerstags von 11:00 -17:00.
jetzt heisst es multiarch und erst mal muss einiges angepasst werden damit es dann vielleicht funtioniert.
greetz
devil
-
Testing hilft mir auch nicht mehr :(
Die folgenden Pakete werden ENTFERNT:
xserver-xorg xserver-xorg-core xserver-xorg-input-all
xserver-xorg-input-evdev xserver-xorg-input-mouse
xserver-xorg-input-synaptics xserver-xorg-input-vmmouse
xserver-xorg-input-wacom xserver-xorg-video-apm xserver-xorg-video-ark
xserver-xorg-video-ati xserver-xorg-video-chips xserver-xorg-video-cirrus
xserver-xorg-video-fbdev xserver-xorg-video-i128 xserver-xorg-video-i740
xserver-xorg-video-intel xserver-xorg-video-mach64 xserver-xorg-video-mga
xserver-xorg-video-neomagic xserver-xorg-video-openchrome
xserver-xorg-video-r128 xserver-xorg-video-radeon
xserver-xorg-video-rendition xserver-xorg-video-s3
xserver-xorg-video-s3virge xserver-xorg-video-savage
xserver-xorg-video-siliconmotion xserver-xorg-video-sis
xserver-xorg-video-sisusb xserver-xorg-video-tdfx xserver-xorg-video-trident
xserver-xorg-video-tseng xserver-xorg-video-vesa xserver-xorg-video-vmware
xserver-xorg-video-voodoo
Die folgenden Pakete werden durch eine ÄLTERE VERSION ERSETZT (Downgrade):
libgl1-mesa-dri libgl1-mesa-glx
0 aktualisiert, 0 neu installiert, 2 durch eine ältere Version ersetzt, 36 zu entfernen und 2 nicht aktualisiert.
Es müssen 17,2 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 14,0 MB Plattenplatz freigegeben.
Möchten Sie fortfahren [J/n]? n
-
Testing ist toll und hilft, wenn Du den Befehl zur Ausgabe reingeschrieben hättest, hätte man dier auch noch schreiben können, was fehlt. ;)
-
@OppaErich
Welche Version ist installiert ?
dpkg -l xserver* |grep ii
ii xserver-common 2:1.10.2-1 common files used by various X servers
ii xserver-xorg 1:7.6+7 X.Org X server
ii xserver-xorg-core 2:1.10.2-1+b1 Xorg X server - core server
ii xserver-xorg-dev 2:1.10.2-1+b1 Xorg X server - development files
ii xserver-xorg-input-all 1:7.6+7 X.Org X server -- input driver metapackage
ii xserver-xorg-input-evdev 1:2.6.0-3 X.Org X server -- evdev input driver
ii xserver-xorg-input-kbd 1:1.6.0-3 X.Org X server -- keyboard input driver
ii xserver-xorg-input-mouse 1:1.7.0-4 X.Org X server -- mouse input driver
ii xserver-xorg-input-synaptics 1.4.0-1+exp1 Synaptics TouchPad driver for X.Org server
ii xserver-xorg-video-fbdev 1:0.4.2-6 X.Org X server -- fbdev display driver
ii xserver-xorg-video-nouveau 1:0.0.16+git20110411+8378443-1+exp1 X.Org X server -- Nouveau display driver (experimental)
ii xserver-xorg-video-vesa
xorg-server (2:1.10.2-2) unstable; urgency=low
* Bump libgl1-mesa-dri versioned Recommends to 7.10.2-4, to lower the
odds of having a server built against multiarched mesa, installed
along a pre-multiarch mesa. The Breaks in mesa packages take care of
the other way round already.
* And since the server's binNMU managed to migrate to testing way too
early, add a Breaks against pre-multiarch libgl1-mesa-dri and
libgl1-mesa-dri-experimental.
-- Cyril Brulebois <kibi> Fri, 17 Jun 2011 18:09:36 +0200
Für mutige
nvidia-graphics-drivers (275.09.07-2) experimental; urgency=low
* Drop Breaks: libgl1-mesa-glx (>= 7.10.2-4~).
-
@OppaErich
Welche Version ist installiert ?
Keine Ahnung, müßte ich jetzt wieder hin- und herbooten. Ich hab jetzt die monatelang unangetastete 64bit laufen.
Testing ist toll und hilft, wenn Du den Befehl zur Ausgabe reingeschrieben hättest, hätte man dier auch noch schreiben können, was fehlt. ;)
apt-get install libgl1-mesa-dri/testing libgl1-mesa-glx/testing
-
echo libgl1-mesa-dev hold | dpkg --set-selections
echo libgl1-mesa-glx hold | dpkg --set-selections
echo mesa-common-dev hold | dpkg --set-selections
Das sind die einzigen Pakete, die ich aus stable geholt habe. -dri ist da irgendwie nicht mit dabei. Das habe ich auf einer Installation mit fglrx so ausgewürfelt. Dann wollte er auch den Rest nicht mehr entfernen. Und fglrx-glx ging wieder, die Kernelmodule bauten und gut wars. (Richtig gut wäre was anderes, aber das steht ja hier jetzt nicht zur Debatte. Der 11-6-1 macht da wohl keine Zicken mehr)
-
HUH ? Verstehe ich nicht wirklich. Wenn ich die drei Pakete auf Hold setze, zaubert mir das den nvidia wieder herbei ? Ich hatte auf einen d-u gehofft aber der brachte mir nur einen neuen Chromium.
-
Nachdem ich mir mein Aptosid auf die von Dir beschriebene Art und Weise versaut hatte, habe ich mir ein Reseve-debian genommen und den selben Ablauf noch mal versucht. Die 3 Pakete vwaren für das entfernen des fglrx-glx verantwortlich. Also habe ich sie, zurückgeholt, gepinnt und gut wars. Danach lief der d-u durch.
Wenn das Kind schon in den Brunnen gefallen ist, installiere die Pakete einfach neu. Die Liste hast Du ja. Die hat er ja dankenswerter Weise geworfen.
-
Hallo Zusammen,
ich frage mich, wie man jetzt mit den dist-upgrades weitermachen kann? Ich verwende den Nvidia Binary-Treiber. Aufgrund des Tipps von ageida habe ich mit den folgenden Holds einen dist-upgrade durchgeführt:echo libgl1-mesa-dev hold | dpkg --set-selections
echo libgl1-mesa-glx hold | dpkg --set-selections
echo mesa-common-dev hold | dpkg --set-selectionsDas hat auch prima geklappt und der Nvidia Treiber wurde auf die Version 275.09.07 aktualisiert. Den Hold habe ich dann für die o.g. Pakete wieder aufgehoben. Beim nächsten dist-upgrade habe ich nun das folgende Bild:Die folgenden Pakete werden ENTFERNT:
libgl1-nvidia-alternatives libgl1-nvidia-glx nvidia-glx
Die folgenden Pakete werden aktualisiert (Upgrade):
apt-xapian-index iptables libatk1.0-0 libatk1.0-data libgl1-mesa-dri libgl1-mesa-glx libmysqlclient16 librecad librecad-data libwebkitgtk-1.0-0
libwebkitgtk-1.0-common libwrap0 mysql-common mysql-server-core-5.1 rsyslog splix x11-xkb-utils xserver-xorg-core Für die zu entfernenden Pakte gilt:
libgl1-nvidia-alternatives:
Installiert: 275.09.07-1
Kandidat: 275.09.07-1
libgl1-nvidia-glx:
Installiert: 275.09.07-1
Kandidat: 275.09.07-1
nvidia-glx:
Installiert: 275.09.07-1
Kandidat: 275.09.07-1
Im voraus Danke für hilfreiche Infos.
Gruß
Sordon
-
Hold wieder setzen und auf nvidia warten ... DU kann ja dann trotzdem normal durchgeführt werden.
-
libgl1-nvidia-glx nvidia-glx - Natürlich kannst Du die entfernen lassen, aber Du wirst sie nicht wieder eingebaut bekommen. Siehe die Erklärungen z.B. von Towo zu diesem Thema. Da es übersichtlich ist, habe ich die Pakete auf hold gelassen. Da die einem dann bei jedem D-U auf den Sack gehen, vergisst man sie auch nicht.
Wenn der Zustand bereinigt ist, dann wird es glaube ich genau hier eine Entwarnung geben. Ich hoffe ja, bald. Bei ATI geht auf jeden Fall momentan nicht viel, die Quellen für 11-5 und jetzt 11-6 wurden zähneknischend ins SVN eingefügt, ab da passierte nichts mehr. Wie das jetzt bei nVidia aussieht weiss ich nicht. Ich werde auf jeden Fall die Füsse still halten und mal gar nichts machen. Die alten Treiber tuns für mich, die aktuellen kann ich mir in Arch anschauen und obwohl die neuen binaries von ATI ein paar Probleme lösen sollen, die ich so nicht habe oder sehe kann ich, wenn es denn wirklich notwendig ist, noch ein oder zwei Versionen auf aktuelles Zeug warten.
Irgendwie witzig, eigentlich kann ich jetzt schon Wetten annehmen, was für meinen Rechner eher kommt - neue Treiber oder neue Hardware.
-
Bei ATI geht auf jeden Fall momentan nicht viel, die Quellen für 11-5 und jetzt 11-6 wurden zähneknischend ins SVN eingefügt, ab da passierte nichts mehr.
towo meinte gestern im IRC, das ATI bald fertig ist ..... ;)
-
Danke für die Infos. Jetzt weiß ich Bescheid, wie ich weiter zu verfahren habe. Hoffe mal das Nvidia schnell reagiert.
-
Bei ATI geht auf jeden Fall momentan nicht viel, die Quellen für 11-5 und jetzt 11-6 wurden zähneknischend ins SVN eingefügt, ab da passierte nichts mehr.
towo meinte gestern im IRC, das ATI bald fertig ist ..... ;)
Wenn er das selbst baut, glaube ich ihm das. Er kann das. Die Commits im Debian-Paket sprechen da eine andere Sprache.
fglrx-driver (1:11-6-1) UNRELEASED; urgency=high
* New upstream release.
Closes: #627100
- Refresh patch 02-dkms-arch_compat.diff.
* Remove odd comments from maintainer scripts.
* Remove debconf question about ACPI Powerstates, it is handled by fglrx
itself.
* Wrap control fields in debian/control.
* Depend on xserver-xorg 1:7.6+7 to ensure, that a multiarch xorg is present.
* Try to enable multiarch:
Closes: #630592
- Drop fglrx-glx-ia32 package.
- Rework many packaging parts.
- Rework diversion handling.
* Remove odd NEWS file.
* Remove odd menu entries for fglrx-control.
* Remove rpl from build depends and from debian/rules, no longer needed.
* Remove all odd upgrade paths.
* Adjust lintian overrides.
-- Patrick Matthäi <pmatthaei> Fri, 17 Jun 2011 22:21:58 +0200
fglrx-driver (1:11-4-2) unstable; urgency=low
* Adjust dependency on xorg-video-abi to 10.
Closes: #624813
-- Patrick Matthäi <pmatthaei> Tue, 03 May 2011 20:19:06 +0200
fglrx-driver (1:11-4-1) unstable; urgency=low
* New upstream release.
- Remove merged patch 04-2.6.38-support.diff.
- Refresh hunky patch 05-fix-global-kernel-lock.diff.
- Fixed regression with Qt demo.
Closes: #614705
* Add patch 07-2.6.39-support.diff to build with Linux 2.6.39.
Closes: #620151
* Remove quilt build dependency.
* Wrap build dependencies.
* Bump Standards-Version to 3.9.2 (no changes needed).
* Fix two typos in fglrx and fglrx_xgamma manpage.
* Adjust lintian overrides.
-- Patrick Matthäi <pmatthaei> Wed, 27 Apr 2011 22:21:51 +0200
Die Häufigkeit der Commits spricht in meinen Augen Bände. Der monatliche Commit ist durch :lol:
-
Ich habe die Info von the-me (dem Maintainer) selbst aus #debian. Er hat Gestern ein Testbuild versucht, allerdings fehlte da auf dem Buildserver noch etwas. Außerdem muß die gefixte Version durch NEW (nvidia-glx auch).
-
Na denne - das wäre doch mal schön. Mit dem 11-5 hatte ich einige Stabilitätsprobleme. Ob das jetzt allerdings am Treiber oder am Zustand der 4.7 beta lag, who cares. Auf jeden Fall ist mein Arch mit 4.7 und 11-6 wieder stabil. Was das bewirkt hat, keine Ahnung. Auf jeden Fall kann eine weiterentwickelte, stabile Version eines Treibers so verkehrt nicht sein.
-
[23:28] <the-me> zobel: Maik: wenn ftp-masters jetzt noch glx-alternative accepten, dann kann ich nen gefixten fglrx hochladen..
-
Für Nvidia liegen gefixte Pakete in Experimental.
-
Die Diversifizierungen würde ich erst mal andere Leute probieren lassen, es ist nicht ubedingt schön, da den alpha-Tester zu spielen. Das könnte länger dauern.
Wenn dann was schief läuft, hat man viel Freude beim Aufräumen. Ich kann da allerdings nur von ATI sprechen, Spass macht das noch nicht wirklich. Die Mesa-Sachen sind noch nicht ganz sauber.
-
Auf 64bit gibts kein Problem mit nvidia.
32bit hat ein kaputtes glx-alternative-mesa.
-
Das habe ich heute morgen auf 64bit mit ATI anders durch. Seit dem benutze ich wieder mal den radeon, der erstaunlich gut funktioniert. Ich hatte einfach noch keine Zeit und Lust, genauer zu schauen, wo es hängt. ;)
-
Then, there is no xserver-xorg-video-nvidia installed.
Du hast wie immer recht, Problem ist nur apt-cache search findet kein Paket mit dem Namen. :|
-
Weils das nur in experimentalgibt vielleicht?
towo:Defiant> apt-cache policy xserver-xorg-video-nvidia
xserver-xorg-video-nvidia:
Installiert: (keine)
Kandidat: 275.09.07-3
Versionstabelle:
275.09.07-3 0
100 ftp://ftp.de.debian.org/debian/ experimental/non-free amd64 Packages
-
Das habe ich heute morgen auf 64bit mit ATI anders durch.
Hatte, seit der Thread hier existiert, kein d-u mehr gemacht und bin heute ungeduldig geworden.
Dank Deiner Warnung hab ich, da fglrx-glx entfernt werden sollte, libgl1-mesa-glx vor dem d-u auf hold gesetzt.
Die folgenden Pakete sind zurückgehalten worden:
libgl1-mesa-dri libgl1-mesa-glx xserver-xorg-core
Danach lief das d-u problemlos, fglrx-11-4-modul wurde gebaut und läuft. KDE ebenfalls ohne Probleme.
Nur für den Fall...
Gruß
ayla
-
Nvidia aus Experimental funktioniert ohne Probleme. Vor Upgrade den Treiber aus Unstable löschen.
..
ii glx-alternative-nvidia 0.0.1
ii glx-diversions 0.0.1
ii libgl1-mesa-glx 7.10.3-3
ii libgl1-nvidia-glx 275.09.07-3.1
..
-
Ich will ja jetzt nicht anfangen zu weinen. Aber eins ist Fakt: Irgendwo in dem neuen Zeug ist ein gewaltiger Hau drin (fglrx). Der Treiber baut auf den Kernel ohne Probleme, aber in den Untiefen dieser kopfkranken Erfindung "Alternativen" hakt es gar mächtig.
Kopfkrank deshalb, weil es einfach nicht sein kann, dass in 3 Paketen und an verschiedensten Orten gefrickelt wird um ganze 2 Dateien (meinetwegen auch 3) in der richtigen Reihenfolge vom richtigen Ort zu laden. Das ist einfach nur krank. Erstaunlich ist, dass einer der Zwischenstände (nicht der jetzige in exp.) funktioniert hat. Falls jemand eine Idee hat, was man wo verbiegen muss, bitte her damit. Ich habe keine Lust mehr, da hinterherzusuchen. Ich hab mir dann erst mal einen alternativen grub-Eintrag mit modeset=1 gemacht und fahre bis auf weiteres den radeon, auch wenn ich da das Stromsparen wieder extra anschalten muss. Und dann warte ich einfach ab, wie diese Farce weitergeht.
Erstaunlich ist, dass diesmal an dem Schrott kein aptosid-dev beteiligt ist.
-
Hoi towo
Für Nvidia liegen gefixte Pakete in Experimental.
Auf 64bit gibts kein Problem mit nvidia.
wegen dem Nvidia häng ich jetzt ein bissel hinter her mit dem d-u
bei mir will er nach wie vor diese 3 Pakete removen:
Remv nvidia-glx [270.41.19-1]
Remv libgl1-nvidia-glx [270.41.19-1]
Remv libgl1-nvidia-alternatives [270.41.19-1]
und diese beiden upgraden:
Inst nvidia-kernel-dkms [270.41.19-1] (275.09.07-1 Debian:unstable [amd64])
Inst nvidia-kernel-source (275.09.07-1 Debian:unstable [amd64])
Conf nvidia-kernel-dkms (275.09.07-1 Debian:unstable [amd64])
Conf nvidia-kernel-source (275.09.07-1 Debian:unstable [amd64])
System
Host/Kernel/OS "tine" running Linux 2.6.39-1.slh.3-aptosid-amd64 x86_64 [ sidux 2009-02 Αιθήρ - kde-lite - (200907141521) ]
CPU Info 4x Intel Core2 Quad Q9400 @ 3072 KB cache flags( sse3 ht nx lm vmx ) clocked at [ 2003.000 MHz ]
Videocard nVidia G96 [GeForce 9400 GT] [ ]
Network cards Marvell 88E8056 PCI-E Gigabit
Marvell 88E8001 Gigabit
Processes 143 | Uptime 10min | Memory 812.3/3966.1MB | HDD ST3200822A,WDC WD5000AAKS-0 Size 700GB (29%used) | Client Shell | Infobash v3.36
sollte ich noch warten, oder kann ich ein d-u wagen?
Merci schon mal
Tine
-
Weils das nur in experimental gibt vielleicht
Ist nun installiert, immer noch "Failed to load module nvidia", kein X.
-
Ich will ja jetzt nicht anfangen zu weinen. Aber eins ist Fakt: Irgendwo in dem neuen Zeug ist ein gewaltiger Hau drin (fglrx).
Ignorieren wir mal den recht sinnfreien snippischen Seitenhieb und sagen wir dann, dass der erste exp. Upload keinen Support für fglrx hatte, weshalb es gut sein kann, dass es da noch ging, weil es eben nicht ging… (gut zu verstehen, nicht war?)
Der Hack mit den Alternativen in Paketen ist sicherlich nicht so hübsch, aber besser als der Hack zuvor (Diversions?) und lösbar scheint mir das nicht zu sein, weil man wohl Namen der Datei in den untiefen des binären Treibers ändern müsste um sich Diversions oder Alternativen zu ersparen… Kannst ja mal AMD und Nvidia fragen ob sie das für dich tun…
Mal davon abgesehen, dass man nun theoretisch jedes dieser Pakete installieren kann und dann "nur" die Alternative umschalten muss was für Systeme ganz nett sein kann die die Grafikkarte öfter wechseln (Persist auf USB-Stick z.B.).
Und JFTR: Das Paket hält inzwischen auch Einzug in unstable, also ist der Umweg über experimental nicht mehr nötig bzw. veraltet bzw. bald überhaupt nicht mehr möglich.
-
Update mit fglrx aus experimental hat bei mir funktioniert ...
-
Update mit fglrx aus experimental hat bei mir funktioniert ...
hmm, dann bin ich wohl zu blöd.
Nach dem Versuch libgl1-mesa-glx und fglrx* auf experimental upzugraden läuft bei mir jetzt mal wieder der radeon.
Der Versuch mit dem fglrx endete in der Konsole.
Weder eigene (mini)-20-fglrx.conf noch eine von aticonfig erstellte ändern was.
30.116]
X.Org X Server 1.10.2
Release Date: 2011-05-28
[ 30.116] X Protocol Version 11, Revision 0
[ 30.116] Build Operating System: Linux 2.6.39-1-amd64 x86_64 Debian
[ 30.116] Current Operating System: Linux nescaya 2.6.39-2.slh.1-aptosid-amd64 #1 SMP PREEMPT Thu Jun 23 22:36:49 UTC 2011 x86_64
[ 30.116] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.39-2.slh.1-aptosid-amd64 root=UUID=14d6b7a7-e328-4ea4-9526-529eecece101 ro radeon.modeset=0
[ 30.116] Build Date: 17 June 2011 04:13:25PM
[ 30.116] xorg-server 2:1.10.2-2 (Cyril Brulebois <kibi>)
[ 30.116] Current version of pixman: 0.21.8
[ 30.116] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 30.116] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 30.117] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Jun 25 14:59:47 2011
[ 30.122] (==) Using config file: "/etc/X11/xorg.conf"
[ 30.122] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 30.122] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 30.125] (==) ServerLayout "aticonfig Layout"
[ 30.125] (**) |-->Screen "aticonfig-Screen[0]-0" (0)
[ 30.125] (**) | |-->Monitor "aticonfig-Monitor[0]-0"
[ 30.126] (**) | |-->Device "aticonfig-Device[0]-0"
[ 30.126] (==) Automatically adding devices
[ 30.126] (==) Automatically enabling devices
[ 30.138] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 30.138] Entry deleted from font path.
[ 30.142] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist.
[ 30.142] Entry deleted from font path.
[ 30.142] (WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist.
[ 30.142] Entry deleted from font path.
[ 30.142] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 30.142] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 30.143] (II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure udev or disable AutoAddDevices.
[ 30.143] (II) Loader magic: 0x7d7a20
[ 30.143] (II) Module ABI versions:
[ 30.143] X.Org ANSI C Emulation: 0.4
[ 30.143] X.Org Video Driver: 10.0
[ 30.143] X.Org XInput driver : 12.2
[ 30.143] X.Org Server Extension : 5.0
[ 30.144] (--) PCI:*(0:0:1:0) 1002:9802:1043:84a5 rev 0, Mem @ 0xc0000000/268435456, 0xfeb00000/262144, 0xfe900000/1048576, I/O @ 0x0000f000/256
[ 30.145] (II) Open ACPI successful (/var/run/acpid.socket)
[ 30.145] (II) "extmod" will be loaded by default.
[ 30.145] (II) "dbe" will be loaded by default.
[ 30.145] (II) "glx" will be loaded by default.
[ 30.145] (II) "record" will be loaded by default.
[ 30.145] (II) "dri" will be loaded by default.
[ 30.145] (II) "dri2" will be loaded by default.
[ 30.145] (II) LoadModule: "extmod"
[ 30.154] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[ 30.157] (II) Module extmod: vendor="X.Org Foundation"
[ 30.157] compiled for 1.10.2, module version = 1.0.0
[ 30.157] Module class: X.Org Server Extension
[ 30.157] ABI class: X.Org Server Extension, version 5.0
[ 30.157] (II) Loading extension SELinux
[ 30.157] (II) Loading extension MIT-SCREEN-SAVER
[ 30.157] (II) Loading extension XFree86-VidModeExtension
[ 30.157] (II) Loading extension XFree86-DGA
[ 30.157] (II) Loading extension DPMS
[ 30.157] (II) Loading extension XVideo
[ 30.157] (II) Loading extension XVideo-MotionCompensation
[ 30.157] (II) Loading extension X-Resource
[ 30.157] (II) LoadModule: "dbe"
[ 30.157] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
[ 30.158] (II) Module dbe: vendor="X.Org Foundation"
[ 30.158] compiled for 1.10.2, module version = 1.0.0
[ 30.158] Module class: X.Org Server Extension
[ 30.158] ABI class: X.Org Server Extension, version 5.0
[ 30.158] (II) Loading extension DOUBLE-BUFFER
[ 30.158] (II) LoadModule: "glx"
[ 30.159] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 30.162] (II) Module glx: vendor="X.Org Foundation"
[ 30.162] compiled for 1.10.2, module version = 1.0.0
[ 30.162] ABI class: X.Org Server Extension, version 5.0
[ 30.162] (==) AIGLX enabled
[ 30.162] (II) Loading extension GLX
[ 30.162] (II) LoadModule: "record"
[ 30.164] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so
[ 30.166] (II) Module record: vendor="X.Org Foundation"
[ 30.166] compiled for 1.10.2, module version = 1.13.0
[ 30.166] Module class: X.Org Server Extension
[ 30.166] ABI class: X.Org Server Extension, version 5.0
[ 30.166] (II) Loading extension RECORD
[ 30.166] (II) LoadModule: "dri"
[ 30.167] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so
[ 30.174] (II) Module dri: vendor="X.Org Foundation"
[ 30.174] compiled for 1.10.2, module version = 1.0.0
[ 30.174] ABI class: X.Org Server Extension, version 5.0
[ 30.174] (II) Loading extension XFree86-DRI
[ 30.174] (II) LoadModule: "dri2"
[ 30.174] (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
[ 30.175] (II) Module dri2: vendor="X.Org Foundation"
[ 30.175] compiled for 1.10.2, module version = 1.2.0
[ 30.175] ABI class: X.Org Server Extension, version 5.0
[ 30.175] (II) Loading extension DRI2
[ 30.175] (II) LoadModule: "fglrx"
[ 30.176] (WW) Warning, couldn't open module fglrx
[ 30.176] (II) UnloadModule: "fglrx"
[ 30.176] (II) Unloading fglrx
[ 30.176] (EE) Failed to load module "fglrx" (module does not exist, 0)
[ 30.176] (EE) No drivers available.
[ 30.176]
Fatal server error:
[ 30.176] no screens found
[ 30.176]
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 30.176] Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 30.176]
fglrx-modules-dkms installiert und dkms hat auch den Bau der module gemeldet.
-
fglrx-modules-dkms installiert und dkms hat auch den Bau der module gemeldet.
hatte bei mir auch erst gefehlt, nachinstalliert und dann reboot und schon lief es.
Und ich glaube glx-alternative-fglrx sollte erst nach glx-alternative-mesa installiert/aktualisiert werden. So hatte ich es zumindest im gefühl ;)
-
Das kann sein. Ich hatte den Kram ungefähr 5 Minuten am Laufen. Das kann aber durchaus den von DonKult angeführten Grund haben. Es war noch nicht implementiert.
-
Kann ich nicht bestätigen.
Hatte zuerst libgl1-mesa-glx aus experimental geholt.
Das hatte fglrx-driver 11-6 und einige andere nachgeholt.
Danach d-u und dann, als ich das Fehlen feststellte, noch fglrx-modules-dkms aus experimental nach installiert.
dkms meldete normal den Bau für die vorhandenen 3 Kernel, trotzdem die Meldung im Xorg.log.
Bin das Geraffel mit purge fglrx* und reinstall noch einige Male durch, aber keine Änderung.
-
hmm, wie gesagt bei mir gehts
fglrx-driver:
Installiert: 1:11-6-1
Kandidat: 1:11-6-1
Versionstabelle:
*** 1:11-6-1 0
1 http://ftp.de.debian.org/debian/ experimental/non-free amd64 Packages
100 /var/lib/dpkg/status
1:11-4-2 0
500 http://ftp.de.debian.org/debian/ unstable/non-free amd64 Packages
500 http://ftp.de.debian.org/debian/ testing/non-free amd64 Packages
glxinfo | grep rendering
direct rendering: Yes
Hast du neu gebootet?
-
Jupp, jedesmal reboot, wenn ich es neu probiert hatte.
Ich probiers heut Nacht nochmal, jetzt muß ich weg.
Danke
ayla
-
Jetzt brat mir doch einer einen!
Nach 3 Stunden wieder an die Kiste gesetzt, das Gleiche zum x. Mal nochmal gemacht:
radeon blacklisten
radeon.modeset=0 und update-grub
fglrx statt radeon in die conf
apt-get install --reinstall -t experimental von dem ganzen fglrx-Krempel
reboot
und läuft!
Warum? Keine Ahnung, ich bin ganz sicher ich hab bei meinen vorigen Versuchen nix vergessen, hab sie ja um sicher zu gehen mehrfach wiederholt. :twisted:
Jedenfalls, es läuft bei mir mit:
libgl1-mesa-glx:
Installiert: 7.11~0-2
1 http://cdn.debian.net/debian/ experimental/main amd64 Packages
libgl1-mesa-dri:
Installiert: 7.11~0-2
1 http://cdn.debian.net/debian/ experimental/main amd64 Packages
fglrx-driver:
Installiert: 1:11-6-1
1 http://cdn.debian.net/debian/ experimental/non-free amd64 Packages
Danke
ayla
-
Für alle, die sich diesen Wiggel nicht antun möchten: Wartet bis das Zeug da ist, und zwar vollständig! ;)
------------------------------------------------------------------------
r625 | pmatthaei | 2011-06-26 17:43:42 +0200 (So, 26. Jun 2011) | 2 Zeilen
* Uploading to unstable.
------------------------------------------------------------------------
r624 | pmatthaei | 2011-06-26 17:35:20 +0200 (So, 26. Jun 2011) | 2 Zeilen
Overwrite lintian warning fglrx-driver: non-dev-pkg-with-shlib-symlink usr/lib/libXvBAW.so.1.0 usr/lib/libXvBAW.so.
------------------------------------------------------------------------
r623 | pmatthaei | 2011-06-26 17:05:55 +0200 (So, 26. Jun 2011) | 3 Zeilen
* Bump dependency on glx-alternative-fglrx to 0.1.2 to ensure, that a fixed
version is available.
-
Hmm, nun hab ich doch ein Problem mit FGLRX. Der HDMI-Ausgang scheint nicht mehr zu funktionieren. Er findet den Fernseher nicht mehr .... Hat da jemand eine Idee??
edit:
hab mal einen eigenen Thread dazu erstellt:
http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&p=9476#9476
-
Nvidia Pakete aus experimental (275*) - nach vorheriger kompletter Entfernung von allem was nach Nvidia auch nur im Entferntesten riecht - hat in Verbindung mit dem Update von libgl1-mesa-glx aus Experimental problemlos geklappt. Danke, towo!
-
So sieht das mit fglrx auch aus. Komplett alle Überreste tilgen und alles neu. Auf einmal funktioniert alles ohne Probleme.
-
hmm, scheint als wäre das chaos vorbei:
apt-cache policy nvidia-kernel-source
nvidia-kernel-source:
Installiert: (keine)
Kandidat: 275.09.07-4
Versionstabelle:
275.09.07-4 0
500 http://ftp.de.debian.org/debian/ unstable/non-free amd64 Packages
glxinfo | grep rendering
direct rendering: Yes
GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite,
da der treiber auch ohne "nvidia-kernel-source" gebaut wird brauch ich die wohl nicht...
cu, stephan
-
ja, hier auch wider alles im Lot. Hab gestern das erste mal seit 3 Wochen wieder ein d-u gewagt und alles ist glatt gelaufen (32-Bit).
Host/Kernel/OS "andreas-notebook" running Linux 2.6.39-2.slh.1-aptosid-686 i686 [ sidux 2010-01 Ύπνος - kde-lite - (201006131622) ]
CPU Info 4x Intel Core i5 M 520 @ 3072 KB cache flags( sse3 ht nx lm vmx ) clocked at [ 1199.000 MHz ]
Videocard nVidia GT216 [GeForce GT 330M] X.Org 1.10.2 [ 1920x1080@50.0hz ]
Network cards Marvell 88E8057 PCI-E Gigabit
Intel Centrino Advanced-N 6200
Processes 144 | Uptime 9:04 | Memory 911.9/3278.2MB | HDD Hitachi HTS54505 Size 500GB (38%used) | GLX Renderer GeForce GT 330M/PCI/SSE2 | GLX Version 3.3.0 NVIDIA 275.09.07 | Client Shell | Infobash v3.36
-
Hallo, hier auch wieder alles im Lot.
Update heute, 64bit.
running Linux 2.6.39-2.slh.1-aptosid-amd64 x86_64 [ aptosid 2010-02 Κῆρες - kde-full - (201009132215) ]
CPU Info 2x Pentium Dual-Core E6600 @ 2048 KB cache flags( sse3 ht nx lm vmx ) clocked at [ 3066.558 MHz ]
Videocard nVidia G96 [GeForce 9400 GT] X.Org 1.10.2 [ 1440x900@50.0hz ]
Network cards Realtek RTL8111/8168B PCI Express Gigabit
Processes 115 | Uptime 37min | Memory 494.2/2012.8MB | HDD ST3808110AS Size 80GB (22%used) | GLX Renderer GeForce 9400 GT/PCI/SSE2 | GLX Version 3.3.0 NVIDIA 275.09.07 | Client Shell | Infobash v3.36
-
Bei mir lief das dist-upgrage heute auch durch (32bit).
infobash -v3
Host/Kernel/OS "Vision" running Linux 2.6.39-2.slh.1-aptosid-686 i686 [ aptosid 2011-01 Γῆρας - kde-lite - (201102051540) ]
CPU Info 2x AMD Athlon X2 Dual Core BE-2350 512 KB cache flags( sse3 ht nx lm svm ) clocked at [ 2100.000 MHz ]
Videocard nVidia C68 [GeForce 7050 PV / nForce 630a] X.Org 1.10.2 [ 3200x1080@50.0hz ](zwei Monitore)
nVidia GT215 [GeForce GT 240]
Network cards nVidia MCP67
Processes 149 | Uptime 52min | Memory 731.1/1771.6MB | HDD ST3320620AS Size 320GB (57%used) | GLX Renderer GeForce GT 240/PCI/SSE2/3DNOW! | GLX Version 3.3.0 NVIDIA 275.09.07 | Client Shell | Infobash v3.36
;-=
-
Bei mir lief das dist-upgrage heute auch durch (32bit).
Das tat es bei mir auch, nur habe ich immer noch kein X auf 32bit.
-
Und ohne /var/log/Xorg.0.log wird Dir auch niemand sagen, warum das so ist.
-
http://paste.pocoo.org/show/417401/ sieht immer noch aus wie die da.
-
dpkg -l | grep nvidia
-
Bei mir ist nach dem Aufheben des holds für nvidia-Pakete auch wieder alles ok. 32-bit-System.
Danke für die Hilfe.
Neelix
-
dpkg -l | grep nvidia
http://paste.pocoo.org/show/426675
-
Hallo Leute.
Nach dem ich hier gelesen hatte, das mit dem fglrx 1:11-6-1 alles wieder im Lot sei, hab ich ein du gemacht.
Das gute: X startet mit fglrx. Nachteil: keine OpenGL Porgramme laufen mehr. Wine und native Programme/Spiele sind betroffen. Compiz geht aber wundersamerweise.
Immer kommt diese Fehlermeldung:
../../src/xcb_io.c:452: _XReply: Assertion `!dpy->xcb->reply_data' failed.
signal caught: Aborted
oder in deutsch:
../../src/xcb_io.c:452: _XReply: Zusicherung »!dpy->xcb->reply_data« nicht erfüllt.
Mit dem radeon habe ich die Probleme nicht, muss also irgendwie an fglrx liegen.
X.log zeigt nichts auffälliges (keine Errors)
Danke erst mal
-
Um mal richtig böse zu sein: Blätter mal ein paar Seiten zurück - zur Stelle mit dem Platt- und Neumachen. Es ist wohl möglich oder eher wahrscheinlich, dass das immer noch seine Gültigkeit hat. Bei mir hat das seit glx-alternative-fglrx 1.2 funktioniert. sid ist 1.4, die nächsten Änderungen stehen in experimental bereit. Alles zum Thema diversions. Dass ist jetzt wirklich bleeding. Ausentwickelt ist was anderes.
http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&p=9497#9497
-
Hi agaida
Ich hab frglx schon komplett runter geworfen und neu installiert. Hat nix gebracht. Soll ich die 3 glx/mesa libs downgraden auf stable (testing funktioniert irgendwie nicht *) und dann fglrx runter und wieder drauf ?
* Ich hab testing Einträge in der srouces.list und wolle das mit apt-get install lib.../testing downgraden es kam aber die Meldung das diese schon aktuell seien..
UPDATE:
Ich ziehe grade den glx krams auf expermental wie ayla das gemacht hat. Ich berichte dann hier.
Danke
-
...wie ayla das gemacht hat.
hmm, naja, optimal war das bei mir nun nicht gerade gelaufen...
Nach 3 Stunden wieder an die Kiste gesetzt, das Gleiche zum x. Mal nochmal gemacht: ....und läuft! Warum? Keine Ahnung,...
Also vielleicht nicht wirklich zum nachmachen empfohlen, auch wenns letztendlich doch noch geklappt hat.
Gruß
ayla
-
@manuel: Ich glaube nicht wirklich, dass das hilft. Da ich das schon vor einer Weile gemacht habe, kann ich nicht sagen, was mit dem aktuellen Stand schiefgelaufen ist. Wahrscheinlich wird aber einer der Links durch die diversions nicht neu gesetzt. Schlussendlich war es so, dass der 2D-Bereich ging, aber ein Hau mit dem fglrx-glx bestand, der zeigte einfach auf einen falschen Blob. Wenn Du also gar nicht weiterkommst, dann meld Dich nochmal hier, dann muss mein X halt noch einmal der Variante aus stable weichen. Mal sehen wo es dann hakt. Handauflegen über 2 Versionen ist blöd.
-
Hi
Also es gibt keinen richtigen Erfolg zu vermelden. Einiges startet zwar wieder aber anderes läuft immer noch nicht.... Jetzt ist es wohl ein totales Kuddelmuddel in dem Grafiklibs. Einige Programme finden die libs wohl, andere brauchen vielleicht noch was? Keinen Durchblick...
Was soll ich jetzt machen um wieder ein konsistentes oder funktionierendes System (full 3D) zu haben ?
Die glx Sachen aus stable benutzen und dann gucken was geht ?
Wie sehen die Maintainer eigentlich die Geschichte, wann werden die das Richtig fixen ?
Etwas Ratlos
Manu
-
Ich habe das gesamte alte Geraffel rund um glx, mesa und fglrx restlos manuell entfernt. Also so richtig mit rm und so ;). Halt alles, was irgendwie mit dem Thema glx in entferntester Weise zu tun haben könnte und nach dem purge der Pakete noch im System rumgammelte.
Danach das Zeug aus Sid eingespielt und es war gut. Seit dieser Aktion habe ich Ruhe. Ich vermute mal, dass grade bei den ersten Paketen noch einige Sachen stehengeblieben sind, die so nicht sollten. Links, die nicht abgeräumt wurden, da noch fehlerhafte implementation etc. pp.
Leider habe ich das nicht dokumentiert. Mir war an den Ausgaben nur aufgefallen, dass bestimmte Links wiederverwendet wurden. Nachdem das alles gekappt war, war alles Friede/Freude. Ich kann Dir dieses Vorgehen nur empfehlen, wenn Du Dir absolut sicher bist, dass Du weisst, was Du tust und eventuelle Missgriffe ohne Probleme entsorgen könntest. Das könnte sonst eventuell zu einem mehr oder weniger nicht mehr ohne Probleme wartbaren System führen.
EDIT: Ich habe grade noch eine Aptosid-Installation gefunden, die ewig nicht aktualisiert wurde. Mal sehen, was die von einem Update hält.
-
Ok das hört sich interesannt an. Woher weis ich was alles mit glx zu tun hat und wo da was zurück bleibt, weil wenn ich die mit purge entferne sind ja normal auch die Dateien weg und wenn er was nicht löschen kann sollte apt mir das doch sagen oder ?
Werde das wohl eher morgen Testen muss jetzt noch ne Ubuntu install bei nem Kumpel durchziehen.....
Danke für den großen Einsatz
-
So sollte es sein. Und jetzt stell Dir bitte vor, dass irgend etwas schiefgeht. Kleine Liste der Möglichkeiten: Nicht alles, was Vorgängerpakete hinterließen, wurde richtig abgeräumt, weil Dateien, links, Verzeichnisse entweder vergessen wurden oder aber es Wechselwirkungen gab, die nicht berücksichtigt wurden. Oder es fehlten Rechte oder irgend welche anderen Bedingungnen waren nicht erfüllt. Wie soll apt-get wissen, was schiefgelaufen ist? DonKult kann vieles, aber die Fähigkeit des vorrausschauenden Handauflegens wird auch ihm fehlen.
Im Normalfall nennt man das dann Sid, wenn man das dann mit experimental aufpeppt, kann es sein, dass man Spass bekommt. Wohlgemerkt, ein Großteil der Abwicklung ist neu. Das meinte ich mit "Ich lehne mich erst mal zurück und schaue mir das in Ruhe an.
Mein Update läuft, ich glaube ich hab das Notebook längere Zeit vergessen gehabt. Mal schauen, was passiert.
620 aktualisiert, 23 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.
Es müssen 1.067 MB an Archiven heruntergeladen werden.
-
ERgebnis:
Soll: http://img35.imageshack.us/img35/169/fglrxrichtig.jpg
Ist: http://img801.imageshack.us/img801/5760/fglrxfalsch.png
Gist: https://gist.github.com/1072503/158e5f78ed4e6be8218d658ae44dd4d2420e0480
Nur mal so zum Vergleichen. So wie das Bild richtig sollte es momentan aussehen. So wie bei falsch sieht es nach meinem Update unbemuckelt aus. GLX läuft aber erstaunlicherweise.
-
Ich habe das gesamte alte Geraffel rund um glx, mesa und fglrx restlos manuell entfernt. Also so richtig mit rm und so Wink. Halt alles, was irgendwie mit dem Thema glx in entferntester Weise zu tun haben könnte und nach dem purge der Pakete noch im System rumgammelte.
Danach das Zeug aus Sid eingespielt und es war gut. Seit dieser Aktion habe ich Ruhe.
Kann das irgendwie nicht nachvollziehen. Siehe meine einträge oben. Bei mir ging es recht fix ohne solche verrengungen.
Ist und soll: http://www.dritimage.de/uploads/bilder/131016114332_Bildschirmfoto32.jpeg
-
Ich habe eigentlich nicht vor, zu rechthaberisch zu sein. Nach der Installation eines neuen Treibers erwarte ich aber eigentlich die komplette Kennung des Treibers in den entsprechenden Feldern zu sehen. Das gilt vor allem für die Version. 11.2 aus Ende Januar diesen Jahres macht mich da nicht unbedingt glücklich. eher im Gegenteil. ;) Ich bin halt so ein Zahlenmensch, bei dem das seine Richtigkeit haben sollte. So gefällt mir das viel besser.
-
@manuel und @all: eventuell ist es besser, einfach mal eine Runde mit dem fglrx auszusetzen. Falls das Kind schon in den Brunnen gefallen ist, könnte das folgende Vorgehen helfen. Allerdings ohne Garantie. Getestet auf Ph 2 965 mit 4890 und intel core2duo mit 3450 (beide amd64):
dpkg --purge fglrx-atieventsd fglrx-control fglrx-driver fglrx-glx fglrx-glx-ia32 fglrx-modules-dkms
dpkg --purge glx-alternative-fglrx glx-alternative-mesa glx-diversions
dpkg --purge --force-all libgl1-mesa-glx
rm -rf /usr/lib/mesa-diverted # falls noch existent
reboot
Man sollte nach dem reboot in der Konsole landen:
apt-get -f install # der repariert libgl1-mesa-glx
apt-get --reinstall install xserver-xorg-core # nur zur Sicherheit
apt-get install fglrx-atieventsd fglrx-control fglrx-driver fglrx-glx fglrx-glx-ia32 fglrx-modules-dkms
aticonfig --initial --force
reboot
Vielleicht ist das ein oder andere über an dieser Auflistung. Es sollte zumindest nicht mehr kaputtmachen, als eh schon kaputt ist ;) Bei mir hat es genau so funktioniert, mehrmals auf verschiedenen Kisten.
-
Ich glaube das löschen der xorg.conf und ein anschließendes "aticonfig --initial" in init3 sollte reichen ... kann mich aber irren ;)
-
Ich würde zwar auch agaidas Rat folgen und den fglrx erst mal in Ruhe lassen falls er funktioniert, aber ich hab's ja schon hinter mir :)
Keine Ahnung ob's jemand hilft, bei mir läuft das Ganze mit einer minimalen xorg.conf.d/20-fglrx.conf und den weiter oben angegebenen Versionen:
Section "Device"
Identifier "screen0"
Driver "fglrx"
EndSection
Gruß
ayla
-
So, gerade mal einen d-u gemacht mit der 32bit. Kam 'ne Menge rein, auch nvidia und alternatives Gedöns. Ändert aber gar nix. Kein X und immer noch "Failed to load module 'nvidia', module does not exist". Ich bring den Rechner gleich innen Keller und verwix den dermaßen... :x
-
Moin,
und was spricht gegen den "oginal' Nvidia Treiber ?
Brgds
Henning
-
Wie immer: Nichts, wenn Du es schaffst, den zum Laufen zu bewegen. ;) - Die Kleinigkeiten wie offizielle Unterstützung, proprietär, kein Support vergessen wir an dieser Stelle mal.
-
hmm,
der "original Nvidia-Treiber läuft hier auf drei Kisten problemlos. Wäre schön wenn das mit dem ATI beim Laptop auch so klappen würde.
Allerdings "habe ich ihn über die "teuflischen" Scripte von h2 installiert.
Grüße
Reiner
-
Naja, wozu man ein sinnloses Script benötigt, um Nvidia Treiber zu installieren, habe ich nie verstanden.
-
Naja, es läuft damit und in der Vergangenheit gabs mal Probleme und mit dem Script eigentlich nie. Ausserdem macht es ja nicht nur die Installation von Grafik-Treibern. :)
Grüße
Reiner
-
Moin,
aha , es gibt doch noch mehr Leute die das "Script" benutzen ;-) nicht nur ich.
Tschuess
Henning
-
ich hab ja immer noch nicht verstanden, was smxi/sgfxi bringen sollen.
wird auch so bleiben, fürchte ich.
und ja, ich habs damals getestet.
ich fand es nur fürchterlich langatmig und unnütz geschwätzig.
abgesehen davon, dass es kernel debian-unkonform in einem zusätzlichen directory tarnt.
greetz
devil
-
ich hab ja immer noch nicht verstanden, was smxi/sgfxi bringen sollen.
Ich werd's gleich mal testen, der Debian konforme Weg bringt mir seit 3 Wochen kein X auf die Beine. :o
-
ich hab ja immer noch nicht verstanden, was smxi/sgfxi bringen sollen.
Ich benutze es heutzutage auch nicht mehr. Es geht also auch ohne. Aber ich fand die Tools eigentlich immer recht gut.
Gerade aus Anfängersicht wird man mehr geleitet und bekommt auch direkt Warnungen und Hinweise zur neusten Situation in debian/sid präsentiert. So Dinge wie: "Paket xyz wird removed. Das ist ok, weil ersetzt durch Paket abc." Oder: "Achtung: Momentan nicht upgraden, weil..." Auch passierte es nicht, dass man vergessen hat, nvidia-glx nachzuinstallieren, weswegen X nicht mehr startet, weil alles automatisch ging.
Klar, man kann das alles manuell machen und sich die Warnungen und Infos aus dem Forum ziehen. Aber eleganter ist es, diese direkt vor dem Upgrade auf den Schirm zu bekommen.
Gruß,
arwa
-
Dieses so hoch gelobte Script hat oft genug Unsinn gemacht!
Da werden Pakete auf hold gesetzt, dann wird der hold nicht wieder gelöst und das System wird inkonsistent.
Was das mit Einsteigerfreundlich zu tun hat, weiss auch nur der Maintainer.
Außerdem kann ein undedarfter User mit der Meldungsflut in der Regel eh' nix anfangen.
-
Nun ja, wers verwenden will und damit klarkommt verwendet es, wer nicht verwendet es halt nicht :)
Bisher hatte ich noch keine ernstlichen Probleme damit sondern im Gegenteil manche Probleme die anderorts, besonders im X-Bereich, auftraten hatte ich erst gar nicht. Daher bleibe ich auch dabei. Wenn ich damit echte Probleme bekomme werde ich mal ein ernstes Wort mit "dem Mann im Spiegel" wechseln. :P
Grüße
Reiner
-
Jetzt habe ich mal den einbeinigen Dreisprung gemacht.
apt-get update
apt-get purge $(dpkg -l | awk '/nvidia/{print $2}')
apt-get install nvidia-kernel-source nvidia-kernel-common nvidia-glx # Das zog dkms als "Neu" mit
apt-get dist-upgrade # da kam xserver-nvidia mit
m-a clean nvidia-kernel-source && m-a a-i nvidia-kernel-source
apt-get install --reinstall nvidia-glx
Ein Reboot spaeter, immer noch "failed to load module nvidia..."
Witzigerweise zeigt lsmod 'nvidia' als geladen an
OK, dann soll es sein. sgfxi
Der behauptet nun es sei gar kein X installiert: http://paste.pocoo.org/show/435223/
Also selbst das "Allheilmittel" will nicht. Ich habe ab Mittwoch eine Woche frei, werde wohl mal neu installieren.
-
dkms und nvidia-kernel-source auf einem system muß schief gehen.
-
Da werden Pakete auf hold gesetzt, dann wird der hold nicht wieder gelöst und das System wird inkonsistent.
Was das mit Einsteigerfreundlich zu tun hat, weiss auch nur der Maintainer.
Gerade das automatische hold-Setzen bei inkonsistenten Paketversionen, so dass bspw. openoffice so lange zurückgehalten wurde, bis alle wesentlichen Pakete von der Versionsnummer zusammenpassen, dasselbe bei diversen gnome Paketen, etc., fand ich eigentlich immer ziemlich cool. Probleme, dass Pakete auf hold blieben hatte ich nie gehabt.
Aber ok, ist OT hier, und ich kenne die Meinung des aptosid-Teams dazu, die ich durchaus auch nachvollziehen kann, auch wenn ich es nicht so einseitig extrem sehe. Der Hauptgrund, warum ich es nicht mehr einsetze ist, dass ich damit eine Quelle weniger habe, von der elementare Dinge installiert werden. Schon bei der debian-Distri, aber auch bei aptosid-Paketen muss man ja Unbekannten gegenüber ein recht großes Maß an Vertrauen haben.
Gruß,
arwa
-
dkms und nvidia-kernel-source auf einem system muß schief gehen.
Ich möchte zwar keine Werbung dafür machen, aber bei mir (64Bit) funktioniert genau das ausgezeichnet, im Moment mit Version 275.09.07-4
-
Ich hab' wieder X mit der 32bit. Das sgfxi behauptete es sei kein X installiert brachte mich auf die Fährte.
startx
/usr/bin/X not found
dpkg l *x*
rc xserver-xorg
apt-get install xserver-xorg
Das hat dann noch -input-all mitgezogen und libgl1-mesa-dri vorgeschlagen, das hab ich auch noch installiert und nun kommt X wieder hoch.
oppa@oppa-mag:~$ glxinfo
name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
-
ich hab ja immer noch nicht verstanden, was smxi/sgfxi bringen sollen.
....
devil
Hab auch KA da diese Scripte oft genug nur Ärger bringen auch teilweise "Out To Date".
Verstehe auch oft nicht warum unbedingt die Leute proprietäre 3rd Software installieren müssen obwohl die "*nix/Debian" Software genauso gut rennt ("Kinder des Lichts Mentalität"?). Persönlich habe ich seit Mesa 7.10.2-3 (Nv: 275.09.07-2) keine Probleme. Nutze aber in normal Fall nur Opensource Treiber. Die einzige noch vorhandene AMD/ATI Kiste rennt absolut Ruhig dank KMS. Ich weiß auch das jede(r) Rechner/Hardware Konfig anders reagiert aber wer nicht darauf reagieren kann,sorry sollte sich überlegen ob Debian insbesondere Testing/Sid bzw überhaupt ob *nix Systeme für ihn was sind.
Huch schon wieder zu viel OT :roll:
-
ich kann sehr wohl verstehen wenn user -begründet- proprietäre treiber wollen oder brauchen.
ich hatte keine lust mehr auf das geraffel und habe auch am desktop jetzt intel. (i7 2600k mit HD3000 grafik)
greetz
devil
-
+1 (Deshalb kloppe ich aber nicht meine 4890 in die Tonne, die brauch ich zum Zocken unter Windows, wenn ich mal dazu komme.
@Saint:
Irgendwas wirfst Du da ganz gewaltig durcheinander. Der Einsatz proprietärer Treiber hat aber auch gar nichts mit der Befähigung zu tun, sid zu fahren. Der Einsatz bestimmter Programme und Scripte auch nicht. Das ist alles eine Frage der persöhnlichen Vorlieben und des Anspruchs. Du meinst auch nicht zufällig dieses prorietäre 275.09.07? Etwa, weil laut Devils Umfrage eigentlich kaum jemand dauerhaft nouveau fährt?
Ich kann da nur für mich sprechen: Ich teste regelmäßig die freien Radeon-Treiber. Meist sogar 2-3 Tage. Dann habe ich die Nase voll und die kommen in die große Reifetonne. Bei der grundlegenden Entscheindung mit den Kriterien funktioniert mit voller Leistung, funktioniert, funktioniert teilweise, funktioniert kaum, frei, unfrei wäre mir (funktioniert, frei) mit am liebsten. Bis dahin heisst es ganz eindeutig (funktioniert mit voller Leistung, unfrei).
Das ist doch das Schöne an Linux. Eigentlich kann jeder Anwender ohne Scheuklappen das machen, was er will. Wenn er es denn kann.
-
Ich bin auf 2 Desktops mit core2 duo auf asusbords mit passiv gekühlten 8500 gt von nvidia auf nouveau umgestiegen. reicht für meine Bedürfnisse. Auf dem rechner mit amd64 aptosid absolut keine probleme, auf dem i686 hab ich aber auch andere Probleme, nicht nur mit der Grafik. Jetzt wo 2011-2 raus ist werde ich mal neu amd64 installieren. Werde dann über nouveau berichten.
-
Hallo @Saint,
Verstehe auch oft nicht warum unbedingt die Leute proprietäre 3rd Software installieren müssen obwohl die "*nix/Debian" Software genauso gut rennt
Das stimmt nicht. Man nehme eine aktuelle Nvidia Karte, lasse sie mit nouveau laufen und probiere mal damit unter KDE verschiedene Desktop Effekte zum Laufen zu bringen. Das gleiche mache man dann mit einem aktuellen proprietären Nvidia Treiber.
Oder ironisch gesagt: Die KDE Entwickler sollten sich überlegen, ob Linux die richtige Plattform für ihre Software ist, packen sie doch Sachen in ihre Software, die mit verschiedenen modernen Grafikkarten unter Einsatz von freien Treibern nicht zum Laufen zu bringen ist.
Nun könnte ich ja konsequent auf Intel Grafikkarten setzen, weil die Treiber frei sind.
Hast Du schon mal versucht, die freie Software Vegastrike mit einer Intel Grafikkarte oder mit nouveau und einer Nvidia Karte zum Laufen zu bekommen?
Das ist nur ein kleiner Bereich von Nutzerbedürfnissen, den ich hier aufgezählt habe und ich sehe nicht ein, warum Leute mit solchen Bedürfnissen kein Linux mit proprietären Grafikkartentreibern verwenden sollen.
Viele Grüße,
Holger
-
Ich setz das mal auf gelöst. Bei wirklichen Problemen mit einem kommenden neuen Treiber bitte einen neuen Thread. Ansonsten könnten wir nvidia und fglrx auch gleich sticky machen. Das nimmt der Sache aber die Bedeutung. Das es Probleme geben kann und auch wird, ist Allgemeingut.