Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Das ist der Punkt, das tut es derzeit für niemanden. Das Ding ist noch in voller Entwicklung :-) . die haben gerade ein paar der Grundlagen fertig und hier und da läuft auch was damit, das meiste dann langsam.
Du dachtest nicht wirklich, das die schon soweit sind, das man das Produktiv einsetzen kann?
Hätte aber schon gedacht, das da für den Dektop nicht solche Probleme auftauchen wie du sie hattest. Der dürfte ja auch mit opengl laufen und nicht Vulklan, die Spiele dann erste übertwiegend mit Vulkan.
Ergänzung ()
Alexander2 schrieb:
aber da gibbet doch jetzt nen NVK offenen Nvidia Vulkan Treiber, der tatsächlich auch schon Vulkan 1.0 Tests schafft.
Ach,von der Feature Matrix her sieht der Nouveau Treiber nicht mal schlecht aus, was den Zustand angeht. Ich denke am meisten haut da wirklich nvdia-utils dazwischen, weil das wohl den "echten" nvidia Treiber erwartet.
Ich habe heute nochmal mit dem nvidia Treiber und MangoHud getestet. Aber schlauer bin ich nicht wirklich geworden. Ich dachte erst, es gibt einen Unterschied, ob DXVK oder VKD3D verwendet wird. Je mehr Spiele ich getestet habe, desto weniger wurde die Vermutung allerdings bestätigt
Einzig halbwegs reproduzierbar ist, dass wenn die Auslastung der Grafikkarte über 40% steigt, die Wahrscheinlichkeit für das Spulenfiepen sehr hoch ist. Ist jedoch logisch, weil dann mehr Leistung bzw. Strom benötigt wird und schon ist man wieder beim Ausgangspunkt: der Energieverwaltung 😅
nvidia direkt zu kontaktieren scheint auch nicht mehr wirklich möglich, die haben hier bis auf ihr Forum alles runter genommen, was irgendwie nach Kontaktmöglichkeit / Ticket aussieht... Der Hardwaresupport ist "nicht mehr vorhanden" aka error 404 und das Kundenfeedback befindet sich gerade im "Wartungsmodus". Allerdings habe ich nicht wirklich was anderes erwartet, die verkaufen genug. Da ist Nachsorge nicht ganz so wichtig.
Ist bei beiden Bootloadern grundsätzlich erstmal der gleiche Vorgang, wenn du in der Auswahl bist einmal e drücken. An die Ende der Zeile packst du dann ibt=off. Da ist die Einstellung dann auch nur für den einen boot aktiv. Kannst damit auch nix kaputtmachen dadurch. Wenn das funktioniert, je nach Bootloader permament setzen https://wiki.archlinux.org/title/Kernel_parameters
Läuft bei mir auch seitdem absolut problemfrei, auch nach Updates.
So, nun habe ich eine externe SSD bespielt, da kann ich das System nach Herzenslust zerschießen
Erster Start nach der OS Installation lief gut, nach der Installation der Nouveau Treiber über nvidia-inst blieb er wieder beim Start in der Konsole bei [OK] Reaching target Graphical Interface hängen... Habe daraufhin den Start über den Parameter ibt=off probiert, gleiches Ergebnis (habe allerdings auch keine Intel CPU).
Im Arch-Wiki gab es noch die Empfehlung mit nouveau.config=NvBios=PRAMIN zu starten, ebenfalls der gleiche Stop. Dieses mal ist ebenso (noch) nichts von nvidia-utils vorhanden, es erfolgt definitiv kein Blacklisting in /usr/lib/modprobe.d/ des Nouveau Treibers, welches den Start verhindern könnte. nomodeset ist auch nicht in den Startparametern vorhanden.
Er hängt sich allerdings nie komplett auf, über Strg+Alt+Entf leitet er einen geordneten reboot ein. Mir ist allerdings aufgefallen, dass es ein Kernel Update auf 6.7 gab, mein produktives System bzw. die Tests vorher liefen mit Kernel 6.6.10.
//Edit: Kann ich in der Konsole (als angemeldeter root) Befehle auch als nicht-root ausführen? Bei der Notfall Boot-Shell bin ich automatisch root, nvidia-inst will jedoch grundsätzlich erst mal mit Benutzerrechten ausgeführt werden....
ich meine sudo kannste sagen welcher Nutzer genommen werden soll, kannst im Handbuch per
man sudo
nachschlagen
Suchen darin geht wieder per vorangestelltem / und dann Suchwort
Ich meine ich könnte dir das jetzt raussuchen, aber wenn ich dir sage wie man sogar ohne Internet an die Info kommt hilft das vielleicht auch bei der nächsten Frage :-)
Kannst dich ja melden, wenn du es nicht findest.
Also [strg]+[alt]+[entf] kannste machen, geht vielleicht auch der wechsel in eine der TTY Konsolen?
[strg]+[alt]+[F1]
oder einer der anderen F* Tasten.
Dass ich sudo sagen kann, welcher Benutzer ausführen hatte ich mal gelesen. Dachte jedoch, da meine Benutzer alle "Systemverwalter" sind, ist es im Endeffekt dann ebenfalls auf root Ebene. Mir fällt allerdings gerade auf, dass ich dann ja nicht in der Konsole immer sudo voranstellen müsste, wenn es so wäre X)
Ja, Strg+Alt+F2 ist möglich, dann lande ich scheinbar in der gleichen Konsole, wie wenn ich den Kernel-Parameter 3 beim boot anfüge.
Habe jetzt nochmal eine Neuinstallation mit dem LTS Kernel 6.6.11 vorgenommen (er installiert trotzdem den aktuellen 6.7. aber lässt beim booten die Wahl), ändert allerdings nichts am Ergebnis des hängen bleiben. Wenn ich [OK] Reaching target Graphical Interface suche, gibt es allerdings ein paar Einträge dazu. Bisher habe ich jedoch nichts gefunden, was mir hilft.
Habe mal noch den Log von Xorg gezogen (//Edit: und angehangen. Funktioniert nicht im "Spoiler"...)
[473.635] (EE) Screen 0 deleted because of no matching config section. Sieht nach einem Problem aus.
[[ 473.626] (II) NOUVEAU driver for NVIDIA chipset families : Kann ich nicht nachvollziehen, da würde der Support bei der GeForce GTX 10xx Familie enden?
Habe mir die Nouveau Seite ebenfalls nochmal angeschaut, und wollte dmesg | grep -i chipset prüfen, es erfolgt keine Ausgabe.
Als Lösung hbe ich noch systemctl start graphical.target gefunden, ohne sudo will er eine Authentifizierung haben (die nach Eingabe des Passwortes fehlschlägt), mit sudo passiert nichts.
Das was du da bekommst beim Booten um einen Kernelparameter anzufügen ist eine behelfskonsole.
Das was du beim gebooteten System bekommst beim Drücken auf die genannte Kombi ist Das TTY, das ist das volständig laufende System. da kannst du ich mit Benutzername und Passwort einloggen und "alles" machen...
Nur mal so doof aufgezählt, auch wenn das heutzutage keiner mehr ernsthaft in der Konsole macht:
Im internet Browsen, das System einstellen/umstellen, Programme installieren/deinstallieren, Dienste starten/beenden/ dem Desktop auch sagen, dass er starten soll, emails schreiben, Briefe schreiben, Dateien verwalten, die Maus benutzen (ja ernsthaft)...
Aber wie schon gesagt typischerweise benutzen die meisten Nutzer, wenn nicht gerade wegen einem Fehler der Desktop nicht startet eben den Desktop und die Grafischen Programme.
Das das da ist bedeutet im Grunde auch, das dein System komplett gestartet ist und nur der Desktop/dein Grafisches UI/"DE" ein Problem hat. Evtl. eben nen Treiberproblem, das X11 nicht starten lässt, wenn es eben X11 ist, was benutzt wird.
Also statt die ganze schose alle 5 Minuten neu zu installieren könntest du einfach in der KOnsole andere Pakete installieren lassen, die config dort anpassen, da neustarts befehlen, oder herunterfahren.
Nur mal so.. aber ja, da müsste man sich schon ein klein wenig einarbeiten um da zu wissen was man so machen kann.
Um das zu lernen kann man durchaus die "zu Fuss" also ohne Installer installation von Arch empfehler (oder Gentoo)
Da wird man in dem zuge alles mögliche an Orten für die konfiguration, die Tools die man dazu nutzt, sowie auch kennenlernen wie man was installiert ohn GUI, wie man Benutzer verwaltet, Netzwerk einstellt ggf.. Was so installiert wird um eine GUI zu bekommen.
syntax868 schrieb:
Als Lösung hbe ich noch systemctl start graphical.target gefunden, ohne sudo will er eine Authentifizierung haben (die nach Eingabe des Passwortes fehlschlägt), mit sudo passiert nichts.
Nuja, Bei so einer zu Fuss Installation gehört auch als Erklärung hinzu, das nach der Unix/Linux Konsolenphilosphie bei Erfolg keine Meldung erfolgt. Bei misserfolg gibt entsprechend geplärre.
Anscheinend "läuft" dein graphical.target halt ja auch schon und so gibt es keine Fehlermeldung - es läuft - kriegt nur nichts geschissen wegen Treiberfehlern/etc.
Ergänzung ()
syntax868 schrieb:
[[ 473.626] (II) NOUVEAU driver for NVIDIA chipset families : Kann ich nicht nachvollziehen, da würde der Support bei der GeForce GTX 10xx Familie enden?
Jop, eindeutig ne? Die Version die du installiert hast ist nicht was du brauchst, oder nicht richtig konfiguriert, deine Karte wird nicht unterstützt insofern die neuer als die genannten ist...
Also besorg die entweder die passende Beta/Git, die neuere Karten unterstützt, oder .. framebuffer sollte auch gehen (also quasi keine Grafische Beschleunigung aber besser ist der Proprietäre Nvidia Treiber, wenn du nicht an den nouveau Treiber kommst, der neuere Karten unterstützt.
Ich muss damit nicht rumprobieren und habe auch garkeine Nvidia Hardware, meine Vermutung ist jedoch, das du eine Git version von Mesa/Kernel brauchst damit die ganze schose zum laufen kommt mit dem neuen Treibern, die unterwegs sind.
Das das bei den 0815 ausgelieferten Systemen noch keiner live geschaltet hat ist nur vernünftig, nicht jeder will mal eben ein bischen herumbetatesten. da muss man sich das neueste Zeug erstmal besorgen.
Aus eigener Erfahrung mit einer "noch nicht" unterstützen Grafikkarte, damals der Vega kann ich sagen, das sich den Kernel aus dem Git und das neueste Mesa holen dann entsprechend zu vollständig laufender Grafikkarte führte (noch durchaus mit Bugs ganz zu Anfang). Aus dem Git holen bedeutet dann selber kompilieren.
Das was du beim gebooteten System bekommst beim Drücken auf die genannte Kombi ist Das TTY, das ist das volständig laufende System. da kannst du ich mit Benutzername und Passwort einloggen und "alles" machen...
Funktioniert beim boot mit der 3 scheinbar ebenfalls (die GUI wird halt nicht gestartet). Bisher habe ich die 1 verwendet, hier ist allerdings nur root möglich und es gibt z.B. keine Netzwerkverbindung. Die 3 liefert einen normalen login.
Und ja: natürlich kann man sich alles von den Basics aufwärts erarbeiten. Mir stellt sich nur die Frage: wie lange behalte ich das Wissen, wenn ich es dann am Ende nicht wieder groß anwende? Die Chance, einen großen Teil davon wieder zu vergessen, wenn alles läuft, ist da ziemlich groß. GRUB rescue? Gab es früher öfter mal, davon weiß ich jetzt nix mehr. Ubuntu Server einrichten? Hat man auf dem Pi paar Mal gemacht. Müsste ich mich aktuell wieder komplett belesen. Lernt man eine fremde Sprache, muss man Gelegenheiten haben sie anzuwenden. Sonst ist das ziemlich schnell für umsonst.
Alexander2 schrieb:
Also statt die ganze schose alle 5 Minuten neu zu installieren könntest du einfach in der KOnsole andere Pakete installieren lassen, die config dort anpassen, da neustarts befehlen, oder herunterfahren.
Wäre eine Möglichkeit. Ich könnte mir ebenfalls zum Testen eine andere Desktopumgebung installieren. Eventuell fehlt ja nur ein Paket? Das bringt dann der komplette GNOME Desktop mit aber am Ende weiß ich dann nicht, dass es nur dieses eine Paket war, was den Fehler behebt.
Eventuell verträgt sich Nouveau nicht mit dem KDE Display Manager SDDM? Dann bringt ein anderer Desktop ebenfalls einen anderen Display Manager mit, aber den könnte ich genauso in EndeavourOS einfach auswählen, statt eine neue Desktopumgebung zu installieren. Im Arch Wiki wird ja z.B. die Verwendung vom proprietären nvidia Treiber und dem Nouveau Treiber zusammen erläutert. Da ich allerdings nicht so in der Materie bin, weiß ich am Ende vermutlich nicht, was genau denn jetzt zur Lösung meines Problems geführt hat, wenn ich Dinge zur Fehlerbehebung kombiniere. Daher lieber komplett aufsetzen und am Ende weiß ich: das jetzt getestete Szenario funktioniert 100%ig so auf meinem System (bis zum nächsten Update ).
Alexander2 schrieb:
Jop, eindeutig ne? Die Version die du installiert hast ist nicht was du brauchst, oder nicht richtig konfiguriert, deine Karte wird nicht unterstützt insofern die neuer als die genannten ist...
Also besorg die entweder die passende Beta/Git, die neuere Karten unterstützt, oder .. framebuffer sollte auch gehen (also quasi keine Grafische Beschleunigung aber besser ist der Proprietäre Nvidia Treiber, wenn du nicht an den nouveau Treiber kommst, der neuere Karten unterstützt.
Aus eigener Erfahrung mit einer "noch nicht" unterstützen Grafikkarte, damals der Vega kann ich sagen, das sich den Kernel aus dem Git und das neueste Mesa holen dann entsprechend zu vollständig laufender Grafikkarte führte (noch durchaus mit Bugs ganz zu Anfang). Aus dem Git holen bedeutet dann selber kompilieren.
Nouveau ist die aktuellste stabile Version, ebenso mesa. Der Witz ist ja: laut freedesktop.org bzw. der feature Matrix werden Karten bis zur 4090 unterstützt. Somit ebenfalls meine 2080 Ti. Allerdings wohl noch nicht vollständig. Aktuell überlege ich, ob es da beim Desktopbetrieb an der mangelnden 2D Unterstützung liegt. Würde jedoch die Frage aufwerfen: warum 3D Unterstützung fertigstellen, wenn noch nicht mal 2D funktioniert? Der geschlossene Treiber von nvidia funktioniert, bzw. der open dkms ebenfalls, den habe ich zwischendurch mal getestet. Nur besteht eben bei beiden das Spulenfiepen. Selber kompilieren war eine Überlegung, aber da müsste ich mich definitiv noch deutlich mehr einlesen.
Alexander2 schrieb:
es gibt wohl einfach nichts, das als chipset auftaucht.
Nutze halt dmesg | less
Wenn im Auto bei 2000rpm der Kaffeebecher vibriert, dann fang ich nicht an meinen Fahrstil zu ändern, sondern kleb den fest.
Und genau das würde ich hier auch machen. Versuche das Quellbauteil ausfindig zu machen (Flüstertüte, eingerolltes DIN A4 Blatt als "Richtmikrofon") und versteife/vergieße das Ding. Vielleicht ist es ja nicht mal die Grafikkarte (sondern Netzteil oder VRMs).
Alternativ die Hochfrequenzcharakteristik berücksichtigen. Drehe den Rechner um 15°, stelle ihn in eine etwas andere Position, stelle ein Brett vor oder ähnliches. Gerade der obere Frequenzbereich lässt sich "richten" und blocken. Vielleicht kann man da was machen.
Ja nun, der Nouveau lädt ja garnicht erst, das haste ja schon selbst erkannt. da braucht man garnicht erst über kompatibilität nachdenken. oder ein zum DE fehlendes Paket. Eher über ein anderes Treiberpaket, eben entweder die proprietären oder sich was vom git ziehen.
Das mit diesem kernel Modul hatteste auch mal gelesen? da gehts auch um die 2000er Serie
Alternatively for the Turing (NV160/TUXXX) series or newer the nvidia-open package may be installed for open source kernel modules on the linux kernel (On other kernels nvidia-open-dkms must be used).
This is currently Beta quality on desktop cards, so there will be issues. Due to nvidia-open issue #282, it does not work on systems that have AMD integrated GPUs.
Dieses nvidia-open (wenns nicht arch ist mag es anders heißen)
bei der matrix fehlt übrigends alles was 2d angeht. ob das dann ausreicht?
Da bei den neueren radeon karten ist alles abgehakt, auch 2d https://www.x.org/wiki/RadeonFeature/
Und dann trinkst Du mit dem Strohhalm?
Eine Veränderung an der Karte selber kommt nicht in Frage, da unter Windows keinerlei Geräusche mit vsync auftreten. Es handelt sich hierbei daher ausschließlich um ein Treiberproblem unter Linux und keinen "Mangel" an der Karte.
Alexander2 schrieb:
Das mit diesem kernel Modul hatteste auch mal gelesen? da gehts auch um die 2000er Serie
Ich hatte den nvidia-open-dkms getestet, den nvidia-open bisher noch nicht. Mit der git-Version und der compilierung habe ich mich heute etwas belesen, da werde ich allerdings wohl etwas Zeit für brauchen.
Bei Verwendung des GNOME Desktops läuft alles zum Start sauber durch, am Ende bleibt es jedoch bei einem command prompt statt der Desktop Umgebung. Konsole über Strg+Alt+F2 ist möglich.
Du könntest es dir in jedem Fall einfacher machen indem du abwartest :-) Es ist durchaus davon auszugehen, das ab einem gewissen Punkt der Entwicklung der Treiber als standard genutzt wird und man optional der Proprietären installieren kann (so herum vermute ich jedenfalls, es sei denn vielleicht die Distro ist aufs zocken spezialisiert)
Wie rum auch immer wenn es soweit ist, wird es auch problemloser sein ohne ein extra Menü dafür zu wechseln.
Mich drängt ja aktuell nix wirklich. Ich werde noch etwas probieren und dann schauen, ob ich noch zu einem Ergebnis komme
Mein Produktivsystem läuft ja soweit und es lässt sich alles nutzen. Notfalls über Kopfhörer, die tragen sich im Winter angenehmer als im Sommer und dann nehme ich das fiepen nicht so war.
Naja, es läge vermutlich an nvidia, den geschlossenen Treiber soweit zu verbessern, dass die Regulierung der Spannung etwas besser abläuft. Wenn es unter Windows funktioniert, sollte grundsätzlich nichts dagegen sprechen, dass es ebenfalls unter Linux klappt.
Das stimmt, jedoch ist auch der ganze andere Softwarekram anders und evtl der Auslöser.
Das die Karte und Netzteil/Mainbaord Kombi zum Fiepen neigt ist aber generell nen Fakt, gibt halt auch Karten-Kombis die das nicht haben, ob nunr unter Linux oder Windoes oder Freebsd oder Dos oder MacOs oder ..
Jedenfalls bei mir höre ich nix fiepen :-) (hatte aber auch mal so ne Karte - ist her)
