News Linux-News der Woche: Update-Probleme bei Arch, Steam Play für alle

[metoer]

Ich hatte das Problem beim Updaten mit pacman heute auch, habe dann einfach per

mv /usr/lib/firmware/nvidia usr/lib/firmware/nvidia.bak

den Ordner umbenannt. Ist zwar keine schöne Lösung, aber es hat funktioniert. Nvidia Hardware kommt mir in naher Zukunft sowieso nicht in die Kiste

Ich kann nur empfehlen sich in die Arch mailing listen einzutragen, zumindest in die announce und security Liste. Dann ist man eigentlich immer up to date bei diversen Problemchen.

https://lists.archlinux.org/mailman3/lists/?page=1

 

[mibbio]

wenn es dann die größten Klopper doch wieder als unbedingte Abhängigkeit hat, darunter nämlich intel, nvidia.

Man muss ja nicht das übergeorndet "linux-firmware" Paket installieren, sondern kann das auch deinstalliert lassen und nur die benötigten herstellerspezifischen "liniux-firmware-..." Pakete installieren.

Die Anleitung soll ja nur dazu dienen, das Updateproblem überhaupt erstmal zu lösen unter Beibehaltung des Status Quo der Installation.

 

[Fard Dwalling]

Nutze ich schon seit nen paar Tagen. Wusste nichtmal das das neu ist.

Von Linux zu Linux? Oder Windows als Host?
Ich meine Linux als Host ginge nicht.

 

[Egon82]

Linux (Manjaro) als Host, Android TV (Raspberry 5) als Client.
Steam version: 1747701111, Steam API Version: SteamClient022

 

[mibbio]

Von Linux zu Linux? Oder Windows als Host?
Ich meine Linux als Host ginge nicht.

Also ich habe es gerade mal ausprobiert mit Steam unter Arch Linux als Host und Steam Link App auf dem Smartphone. Hat wunderbar funktioniert.

 

[Fard Dwalling]

Weiß jemand wie lange das schon geht?

 

[Randnotiz]

wie lange das schon geht?

Bei mir geht das schon, mindestens seitdem sie In Home-Streaming zu RemotePlay umbenannt haben.

Also schon eine ganze Weile.

 

[Wau]

Ich hatte das Problem beim Updaten mit pacman heute auch, habe dann einfach per

mv /usr/lib/firmware/nvidia usr/lib/firmware/nvidia.bak

den Ordner umbenannt. Ist zwar keine schöne Lösung, aber es hat funktioniert. Nvidia Hardware kommt mir in naher Zukunft sowieso nicht in die Kiste

Ich kann nur empfehlen sich in die Arch mailing listen einzutragen, zumindest in die announce und security Liste. Dann ist man eigentlich immer up to date bei diversen Problemchen.

https://lists.archlinux.org/mailman3/lists/?page=1

Für KDE-Nutzer ist Apdatifier auch eine gute Lösung um schnell via Notifications über neue News/Updates informiert zu werden. https://github.com/exequtic/apdatifier

 

[Tevur]

Zum Thema "Steamplay für alle Titel":
Weiß jemand wie das dann bei Spielen ist, die native Spielversionen bieten und eben die Kompatibilitätsversion über Steamplay?

Auch die native Version nutzt SteamPlay, nämlich für die Runtimes (meist 1.0 Scout).
Du kannst für jedes Spiel in der Bibliothek die Spieldetails aufrufen (das i im Kreis) und siehst dann, ob das über SteamPlay über Linux-Runtime oder über Proton (und welche Version) läuft.
Ändern kannst du das in den Einstellungen bei Kompatibilität. Kein Haken heißt dort, dass die native Version verwendet wird, wenn vorhanden.

 

[DorMoordor]

Wann wird denn wohl Steam Remote Play über Linux gehen? Ich meine, letztens ging das noch nicht.

