Von Windows 11 auf Arch Linux - Kurzer Erfahrungsbericht

[Alexander2]

Ruckler in nem Spiel, das es unspielbar war zum Beispiel, ich kann dir jetzt nicht mehr sagen welcher kenel das in dem fall war. glaube lqx
Jedenfalls mit Standardkernel dann saubere frametimes und normal spielbar.

Letzt erst mitm lqx, wegen dem pcgh nochmal getestet, in rdr2 kamen nach gewisser Spielzeit nen Stillstand von ~10 Sekunden wirklich kein einziges neues Bild, und in den Hintergrund gewechselt ging noch, da lief fast alles, außer das keine App neu starten wollte, was lief, das lief jedoch.
Ich hatte das Tatsächlich ausgesessen, nach der Zeit eben lief das dann eben wieder und die 15 Terminals die ich starten wollte sind dann auch alle auf einmal aufgeploppt.

mit dem xen xanmod glaube lief es dann besser, so viel mehr fps komen aber auch nicht bei rum.

das letzte Problem ist in last epoch an einer stelle wo sehr viel los war scheint sich pipewire sozusagen in aufträgen für die usb soundkarte ertränkt zu haben, vermute ich, weil es nicht schnell genug abgearbeitet wurde was vom Spiel kam? der Ton war effektiv nurnoch unidentifizierbares krächzen, sowie die fps waren nurnoch bei 10 rum statt um die 100.
Dieses letzte Problem kann ich nicht 100% zuordnen, aktuell schiebe ich es dennoch hauptsächlich auf den Kernel. habe zurück zum standard gewexhselt, sowie pipewire auf pro audio umgestellt für geringere latenzen und ich habe mir auch nen upgrade vom 3900x auf 5800x3d gegönnt. → kein problem mehr.

Das upgrade bringt mir aber auch zum Beispiel in cosmoteer große vorteile das ist teils doch sehr cpu hungrig. und ich verspreche mir auch in cities skyline deutliche Vorteile.

für nur ein paar wenige fps mehr hier und da mir dann solche Probleme einhandeln -- da bin ich immer wieder ganz fix auf dem standardkernel, zudem andere auch sowieso ja parallel installiert werden, wenn ich die doch mal teste.
Ich kann mir auch nicht so sehr vorstellen, das mein Rechner/System so ein Mauerblümchen ist, das ich der Einzige bin, der solche Probleme bekommt. Vermutung ist teils daher, das daraus dann so sachen entstehen wie bä pulseaudio ist kacke, die haben noch immer nicht den Soundserver unter kontroller oder sowas.

 

[D.S.i.u.S.]

Es ist eine beschlossene Sache. Liquorix Kernel wird nicht installiert. Linux-zen + Linux Kernel(als Backup) ist ausreichend.
Ich habe zwei Spiele getestet. Der Unterschied ist nur ganz marginal.

	RDR2 FPS-Minimum​	Far Cry 6​ FPS-Minimum
6.7.10-lqx3-1-lqx Test 1​	44​	133​
6.7.10-lqx3-1-lqx Test 2​	72​	129​
6.7.10-lqx3-1-lqx Test 3​	74​	130​
Durchschnitt	63​	132​

	RDR2 FPS-Minimum​	Far Cry 6​ FPS-Minimum
6.8.1-zen Test 1​	34​	130​
6.8.1-zen Test 2​	79​	129​
6.8.1-zen Test 3​	75​	127​
Durchschnitt	63​	129​

 

[Evil E-Lex]

linux-zen ist ein offizieller Kernel.

Nein, das ist ein Fork. Offiziell ist, was du auf kernel.org herunterladen kannst.

 

[agon]

@Evil E-Lex Nach der Logik wäre linux dann auch kein offizieller Arch-Kernel.
https://wiki.archlinux.org/title/Kernel#Officially_supported_kernels

Ich sollte wohl zukünftig "offiziell unterstützt" schreiben.
Btw. "Community support on forum and bug reporting is available for officially supported kernels."

 

[Evil E-Lex]

@Evil E-Lex Nach der Logik wäre linux dann auch kein offizieller Arch-Kernel.

Ein offizielles Arch-Kernel-Paket sicherlich, ein offizieller Kernel aber nicht. Denn bei dem Paket handelt es sich, wie bei nahezu jeder Distribution, um einen Fork, der mit distributionsspezifischen Patches angereichert wird.

Ich sollte wohl zukünftig "offiziell unterstützt" schreiben.

"Vom Arch-Projekt offiziell unterstützt" wäre noch besser. 🙂 Alles andere suggeriert eine Nähe zum Vanilla-Kernel, die nicht gegeben ist.

 

