Bis vor kurzem war eigentlich alles noch im grünen Bereich, Steam war
und ist etwas schwierig, nicht vollständig funktionsfähig, ein wenig
divahaft, man kommt aber meistens irgendwie durch, man kann nur hoffen..
Vor einiger Zeit kamen dann Aufrufe auf Fedora 33 upzugraden, die ich
aufgrund früherer Schwierigkeiten lieber ignoriert hatte. Aber dann kam
so etwa zum Anfang das Jahres ständig ein Nagscreen über den Bildschirm,
doch mal den neuen Wine-Application-Starter zu installieren. Nicht, dass
ich das Ding gebraucht hätte. Nach der Installation wollte Skyrim
erstmal nicht gleich starten.
Der Hintergrund der neuen Startprobleme scheint aber wieder einmal die
Divenhaftigkeit von Steam.
Upgrade auf Fedora 33 war nicht viel besser. Denn wenn man jetzt wine
notepad in die Konsole eingegeben hat, hagelte es Fehlermeldungen. Mit
Skyrim oder Steam ging erst recht nix.
Das war alles kurz vor der Fastenzeit, und weil das so war, dachte ich
ok, muss ich kein Skyrim spielen.
Man konnte in die Konsole wine notepad64 eingeben, und das
funktionierte.
Fedora selber ist 64 Bit und (mein) Skyrim LE ist ein 32 Bit Programm.
Wie gesagt, bis vor kurzem lief das alles noch ganz gut.
Wenn man jetzt in der User.reg von wine den Eintrag Arch=64 nach Arch=32
umwandelt, läuft fast wieder alles wie es sollte. Steam macht seine
Updates, der Skyrim Start- also die Umschaltung in den Spielebilschirm
ist ein wenig Lotteriespiel - aber machmal geht es...
(Den Start kann man nur einmal machen - wenn Steam/Wine dann nicht in
den Spielebildschirm schaltet, ist meist ein Neustart nötig)
Im Spiel selber tauchen die alten Probleme vom Anfang (der Installation)
wieder auf - in erster Line keine Stimmen (die Menschen sind stumm),
keine Musik - aber Effektsounds.
Wie komme ich jetzt mit der winecfg um die Ecke, die offenbar aufgrund
des fehlenden Rückhalts von "Arch64" im User.reg Eintrag nichts mehr
merken bzw. lesen will ?
So ganz grob weiß ich nicht wirklich, was hier los ist, denn die winecfg
"funktionierte" bis vor kurzem noch wie sie sollte.
Wine selber hat sich ein wenig verändert und "schaltet" gar nicht mehr
in einen extra Desktop.
Wenn man jetzt (Arch=32 in der User.reg) wine notepad eingibt, erscheint
der Editor direkt im Linux-Desktop.
Wenn man Skyrim unter diesen Bedingungen startet, dann erscheint statt
dem Windows Desktop ein kleines Icon im Linux-Desktop mit den
Steam-Menü.
Aber weil diese User.reg ja nicht mehr "koscher" ist, merkt sich das
System auch nichts mehr diesbezüglich bzw. fallen die Einträge in der
winecfg weg (??), so dass auch die Stimmen oder die Musik fehlen - und
auch die Anmeldung mit dem Passwort muss ich jedes Mal neu machen.
Neue Einträge in der winecfg sind sinnlos.
Das ziemlich lange, komplizierte Passwort bei der Steam-Konto-Anmeldung
weiß ich bald auswendig.
Hat jemand eine Idee, wie man einigermaßen sparsam aus diesem "Chaos"
herauskommt?
Wird mir aus deinem Text nicht ganz klar:
Lässt du das Windows-Steam über Wine laufen, oder lässt du das
Linux-Steam laufen, und verwendest für Skyrim die Wine-Implementation
von Valve, "Proton"?
Bei den Steam Sachen steht ziemlich eindeutig "Ubuntu LTS" als
Anforderung dabei.
Auf anderen Distributionen ist das dann übelste Handarbeit, die
entsprechenden Abhängigkeiten aufzulösen.
Ich würde einfach auf das neueste Ubuntu LTS wechslen.
Jim M. schrieb:> Auf anderen Distributionen ist das dann übelste Handarbeit, die> entsprechenden Abhängigkeiten aufzulösen.
Eigentlich nicht. Wenn das Steam erstmal läuft, bringt das ja eigentlich
alles an Abhängigkeiten selber mit, da gibt's keine großen Anforderungen
an das OS, und wenn ist oft schon alles vorgekaut als Paket verfügbar.
Bei Fedora: `sudo dnf install steam`.
Und wenn du ein Windows-Spiel über das Linux-Steam startest, installiert
Steam gleich eine Wine-Version dazu, oft auch extra für das Spiel
passend vorkonfiguriert. Das funktioniert überraschend gut, und ist
garkein Vergleich zu den Wine-Config-und-DLL-Frickeleien, die da früher
notwendig waren.
Der TE hat vermutlich aber garnicht das Linux-Steam am laufen, sondern
verwendet das Windows-Steam unter Wine. Hat man vor vielen vielen Jahren
(Jahrzehnten) mangels Alternative so gemacht.
Falls nicht die Linux-Version von Steam genutzt wird, würde ich das auch
zuerst versuchen, vielleicht klappt es dann direkt. Das wird unter
Fedora gut unterstützt (über RPM Fusion). Bei mir funktioniert Steam
jedenfalls auch mit Windows-Titeln out of the box, nutze das aber
zugegeben eher selten.
rbx schrieb:> Vor einiger Zeit kamen dann Aufrufe auf Fedora 33 upzugraden, die ich> aufgrund früherer Schwierigkeiten lieber ignoriert hatte.
Derartige Meldungen ich noch nie, aber ich versuche mein System auch up
to date zu halten. Prinzipiell ist der Release Cycle ja bekannt, mann
sollte also min. 1x pro Jahr ein Upgrade durchführen. Dass es zu
Problemen kommen kann, wenn man zu viele Releases überspringt wird ja
klar kommuniziert. Wenn das unerwünscht ist, passt sicher eine andere
Distribution mit Rolling Release besser. Kaputt gehen kann natürlich
auch hier etwas.
Das ganze fing an mit einer Skyrim CD. Auf der Stand nur drauf, dass ein
Konto zur Aktivierung des Spiels nötig ist. Nichts von dubiosen
Programminstallationen zusätzlich.
Also hatte ich die Skyrim LE CD in den CD-Schacht gelegt, und das Setup
mit Wine gestartet - bzw. das ging ja anders als sonst. Steam ging also
über den Wine-Desktop los, und von dort aus wird (nach überprüfung der
Daten) die Skyrim Installation und dann Skyrim gestartet. Am Anfang gab
es verschiedene Probleme, z.B. mit der Anmeldung, die hatte ich aber
direkt per Internet gemacht. Das ging auch.
Weiter ging es dann einfach mit dem, was auf Linux/Wine ging, mit Steam,
auch das Constuction Kit musste man ja über Steam suchen + installieren.
Allerdings gab es den ein oder anderen Holperer mit Steam.
Beim letzten Upgrade ging eine ganze Zeit das Construction Set nicht,
bzw. Steam sagte: Spiel wird gestartet, aber nichts passierte.
Allerdings kann man direkt von der Internetseite von Steam Skyrim-Mods
installieren, was ganz gut geht und mehr Beachtung verdient, da viele
dieser Mods Probleme verursachen und das ein Weg ist, ein Minimum an
Qualitätssicherung zu machen.
Also grundsätzlich ich hab erstmal nur das, was auf der Installations-CD
mit drauf war.
Und das lief ja auch alles bis vor kurzem noch ziemlich gut. Aber oft
hängt Steam dazwischen, z.B. wenn die Umschaltung in den
Spielebildschirm nicht kommt, dann ist das eher ein Steam-Ding. Verträgt
sich aktuell wohl nicht mit dem neuen Wine-Application-Starter.
Wenn ich jetzt nochmal (nach einem Fehlversuch) versuche, das Spiel zu
starten, gibt es einen Loop: Benutzer wird eingeloggt, Spiel wird
gestartet..aber das Spiel startet nicht, und es geht weiter mit Benutzer
wird eingeloggt..
Im Moment habe ich aber eher Schwierigkeiten wine bzw. dem Hin- und her
zwischen 64 Bit und 32 Bit.
Das das Zusammenspiel zwischen den "Application-Starter" und Steam noch
eine Gewisse Reife nötig hat, dürfte auch klar sein ;)
Dann probier doch wie gesagt die native Steam-Version. Da es die gibt
macht es wenig Sinn selber rumzubasteln, genauso würdest du ja unter
Windows auch nicht versuchen, die Linux-Variante zum Laufen zu bekommen,
wenn es einen Windows-Installer gibt.
Ich weiß jetzt nicht, welche Probleme du genau mit x86/x64 hast, aber
darum sollte sich auch Steam bzw der Paketmanager kümmern. Wie ja auch
andere bestätigen ist das mittlerweile recht problemfrei möglich.
Steam schrieb:> Ich weiß jetzt nicht, welche Probleme du genau mit x86/x64 hast,
Ich weiß das jetzt ehrlich gesagt auch nicht genau. Ich weiß aber, dass
man vor dem Upgrade noch wine notepad in die Konsole eingeben konnte,
und Notepad startete.
Nach dem System-Upgrade ging das nicht mehr. Was wohl geht, ist eine
64bit-Version von Notepad aufzurufen - aber das nützt wohl für Wine oder
Skyrim eher wenig.
Aus dem Application-Starter werde ich auch nicht so recht schlau.
Das sind zwei Felder, die haben aus meiner Sicht den Status: "broken"
Am hilfreichsten fand ich in dem ganzen Szenario (was frag ich
überhaupt??) die Seite der Fedora Docs:
https://docs.fedoraproject.org/en-US/quick-docs/wine/
So ganz unbekannt war das Problem nicht - aber es scheint noch immer
schwierig zu orten.
https://bugzilla.redhat.com/show_bug.cgi?id=1192725
Es taucht scheinbar öfters im Zusammenhang mit Updates und Dist-Upgrades
auf. Aber jedesmal auf ein Wine-Update warten zu müssen, kann auch keine
Lösung sein.
Wenn man den .wine ordner mit einem unbelasteten austauscht (also in
diesen Fall mit dem aus der Testing-Repo) dann funktionieren die
Konsoleprogramme wieder normal, also wine notepad, oder (noch viel
wichtiger) die (per Konsole aufgerufene) winecfg.
Startet man Skyrim von der Konsole aus unter diesen Bedingungen, bleibt
der Bildschirm nach dem Start komplett schwarz.
Dann hatte ich den neuen .wine-Ordner gelöscht, und den alten
wiederhergestellt. Bleibt der Bildschirm immer noch schwarz?
Von außen gesehen: so ein wenig wirkt die Szenerie, als wollte Steam aus
seinem Windows-Desktop-Gefängnis ausbrechen..
Grundsätzlich schalten die alten Wine-Programme in den Windows-Desktop
und brechen dann ab. Sämtliche Programme, die auf Wine angewiesen sind,
gehen nicht mehr.
Workaround: in der User.reg Arch=64 nach Arch=32 umbenennen.
Die Winecfg passt zwar nicht mehr, aber sie kann - zumindest für diese
Sitzung - die Eintragungen behalten.
Die Starts sind viel besser geworden, man kann mehrmals starten, und man
kommt nahezu immer in den Spielebildschirm. Kein Lotteriespiel mehr.
Weil die Eintragungen in der winecfg behalten werden, erklingt beim
Startbildschirm von Skyrim sogar Musik.
Jetzt aber geht die Maus nicht mehr (die ging sonst immer) und wenn man
ein Spiel startet, oder ein altes Spiel läd, bekommt man einen schwarzen
Bildschirm. Teilweise geht der noch, man kann z.B. Türen aufmachen. Aber
das Spiel legt autosaves an - und scheint scheint den Speicherort nicht
mehr zu finden - und bricht ab bzw. macht einen Crash to Desktop (CTD).
Vom Aspekt der schrittweisen Verbesserung kann man hier nicht meckern ;)
Allerdings wäre es ganz gut, Directx noch mal zu starten - aber dazu
braucht es ein funktionelles Wine-Programm.
Auch eine Neuinstallation von Skyrim wäre zu überdenken. Aber das
bräuchte eine funktionelle winecfg bzw. so ganz "koscher" erscheint mir
die Situation mit Wine (und dem Fedora-Upgrade) nicht - weswegen die
nähere Lösung ist, Fedora vom Rechner runterzuschmeißen, und durch
Windows 10 zu ersetzen.
Skyrim Mods habe ich mir nicht so viele Installiert und den
Skript-Extender brauche ich gar nicht. Die Spielesaves liegen recht
sicher in Dokumente/MyGames - also eigentlich wie bei den neueren
Windowsen.
Was wirklich weh tut, ist dass spürbar viele Arbeitsstunden in das
Wine-Programm hineingeflossen sind, dass das Spielszenario mit Wine
unter Linux einen wirklich guten und performanten Eindruck macht(e).
Alternative Lösungen sind da eher zweit- oder drittklassig.
Hinzu kommt, dass bei Fedora Virtualisierung und Co ziemlich groß
geschrieben werden..
Aber vom Aspekt der schrittweisen Verbesserung sehe ich da eher einen
(Ampelfarben) grünen Bereich.
rbx schrieb:> Was wirklich weh tut, ist dass spürbar viele Arbeitsstunden in das> Wine-Programm hineingeflossen sind, dass das Spielszenario mit Wine> unter Linux einen wirklich guten und performanten Eindruck macht(e).> Alternative Lösungen sind da eher zweit- oder drittklassig.
Was bedeutet alternative Lösungen? Der naheliegende Weg wäre die Version
des Programms (Steam) zu nutzen, die für dein OS gemacht ist. Aus irgend
einem Grund willst du das nicht und gehst lieber den komplizierten Weg.
Gründe dafür zu nennen würden vielleicht dafür sorgen, dass du hier mehr
Antworten bekommst ;-)
Wenn es wirklich der komplizierte Weg sein muss, kannst du dir über dnf
übrigens auch eine frühere Version von wine holen, was ich persönlich
vor Testing bevorzugen würde, gerade wenn "es vorher mal ging".
Steam schrieb:> Wenn es wirklich der komplizierte Weg sein muss, kannst du dir über dnf> übrigens auch eine frühere Version von wine holen, was ich persönlich> vor Testing bevorzugen würde, gerade wenn "es vorher mal ging".
Nun hat aber der Dist-Upgrade Wine zerschossen, und wie ich oben
geschrieben hatte, geht es durchaus schrittweise vorwärts.
Das hat nichts mit kompliziert zu tun, sondern eher mit abwarten und
undokumentiert - wenn hier überhaupt etwas kompliziert auftritt, dann
ist das Steam.
D.h. man hat eigentlich einen lustigen Dreierbund aus Dist-Upgrade,
Wine-Updates und Steam..
Ich würde mir aber mehr Linux-Freundlichkeit von Steam wünschen, das was
bei Steam unter Wine läuft, ist eher ein schlechter Witz.
rbx schrieb:> Ich würde mir aber mehr Linux-Freundlichkeit von Steam wünschen,
Valve bietet eine Linux-Version an. Das ist mehr als alle anderen
Spiele-Download-Plattformen machen. Sozusagen das absolute Maximum an
Linux-Freundlichkeit.
Und das machen die sicher nicht zum Geldverdienen (Schau dir mal die
Steam-Hardware&OS-Statistiken an).
Dieses Linux-Steam funktioniert auf Bergen von verschiedenen
Distributionen, von Ur-Alt bis Super-Frisch, das ist mehr als viele
Löhnware-Anbieter für ihre Linux-Software tun.
Damit geht Valve schon weit über "Linux-Freundlichkeit" hinaus.
Und wir sind noch nicht am Ende, Steam bietet mit Proton auch noch ihre
eigene Wine-Distro an, mit der man viele Windows-Spiele einfach unter
Linux starten kann, ganz transparent ohne Gefrickel.
Und das reicht dir noch nicht? Was soll Valve noch machen? Soll Gabe
Newell bei jedem Linux-Gamer persönlich vorbeischauen und ihm die Füße
küssen?
Ergänzung:
Das Umschreiben von "ARCH" nach 32 in der user.reg von Wine ist aber
noch nötig.
Die Starts laufen sehr gut, deutlich besser als vorher. Diese Neustarts
braucht man auch, weil die winecfg noch etwas zickig ist.
Damit ich im Spiel Musik und Stimmen höre, muss ich in der Bibliothek
"Neue Überschreibungen für" xaudio2_6 und xaudio2_7 (per Mausklick)
eintragen. Beide nötig.
Beim Starten (der winecfg) haut die winecfg einen Haufen Fehlermeldungen
raus, die eine andere Grafikkarte nahelegen..
Ja, wenn das denn ginge..
Wichtig ist aber, dass sie die eingetragenen "Überschreibungen"
memoriert. So ganz astrein läuft das noch nicht, manchmal kommt eine
Fehlermeldung zu einem Packet, und die Eintragungen gehen flöten. Man
muss also noch in der Konsole beobachten, dass nach den Eintragungen
keine Fehlermeldung kommt.
Falls doch, sind die Überschreibungen neu einzutragen.
Was man vorher auch schon machen musste:
1
#! /bin/sh
2
3
echo"Datum"
4
date
5
echo"Rechner"
6
hostname
7
8
echo"Voreinträge für x zum Spielen.."
9
10
xset -r
11
xinput disable 13
12
xinput disable 14
13
14
echo"Ok"
;)
Steam für Linux hatte ich mal testweise installiert, war aber Quatsch,
hatte nicht viel (mehr) gebracht.
und wieder geht nix. Was ist es diesmal?
Es gab Updates, Kernel, OpenMP, Xen.. ("Neustart erforderlich")
Neustart:
error: symbol 'grub_calloc' not found
error: symbol 'grub_calloc' not found
Press any key to continue
Eine hilfreich Bootrepair-Disk gibt es, aber die ist auf Ubuntu
zugeschnitten.
"Bitte eine Packetquelle aktivieren, die die Packete [grub2] in den
Packetquellen von Fedora33 (Workstation Edition)(mapper/fedora-root)
enthält. Versuchen sie es dann erneut."
Die hilfreiche Text+Repair-Disk von Fedora kann man im Moment wohl nicht
mehr von der Fedora Seite bekommen. Auf der Live-CD von Fedora 34 konnte
ich noch keine hilfreichen Software-Werkzeuge für diese Art von
Problemen entdecken..
Gewisse Merkwürdigkeiten kann man auf jeden Fall mal festhalten:
1) Es ist gar nicht so recht klar, was los ist - aber was noch viel
schlimmer ist: warum treibt sich dieser Unfug immer noch auf den
Repositories herum?
Letztes Jahr im Sommer waren viele Debian/Ubuntu-Systeme betroffen.
2) Zum Fixen ist auf jeden Fall eine Live-CD vorzuziehen. Die
Grub-Notkonsole kann (mit hoher Wahrscheinlichkeit) mitbetroffen sein.
Das Herumfuhrwerken in Bereichen, von denen man lieber die Finger lässt,
ist auch nicht besonders witzig.
Diese (Notfall-)Live-Cds müssten zusammen mit den Betriebsystem
ausgeliefert werden.
Bei Windows gab es früher immer eine Möglichkeit, sich eine
Rettungsdiskette zu erstellen.
3) Alternativlos?
Auch wieder Windows: Grafikkarten: Wenn es darum ging, neue Treiber zu
installieren, oder wenn es Ärger gab, dann konnte man immer bzw. sollte
man das sogar - in einen einfachen Treiber wechseln.
Wenn hier (bei Linux) der Bootloader solche Zicken macht, dann muss es
einen einfachen alternativen Bootloader geben, den man dann bei
Problemen oder Umstellungen einsetzen kann. Es würde auch nicht stören,
wenn solche Hilfsgeschichten ins Bios, oder in die Hardware wandern.
rbx schrieb:> Es ist gar nicht so recht klar, was los ist
und vor Allem: Warum das nur bei dir "los" ist.
Grub-Probleme wie von dir beschrieben hatte ich seit gefühlt 1990 nicht
mehr.
rbx schrieb:> Diese (Notfall-)Live-Cds müssten zusammen mit den Betriebsystem> ausgeliefert werden.
Bei ziemlich jeder aktuellen Distro lässt sich die
Installations-CD/Stick als Live-System booten. d.H.: Forderung seit
langem erfüllt.
rbx schrieb:> Bei Windows gab es früher immer eine Möglichkeit, sich eine> Rettungsdiskette zu erstellen.
Welche aber nie was gerettet hat, abgesehen von "fdisk /mbr"...
rbx schrieb:> oder wenn es Ärger gab, dann konnte man immer bzw. sollte> man das sogar - in einen einfachen Treiber wechseln.
geht, schau mal in dein Grub-Menu abseits des Auto-Starts.
rbx schrieb:> Wenn hier (bei Linux) der Bootloader solche Zicken macht, dann muss es> einen einfachen alternativen Bootloader geben, den man dann bei> Problemen oder Umstellungen einsetzen kann.
gibt es, lässt sich einfach parallel installieren. "rEFInd" wäre z.B.
eine Option.
https://fedoraproject.org/wiki/Refindhttps://www.rodsbooks.com/refind/rbx schrieb:> Es würde auch nicht stören,> wenn solche Hilfsgeschichten ins Bios, oder in die Hardware wandern.
Ist es längst. Wie antik ist bitte deine Hardware, wenn die noch kein
UEFI hat?