Also ich hab zumindest mit nem Kumpel schon Ende letztes Jahr Brotato im Koop per Steam Remote Play Together gespielt (Er Win, ich Manjaro, abwechselnder Host). Das lief ganz ok, lag aber hauptsächlich an unseren mickrigen Uploads.

 

[Real-Duke]

Ich hatte das Problem auch heute. Aber war fix zu lösen mit yay.
Danke für die News!

Bin unter CachyOS noch recht neu in der ARCH Familie, aber als ich das Problem sah, gab es den Fix dazu auch schon im Chachy Forum: https://discuss.cachyos.org/t/annou...-5-upgrade-requires-manual-intervention/10427

Alles in allem kein Problem

 

[aragorn92]

@Kaito Kariheddo @neutrongummi
Also WSL basiert auf Hyper-V und das ist ein Tier2 Hypervisor und bedingt Overhead wie andere (gute) Hypervisorlösungen auch. Der Overhead ist mittlerweile recht klein, da Adressübersetzung die CPUs bzw. deren MMUs erledigen, aber Overhead ist vorhanden. Bei der Grafikbeschleunigung hat sich Microsoft auch Mühe gegeben, dass OpenGL/Vulkan recht problemlos auf DirectX laufen können, inkl Videobeschleunigung.

Edit: Und generell scheint Microsoft den Linuxkernel (und HyperV) so erweitert zu haben, dass Linux (mehr oder weniger) direkt Windows APIs nutzen kann.

Edit2: KVMs VirtIO geht in eine ähnliche Richtung.

Stimmt nicht, Hyper-V ist sowohl unter Windows Server als auch unter den Client Systemen ein Type 1 Hypervisor. Die Host Systeme laufen da als privilegierte virtuellen Maschinen. Das ist auch der Grund, warum zum Beispiel VirtualBox Gäste bei aktiviertem Hyper-V und den restlichen Virtualisierungsfunktionen von Windows langsamer laufen.

 

[mibbio]

Das ist auch der Grund, warum zum Beispiel VirtualBox Gäste bei aktiviertem Hyper-V und den restlichen Virtualisierungsfunktionen von Windows langsamer laufen.

Kann Hyper-V immer noch keine Nested-Virtualization mit anderen (Typ-2) Virtualisierern, außer sich selbst?

 

[polyphase]

Das Problem mit der Nvidia Firmware hatte ich heute auch, obwohl ich keine Nvidia Hardware nutze.

Habe das Update erstmal verschoben, muss mir das genauer anschauen

 

[mae]

Da ist praktisch kein Overhead mehr

Ein Kollege von mir wollte auf unser git-Projekt (viele Unterverzeichnisse, viele Symlinks) mit git unter WSL zugreifen, aber es war extrem langsam; waehrend git unter Linux (auf bare metal) sehr schnell ist. Seine Loesung war dann, das Windows-git zu verwenden. Es haengt also sehr davon ab, was man tut, ob ein Overhead zu bemerken ist oder nicht.

 

[mibbio]

Das Problem mit der Nvidia Firmware hatte ich heute auch, obwohl ich keine Nvidia Hardware nutze.

Das liegt daran, dass bis unter Arch Linux das Paket "linux-firmware" installiert ist, welches bisher die Firmwares sämtlicher Hersteller enthalten hat - also auch die von Nvidia. Es war bisher nur nicht offensichtlich, weil es kein separates Firmware-Paket war.

Jetzt haben die Leute bei Arch aber dieses All-Inclusive Paket auseinandergepflückt und die ganzes Firmwares in einzelne Pakete für jeden Hersteller geschoben. Und diese neuen Einzelpakete sind alle eine Abhängigkeit von "linux-firmware".
Pacman sieht dann bei einem Update, dass es eine neue Version von "linux-firmware" gibt und will das entsprechend aktualisieren. Dabei sieht Pacman die neuen Abhängigkeiten von dem Paket, nämlich die ganzen "linux-firmware-..." und will die folglich mit installieren. Bei der Installation stellt Pacman dann bei "linux-firmware-nvidia" fest, dass dessen Inhalt ja schon von einem anderen Paket (nämlich der alten, noch installieren Version von "linux-firmware") auf dem Syetem vorhanden ist, wodurch es zu dem Konflikt kommt.