[agon]

Ein offizielles Arch-Kernel-Paket sicherlich, ein offizieller Kernel aber nicht.

In welchem Thread sind wir hier noch mal? -> "Von Windows 11 auf Arch Linux - Kurzer Erfahrungsbericht"
Kontext beachten.

linux-zen ist ein offizieller Kernel – nämlich seitens Arch Linux. Dieser Kernel wird auch von Arch offiziell unterstützt.
linux-zen ist auch nur ein Arch Linux Kernel, siehe FAQ. Ich habe auch explizit linux-zen geschrieben.

Ich> linux-zen ist ein offizieller Kernel.
Nein, das ist ein Fork.

Dass alle geforkten Projekte, keine offiziellen Projekte sind, wusste ich tatsächlich noch nicht…

 

[D.S.i.u.S.]

Ich hatte neulich wieder ein Problem gehabt.
System-und-software-update Script gestartet, Passwort eingegeben, J und ENTER gedrückt. Es hatte den Anschein, dass alles aktualisiert wird und dann schließt sich die Konsole automatisch.

Am nächsten Tag ist mir aufgefallen, dass es dieselben Updates sind. Dann habe ich die Konsole geöffnet und versucht mit yay(paru) zu aktualisieren. Ging auch nicht. Dann habe ich versucht mit Pamac zu aktualisieren. Weil es mit Pamac zu lange gedauert hat, habe ich auf Abbrechen geklickt.
Konsole wieder geöffnet. Daraufhin kam die Meldung :: Pacman wird gerade ausgeführt, bitte warten…
zum Vorschein. Meine Vermutung ist, dass es der Abbruch in Pamac verursacht hat.
Manchmal bleibt das Sperrverzeichnis von Pacman bestehen und verhindert, dass Pacman ausgeführt wird. Wenn Pacman ausgeführt wird, erstellt es db.lck Datei, um sicherzustellen, dass nur ein einzelner Pacman-Prozess gleichzeitig auf die Datenbank zugreift.
Mit sudo rm /var/lib/pacman/db.lck habe ich diese Datei gelöscht. Über Konsole war Löschen nicht möglich. Zum Verzeichnis und dann diese Datei löschen.
Durch Löschen dieser Sperrdatei könnten neue Pacman-Operationen durchgeführt werden, da Pacman keine aktiven Sperren mehr feststellt.

yay Befehl in der Konsole ausgeführt und festgestellt, dass linux-lqx nicht heruntergeladen wird.
Die Aktualisierung mit Pacman hat eine Macke. Wenn ein Paket nicht heruntergeladen wurde, werden die anderen Pakete nicht aktualisiert.
Mit sudo pacman -Syu --ignore linux-lqx wurden endlich die anderen Pakete aktualisiert.

Ich werde linux-lqx Kernel entfernen, weil linux-zen genauso gut ist. Und außerdem werde ich bald Arch nochmal ohne archinstall und ohne Discover, Pamac und linux-lqx installieren.

 

[Alexander2]

Hast du deinen RAM auch mal mit nur JEDEC Werten getestet?

 

[Evil E-Lex]

Mit sudo rm /var/lib/pacman/db.lck habe ich diese Datei gelöscht. Über Konsole war Löschen nicht möglich.

Natürlich geht das. Im Zweifel rm -f benutzen.

yay Befehl in der Konsole ausgeführt und festgestellt, dass linux-lqx nicht heruntergeladen wird.

Wie der Screenshot zeigt, war der Server grade nicht, oder nur schlecht erreichbar. Kommt halt vor

Ich werde linux-lqx Kernel entfernen, weil linux-zen genauso gut ist. Und außerdem werde ich bald Arch nochmal ohne archinstall und ohne Discover, Pamac und linux-lqx installieren.

Beide obigen "Probleme" sind kein Grund das System neu zu installieren. Das sind schlicht alltägliche Dinge, die immer wieder auftreten können.

 

[Alexander2]

Also sein Problem, das Das Terminal "Konsole" mit bzw wegen dem update abschmiert dürfte doch eher selten vorkommen. Fehlermeldungen, irgendein Problem ja.. aber es kackt einfach ab und schließt sich ohne Meldungen... ich kann mich nicht daran erinnern, das das mal bei mir passiert wäre. Deswegen auch die Frage nach seinem RAM, wenn der instabil eingestellt ist ggf. wegen XMP/EXPO wäre das eine Erklärung.

