Das ist auch eigentlich richtig so. Alle nicht-echten Geräte übernimmt das Paket "devicemapper". Und dieses sollte die Geräte eigentlich alle in "/dev/mapper" erstellen. Wo hast du das mit "/dev/<VG>"
Versuch mal weiterhin "relatime" zu benutzen und zusätzlich "lazytime". Das ist relativ neu und schreibt die Zeitstempel erst, wenn die Inode sowieso neu geschrieben werden müsste oder eine gewisse Zeit vergangen ist. Damit hast du den Vorteil einer Access-Time ohne den Performanceverlust zu haben.
Mit "discard" hatte ich in der Vergangenheit unter hoher Last Performanceprobleme. Aktiviere lieber den "fstrim.timer" mit "systemctl enable --now fstrim.timer" und entferne "discard". Wenn du LUKS benutzt, musst du TRIM auch für LUKS aktivieren. Das ist standardmäßig deaktiviert.
Ich werde einfach sowohl die englische als auch deutsche (die manchmal ausführlicher erläutert) Anleitungen anschauen.
Bei Allem, was im deutschen Wiki steht, bitte nochmal im englischen nachschlagen. Das Deutsche ist in vieler Hinsicht nicht aktuell.
In /boot/loader/entries/entry.conf auch "initrd /intel-ucode.img" eingetragen, was evtl. wegen CPU-Sicherheitslücken helfen kann.
Aufpassen, dass das der aller erste "initrd"-Eintrag ist. Die werden in der Reihenfolge geladen wie sie in der Konfiguration stehen und der Microcode lässt sich nicht mehr laden, wenn die initramfs bereits geladen wurde.
Für was braucht man eigentlich den oft in Anleitungen erwähnten wpa supplicant? Am Anfang der Installation einfach mit wifi-menu WLAN eingerichtet und keinen wpa supplicant mitinstalliert. Nach dem Booten ist WLAN trotzdem vorhanden.
"wpa_supplicant" ist unter Linux der Standard-WiFi-Adapter. Da er aber maximal beschissen zu bedienen ist, gibt es inzwischen mehrere Wrapper um "wpa_supplicant". Einer von denen ist Arch eigenentwickeltes "netctl", welches du mit "wifi-menu" benutzt. Schau dir das
Paket mal an. Als optionale Abhängigkeit benötigt es "wpa_supplicant". Der Text daneben erklärt auch wofür.
Wegen Repos und Paketierung muss ich mich noch genauer einlesen. Hier mal gelesen:
7 Essential Things To Do After Installing Arch Linux | Its FOSS
Bitte so einen Scheiß nicht befolgen. Arch läuft OOTB perfekt. Wenn du merkst, dass dir etwas fehlt, installiere es nach.
Also für die offiziellen Repos nutzt man pacman und für AUR dann yaourt? Nur bei AUR muss man immer die PKGBUILD prüfen, um auf der sichereren Seite zu sein und die offiziellen Repos sind automatisch clean?
Erstmal: FINGER WEG VON YAOURT! Das Teil ist absolut miserabel und ich frage mich bis heute wie das so viel Aufmerksamkeit bekommen konnte.
Alle Arch-Pakete werden aus einer sogenannten PKGBUILDs gebaut. Das ist eine Datei, die von dem Programm "makepkg", welches mit "pacman" daherkommt, gelesen wird und beschreibt wie ein Paket gebaut wird. Beispielsweise steht da drin, dass "make" und "make install" ausgeführt werden muss, irgendwelche Syminks angelegt werden müssen etc. Am Ende kommt dann ein "pacman"-Paket bei rum, welches mit "pacman -U <Datei>" installiert werden kann. Die offiziellen Pakete sind vorgebaut und müssen nur noch installiert werden. Die AUR-Pakete sind das nicht. Wenn du dir ein AUR-Paket runterlädst, musst du es mit "makepkg" selber bauen, wobei du idealerweise im Verzeichnis der PKGBUILD "makepkg -sric" ausführt, wobei...
-s = Fehlende Abhängigkeiten installieren
-r = Nach der Installation nicht mehr benötigte Buildtime-Abhängigkeiten wieder deinstallieren
-i = Paket nach dem Bauen direkt installieren (ansonsten müsstest du auf die durch "makepkg" erstellte Paketdatei manuell ein "pacman -U" ausführen)
-c = Nach dem Bauen das Verzeichnis säubern
AUR-Helper neigen von Natur aus dazu gern mal Fehler zu verursachen. Deswegen versuche es für den Anfang erstmal ohne AUR-Helper, damit zu zumindest verstehst wie das Bauen funktioniert. Der Standardprozess für das Bauen eines AUR-Paketes ist:
Code:
git clone https://aur.archlinux.org/google-chrome.git
cd google-chrome
makepkg -sric
Wenn du ein AUR-Paket updaten willst, einfach in dem Git-Repository:
Um AUR-Pakete auf Updates zu überprüfen, kannst du
auracle benutzen. "auracle sync" listet dir alle Pakete auf, für die im AUR eine neuere Version vorliegt. Wenn du versuchst "auracle" zu installieren, wirst du merken, dass er eine Abhängigkeit namens "nlohmann-json" nicht findet. Dieses Paket ist ebenfalls ein AUR-Paket, heißt das Paket muss vor "auracle" installiert werden. Hier kommt dann der Unterschied zwischen explizit (ICH habe es installiert) und implizit (nur installiert, weil ein anderes Paket es braucht) installierten Paketen ins Spiel. Du brauchst nur "auracle". "auracle" braucht "nlohmann-json", ja, aber DU brauchst nur "auracle". Deswegen solltest du "nlohmann-json" als Abhängigkeit installieren, was mit "makepkg -sric --asdeps" funktioniert.
Wo liegt der Unterschied zwischen den beiden Installationen? Explizit installierte Pakete (einsehbar mit "pacman -Qe") werden von "pacman" festgehalten. "pacman" weiß, dass du dieses Paket willst, also wird es das Paket niemals automaisch entfernen. Implizit installierte Pakete werden jedoch automatisch entfernt, wenn kein Paket mehr dieses Paket braucht. Deinstallierst du also "auracle", so wird "nlohmann-json" auch direkt deinstalliert. Um dir ein absolutes Abhängigkeitschaos zu ersparen, solltest du Pakete, du du nicht selber unbedingt brauchst, auch implizit installieren.
"pulseaudio" hat da ein sehr gutes Beispiel. Wenn du "pulseaudio" installierst, wird "pacman" automatisch einen Haufen an anderer Pakete installieren, die "pulseaudio" braucht, um zu funktioneren. Diese Pakete werden implizit installiert, also entfernt, wenn du "pulseaudio" wieder entfernst, denn kein Paket braucht sie mehr. "pulseaudio" selbst ist explizit installiert. Es wird nicht deinstalliert, nur weil kein anderes Paket mehr explizit sagt: "Ich brauche das aber!". Nun bietet "pulseaudio" allerdings ein optionales Paket namens "pulseaudio-alsa" an. Das ist dafür gedacht, dass wenn ein Programm kein PulseAudio unterstützt und versucht das klassische ALSA anzusteuern, dass es zu PulseAudio weitergeleitet wird. Ein Top-Kandidat für eine manuelle Installation eines impliziten Paketes! Wenn du "pulseaudio" deinstallierst, dann brauchst du "pulseaudio-alsa" nicht mehr. Im Gegenteil, es leitet dir sogar deinen Sound an ein Programm weiter, welches nicht existiert. Du wirst verzweifeln bis du herausgefunden hast wieso ALSA nicht mehr funktioniert. Wenn du "pulseaudio-alsa" einfach via "pacman -S pulseaudio-alsa" installierst, ist es explizit installiert. Deswegen installierst du es mit "pacman -S --asdeps pulseaudio-alsa". Deinstallierst du nun "pulseaudio", verschwindet "pulseaudio-alsa" auch direkt. Zumindest fast.
Ich hab bisher noch nicht herausgefunden wieso, aber "pacman" scheint sich zu merken, dass du ein Paket manuell als implizit markiert hast. Wenn du "pulseaudio" deinstallierst, bleibt "pulseaudio-alsa" installiert. Es taucht aber in der Liste der Pakete auf, die nicht mehr benötigt werden, die du mit "pacman -Qtd" einsehen kannst, wobei...
-Q = Lokale Paketdatenbank abfragen (im Gegensatz dazu steht -S für die entferne Datenbank, also die offiziellen Repos)
-t = Alle Pakete listen, die nicht von einem anderen Paket gebraucht werden
-d = Ergebnisse auf Abhängigkeiten, also implizite Pakete, beschränken. Ansonsten würde er dir auch alle impliziten Pakete anzeigen, die kein anderes Paket braucht. Und das willst du ja nicht, weil DU die ja brauchst.
Ab und zu also mal in "pacman -Qtd" reingucken kann also nicht schaden.
Auch nachträglich lässt sich noch ändern was explizit und was implizit installiert wurde. Wenn du beispielsweise jetzt "pulseaudio-alsa" schon installiert hast, ohne "--asdeps" zu benutzen, dann kannst du es nachträglich mit...
Code:
pacman -D --asdeps pulseaudio-alsa
...als implizit markieren, wobei "-D" für "modiziziere die lokale Datenbank" steht. Genauso wirst du vielleicht auch mal etwas nachträglich als explizit markieren wollen. Wenn du z.B. "tlp" installiert hast und irgendwann wieder deinstallierst, wirst du merken, dass auch "hdparm" deinstalliert wird. "tlp" hat "hdparm" als Abhängigkeit installiert. Wenn du dir aber jetzt denkst: "Hmm, okay, also eigentlich will ich ja nicht, dass "hdparm" wieder deinstalliert wird, wenn ich "tlp" deinstalliere, weil ich das ja (inzwischen) selber brauche, weil ich XY mache", dann kannst du einfach...
Code:
pacman -D --asexplicit hdparm
...ausführen. Dann ist "hdparm" als explizit installiert und du kannst "tlp" deinstallieren, ohne dass "hdparm" auch deinstalliert wird.
Außerdem: NIEMALS einfach "pacman -R" ausführen. Das deinstalliert das angegebene Paket ohne zu prüfen, ob es noch in irgendeiner Weise gebraucht wird. Das kann dir das System zerschießen. Am Sichersten ist ein "pacman -Rsc", wobei...
-s = Entferne auch alle impliziten Pakete, die jetzt nicht mehr gebraucht werden
-c = Entferne auch alle Pakete, die das Paket, was du da installierst, brauchen
"-c" ist vielleicht nicht das was du willst, weil es dir dann das halbe System deinstalliert, wenn du "pacman -Rsc glibc" ausführst. Deswegen kannst du alternativ auch "pacman -Rsu" benutzen (u = Nur nicht benötigte Pakete). Das weigert sich etwas zu deinstallieren, wenn etwas Anderes das Paket braucht. Das kann aber auch nervig sein, wenn du dein komplettes GUI deinstallieren willst und einfach "pacman -Rsu xorg-server" ausführst. Weil dann heult er rum, dass deine ganzen GUI-Pakete das brauchen. Da hilft dann ein "pacman -Rsc xorg-server", denn das deinstalliert diese ganzen GUI-Pakete dann direkt mit, was du ja wahrscheinlich willst.
Und wenn du KDE Plasma installieren willst und eh das volle Programm haben willst, bevorzuge das Paket "plasma-meta" statt die Gruppe "plasma". Das Meta-Paket ist selber komplett leer, zieht aber ganz KDE Plasma als Abhängigkeit rein. Das ist in der Hinsicht nützlich, dass neue Plasma-Pakete dann automatisch installiert werden und veraltete Pakete, die "plasma-meta" nicht mehr braucht, in "pacman -Qtd" auftauchen. Bei der Gruppe hast du das nicht. Da werden alle Pakete der Gruppe ganz einfach als explizit installiert, dein "pacman -Qe" wächst beachtlich und zugleich darfst du selber prüfen, ob etwas in der Gruppe "plasma" dazugekommen ist oder entfernt wurde. Nachteil eines Meta-Pakets ist jedoch, dass du eine einzelne Komponente der Gruppe dann nicht einfach deinstallieren kannst, weil es dann heißt: "Nene, du kannst "plasma-workspace-wallpapers" nicht deinstallieren, "plasma-meta" braucht das!" Du bist also weniger flexibel.
Pflege dein "pacman -Qe"!!! Was als Abhängigkeit installiert wurde interessiert dich absolut null! Wichtig ist nur "pacman -Qe" und das, was "pacman -Qtd" so ausspuckt.
- - - Updated - - -
Dieser Moment, wenn du realisierst, dass du lieber schlafen gehen solltest, stattdessen aber viel zu viel Text schreibst.
tl;dr: KEIN YAOURT, installiere nicht alles als explizit, lass die Finger vom deutschen Arch-Wiki oder kontrolliere das, was da steht, zumindest.
Ja FOSS würde ich so gut wie nicht befolgen und die Priorität eher auf engl. archwiki>deutsch setzen.
Nutzt ihr Add-Ons, um ähnliches zu korrigieren? Habe Dark Reader gefunden.