Die Lösung ist dann eben, die vorhandenen Dateien der Nvidia-Firmware loszuwerden, indem man die aktuell installierte Version von "linux-firmware", wo die Dateien bisher drin waren, zu deinstallieren und im Anschluss die neue Version davon mit den neuen Abhängigkeiten zu installieren.

 

[agon]

Also eigentlich braucht man kein "linux-firmware". Das sollte eher ein Meta-Paket werden.
Ich habe bspw. nur linux-firmware-amdgpu, linux-firmware-intel, linux-firmware-other & linux-firmware-qlogic installiert.
Halt, je nachdem welche Module bei mkinitcpio -P fehlen.

 

[flaphoschi]

Ich wünschte nVidia würde mal seine Treiber und Wayland in den Griff bekommen.

Es gibt da eine Lösung. Die wird Ihnen aber nicht zwingend gefallen. Nvidia rauswerfen. AMD oder Intel rein.

Der quellgeschlossene Treiber war immer eine miese Sache. Aber seit 2010 hat Nvidia den Anschluss komplett verloren und ist nur noch ein Querulant der Schaden anrichtet.

Intel war gefühlt immer quelloffen. AMD etwa seit 2010. Nvidia “theoretisch” jetzt, aber sie wollen ja nichts in Linux und Mesa mergen. Hängen um Jahre bei Wayland hinterher, weil man Wayland regelrecht verweigert hat. Gehen den Nutzer mit eigenem Treiberpaket auf die Nerven. Red Hat kopiert und forkt schon den Treiber…also noch mehr Arbeit.

Und dabei hat man jetzt extra für Nvidia noch Explicit Sync in Wayland eingebaut, weil sie es nicht Implicit Sync hinbekommen.

Aber sie haben ja ein Quasi-Monopol? Brauchen sie auch. Sonst kommen sie mit so etwas nicht durch:
https://registry.khronos.org/OpenGL/extensions/NV/NV_robustness_video_memory_purge.txt

TLDR: Unser Grafikkarten verlieren gerne mal den Inhalt im Videospeicher. Ja. Ist ein Fehler. Aber wir definieren das als Feature um. Ihr müsst immer nachfragen ob die Texturen weg sind. Wird bald gefixt. Viele Grüße aus 2016. Euer Nvidia.


Die Probleme beim VT-Wechsel, Suspend und mit Wayland sind - unter anderem deswegen - ein Nvidia eigenes Problem. Seit KMS ist das mit AMD und Intel einwandfrei immer sicher möglich. Und das ist auch schon alt.

Unser Geld ist das einzige was sie verstehen. Auch wenn wir “nicht viel zu sagen haben”.


PS: Das mit den eigenen Standards erinnert leider an Microsoft. Die Mail von Bill Gates mit der Bitte ACPI doch zu verpfuschen, damit das mit Linux nicht gut funktioniert, legendär. Gerichsfest in Iowa dokumentiert, hat nur 180 Millionen gekostet. Das die dann mit SecureBoot weiter machen war klar. Deswegen reguliert man und kommt nicht zehn Jahre später mit kleinen Strafen.

 

[moan1]

Danke für die Linux-News!

 

[Donnerkind]

Was mich an dem neuen Firmware-Paket wundert/nervt: wozu haben sie das überhaupt aufgesplittet, wenn es dann die größten Klopper doch wieder als unbedingte Abhängigkeit hat, darunter nämlich intel, nvidia.

Ich habe Grütze geredet. Das Paket linux-firmware ist nur noch ein Meta-Paket, das die von mir beanstandeten Abhängigkeiten hat. Aber nichts im System fordert, dass linux-firmware installiert ist. Ich habe es also runtergeworfen und von den firmware-Unterpaketen nur behalten, was ich wirklich brauche.