Das folgende Problem, das die Installer nichts mehr machen wollten ist nur die Folge, das die db.lock wegen dem absturz nicht entfernt wurde. Soweit normal.

Ich meine es kann natürlich einfach Pech gewesen sein, mir ist jedoch das Updateprogramm und das Terminal noch nicht als instabil untergekommen.

 

[jenzen]

linux-lqx stammt auch aus einem "unofficial user repository". Daher, aber auch bei Arch generell, sollte man mit so kleineren Problemchen rechnen.
Das gehört zum allgemein minimal höheren administrativen Aufwand, den man mit Arch hat im Vergleich zu typischen "einsteigerfreundlicheren" Distris. Das ist auch so "by design" - bei Arch geht die Distri sozusagen davon aus, dass die User mit minimalen Problemen wie Paket-/Update-Problemen oder anderen Maintenance-Doings umgehen können. Arch ist zwar wesentlich stabiler als sein Ruf, aber ab und zu kommt es nun mal vor, dass man mal ein Paket wieder downgraden muss, oder ein Community-Paket nicht mehr up to date ist und somit nicht mehr kompatibel ist zum Rest des Systems, und so Sachen halt. Dass mal einer der eingestellten Repo-Mirror-Server langsam oder nicht verfügbar ist, passiert auch mal. Dann enabled man halt stattdessen einen anderen, oder wartet etwas. Das muss einem als User vorher klar sein. Aber wir reden hier trotzdem nur von wirklichen Peanuts, die jeder halbwegs erfahrene Linux-User wieder geradegerückt bekommt. Aber ein 100% Selbstläufer ist Arch nun mal nicht, will es auch gar nicht sein. Also bringt es auch IMHO wenig, darüber zu berichten. Bugs melden usw. ist gut, aber sowas wie "ein inoffizieller Mirror, den ich eingebunden habe, ist gerade zu langsam, deshalb geht mein ganzer Update-Vorgang nicht" ist dann doch nicht wirklich einen Post wert. Da hilft warten oder eine kurze Mail an den Maintainer des Repos eher weiter.

Und bei GUI-Frontends wie Discover ist es halt meistens so, dass im Vergleich zum CLI-Tool wofür sie ein Frontend sind, weniger Features vorhanden sind und weniger Fehlerinformationen angezeigt werden. Das haben GUI-Frontends grundsätzlich so an sich - sie werden gebaut weil sie die Bedienung kinderleicht machen, aber es werden fast nie alle Features des Original-Tools abgedeckt. Im Fehlerfall kann es daher immer mal vorkommen, dass man auf das Original-Tool zurückgreifen oder in Logs schauen muss, um das Problem zu troubleshooten, weil das Frontend irgendwas Wichtiges nicht anzeigt. Das gilt für alle OS, nicht nur für Linux. Sinnvoller machen es Frontends, wo man den direkten Output des Original-Tools sieht. Da kann man dann auch jeden Fehler direkt sehen. Aber das sieht halt nicht so schön aus, daher wird sowas gerne versteckt in der GUI.

 

[D.S.i.u.S.]

@Alexander2
Konsole schmiert nicht ab. Es ist so eingestellt, dass die Konsole nach dem Update sich schließen soll. Alles gut.

Liquorix Server sind seit drei Tagen nicht erreichbar bzw Kernel kann nicht von liquorix.net übertragen werden. Auch das ist kein Problem mehr, weil ich den Liquorix Kernel entfernt habe.

@Evil E-Lex
Grund für Neuinstallation:
Obwohl man Programme mit sudo pacman -Rns entfernt, hinterlassen Programme viele Ordner, Dateien, Dienste und irgendwelche Zeilen an verschiedenen Stellen. Aber es kann auch sein, dass ich nicht mit sudo pacman -Rns entfernt habe. Weiß ich nicht mehr so genau.

Ich habe seit Arch Installation viele Programme getestet. Es sind viele Reste davon übergeblieben. Besonders schlimm war es mit Evolution. Seitdem ich es entfernt habe, sehe immer wieder irgendwelche Ordner oder Dienste mit "Evolution" im Namen.

Es ist ähnlich wie mit Bloatware. Keiner will es haben.

Muss mich noch informieren, warum einige AURs Ordner im Home-Verzeichnis erstellen und ob diese unbedingt erforderlich sind. Sind das alles Konfigurations- und Cache-Ordner oder werden die nur für Build-Prozess erstellt?
Momentan sind Auracle-git, jargonaut, nvidia-all und paru in Home-Verzeichniss. Es waren schon mehr gewesen.
Jargonaut wollte ich nur kurz testen, aber nicht geschafft es zu installieren. Ist eigentlich von Linux Mint.
Auracle-git Ordner habe ich, weil es Probleme mit Aktualisieren von auracle-git hatte.
In Nvidia-all Ordner ist ver. 550.67 und anderes Zeug drin.

 

[Evil E-Lex]

Also sein Problem, das Das Terminal "Konsole" mit bzw wegen dem update abschmiert dürfte doch eher selten vorkommen.

Das habe ich so nirgends herausgelesen. Nach meinem Verständnis hat er erst ein Update-Script genutzt, das schließt das Terminalfenster nach Beendigung automatisch. Soweit normal. Danach hat er in der Konsole yay bzw. paru genutzt "was auch nicht ging", was immer das bedeuten mag. Danach dann pamac, was ihm dann zu lange gedauert hat und er deshalb das Fenster geschlossen hat. Dabei laufen natürlich noch Hintergrundprozesse weiter und es wird ein Lockfile erzeugt. Das ist alles völlig normal.

Das eigentlich Problem besteht darin, dass er verkennt, dass alle genannten Tools nur Frontends für pacman sind und daher immer das gleiche Programm, nämlich pacman, aufrufen. Statt mehrfach hintereinander mit verschiedenen Frontends die gleiche Aktion durchzuführen, wäre es zielführend gewesen, direkt die Logdateien zu lesen und zu schauen, wo das eigentliche Problem liegt. So hat die ganze Angelegenheit etwas von "Die Definition von Wahnsinn ist, immer wieder das Gleiche zu tun und andere Ergebnisse zu erwarten."

Ergänzung (6. April 2024)

Es ist ähnlich wie mit Bloatware. Keiner will es haben.

Im Gegensatz zu Bloatware sind das aber maximal ein paar Verzeichnisse mit Configfiles. Nichts davon ist aktiv und läuft noch auf dem System. Dateigröße von allen Überbleibseln vielleicht einige dutzend MB. Immer noch kein Grund ein System deswegen neu zu installieren.

Zunächst würde es helfen, sich von dem Strauß AUR-Helpern zu verabschieden und sich für einen zu entscheiden. So pflegen die unter Umständen alle ihr eigenes Cache- und Build-Verzeichnis.

 

[D.S.i.u.S.]

@Evil E-Lex
Mir war bewusst, dass Pamac pacman nutzt. Ich wollte nur sehen was Pamac in so einem Fall macht. Es versucht nämlich bis in alle Ewigkeit Liquorix Kernel von liquorix.net zu übertragen. Es gibt keine Fehlermeldung.

Ich muss zugeben, dass ich die Fehlermeldung mit Liquorix in der Konsole ignoriert habe. Ich hatte zu diesem Zeitpunkt schon Linux-Zen Kernel aktiv gehabt und mir war egal, dass Liquorix Kernel nicht heruntergeladen wurde.
Für mich erschien die Tatsache, dass andere Pakete nicht aktualisiert werden, wenn ein Paket nicht herunterladen wurde als interessant. Ich habe nach Einstellungen gesucht um es zu ändern.

Ich hatte mal am Anfang yay und paru gehabt. Seit 2024 aber nur paru.
Was meinst du mit "sich von dem Strauß AUR-Helpern zu verabschieden"?

Vielleicht sollte ich in paru.conf BUILD_DIR überprüfen.

 

[Evil E-Lex]

Ich hatte mal am Anfang yay und paru gehabt. Seit 2024 aber nur paru.
Was meinst du mit "sich von dem Strauß AUR-Helpern zu verabschieden"?

Du widersprichst dir. In deinem Screenshot oben sieht man ganz klar, dass du yay aufrufst. Und ich meine eben das. Du springst lustig zwischen yay, paru und offensichtlich auch noch auracle hin und her. Was soll das bringen?

Und wenn dir bewusst ist, dass pamac pacman aufruft. Was soll das bringen? Da kann naturgemäß kein anderes Ergebnis bei rumkommen.

Ich empfehle dir: Weniger sprunghaft sein. Mehr Dokumentation lesen und verstehen. Logs lesen und verstehen. Fehlermeldungen verstehen und einordnen lernen.

 

[D.S.i.u.S.]

Auracle-git und Paru sind zwei verschiedene Werkzeuge mit unterschiedlichen Funktionen, obwohl sie beide mit dem Arch User Repository (AUR) arbeiten.

Auf Seite 1 steht:

Aufrufen von Pamac war "for science"

 

[D.S.i.u.S.]

Wieder etwas Neues über die Funktionsweise von Arch Linux gelernt.

9. Pacman – Paketcache automatisch bereinigen
Da der Pacman Cache kontinuierlich anwächst, sollte man entweder manuell eingreifen und den Cache regelmäßig bereinigen oder systemd-Timer und -Service einrichten, um ein unkontrolliertes Wachstum zu verhindern.

pacman-contrib installieren.
Systemd-Service erstellen: sudo nano /etc/systemd/system/paccache-clean.service
Inhalt der Datei:

[Unit]
Description=Clean pacman package cache

[Service]
Type=oneshot
ExecStart=/usr/bin/paccache -ruk0
ExecStart=/usr/bin/paccache -vrk2

paccache -vrk2 # Entfernt Pakete aus dem Cache, behält die jüngsten 2 Versionen
paccache -ruk0 # Alle Pakete aus dem Cache entfernen, die nicht (mehr) installiert sind

Systemd-Timer erstellen: sudo nano /etc/systemd/system/paccache-clean.timer
Inhalt der Datei:

[Unit]
Description=Run paccache-clean.service weekly

[Timer]
OnCalendar=weekly
Persistent=true

[Install]
WantedBy=timers.target

Den Timer und den Service aktivieren:
Aktivieren: sudo systemctl enable paccache-clean.timer
Starten: sudo systemctl start paccache-clean.timer
Status überprüfen: sudo systemctl status paccache-clean.timer

 

[jenzen]

Jep, wenn man den Paketcache nicht manuell oder automatisiert durch so etwas in der Art leert, wächst er stetig an, er bereinigt sich nicht automatisch. Das ist auch ein Mitgrund dafür, dass Arch nicht ganz in die Einsteiger-Klasse der Linux-Distris fällt. Arch geht davon aus, dass die User sich sowas entweder selbst beibringen (Wiki) oder schon vorher wissen.
https://wiki.archlinux.org/title/System_maintenance

Noch besser als ein zeitgesteuertes Löschen ist IMHO ein pacman-Hook (Script, welches direkt nach jeder pacman-Operation läuft), z.B. https://bbs.archlinux.org/viewtopic.php?pid=1694743#p1694743
Solche Scripts können in /etc/pacman.d/hooks/ angelegt werden.

 

[Donnerkind]

Ich habe ein Wrapperscript, das das am Ende auf Nachfrage tut. Das Skript synct erst die Datenbank (pacman -Sy), fragt dann, ob ich die Updates haben will und wenn nicht, dann stellt es die alte Datenbank wieder her. Gründe für eine Ablehnung meinerseits sind, falls ich die verfügbaren Updates uninteressant finde oder gerade nicht gebrauchen kann. Z.B. ein neuer Kernel, nach dessen Update ich rebooten muss, weil dann keine USB-Speichergeräte mehr funktionieren. Oft habe ich aber gerade einen Haufen Arbeitsdateien in einer Ramdisk liegen.

 

[D.S.i.u.S.]

Ich habe die .desktop-Datei etwas modifiziert.
Datei erstellen: nano ~/.local/share/applications/update.desktop
In Eigenschaften für update.desktop "Öffnen mit: Konsole."
Inhalt der Datei:

[Desktop Entry]
Name=System Update and Cache Clean
Comment=Run Paru for system update and paccache for cache cleaning
Exec=/usr/bin/paru && /usr/bin/paccache -ruk0 && /usr/bin/paccache -vrk2
Icon=system-software-update
Terminal=true
Type=Application
Categories=System;

Am 08.04.24 Ausführung des Befehls aktualisiert. paccache -ruk0 und paccache -vrk2 sind dazu gekommen.
paccache -vrk2 # Entfernt Pakete aus dem Cache, behält die jüngsten 2 Versionen
paccache -ruk0 # Alle Pakete aus dem Cache entfernen, die nicht (mehr) installiert sind
Das Paket "pacman-contrib" muss installiert sein.
Den Pfad zu jedem Befehl habe ich spezifiziert. Möglicherweise geht auch ohne Pfad.
Ich habe zum Testen Firefox installiert und wieder deinstalliert. paccache -ruk0 hat funktioniert.

Für .cache/paru habe ich ein Eintrag in fstab erstellt:
tmpfs /home/username/.cache/paru tmpfs uid=1000,gid=1000,mode=750 0 0
Dies bedeutet, dass der Inhalt des Verzeichnisses /home/username/.cache/paru im Arbeitsspeicher des Computers gespeichert wird, anstatt auf SSD und dass die im RAM gespeicherten Daten beim Herunterfahren des Systems verloren gehen.
Nach dem Neustart des PCs war .cache/paru leer.