Zufrieden mit dem glatten Verlauf des ersten Teils der Installation ging es gleich weiter. Hier sollte ich aber dann das erste mal so richtig ausgebremst werden. Es bedurfte einiger Installationen, bis ich Irrwege und Probleme mit Treiber und Paketen erkannte. Clonezilla und einige Images meines neuen Systems waren mir hier gute Helfer.

Das System steht; es gibt einen User; Sudo läuft … weiter gehts.

Zeit einige Dienste nach zu installieren

(cronie ist vermutlich schon bei der „base“-installation mit dabei)
Und die Dienste aktivieren

Um den Rechner auch immer auf dem aktuellen Datum zu halten, installiere ich noch den ntp-Dienst dazu

Anpassen der /etc/ntp.conf

Den Inhalt anpassen

den Dienst aktivieren

Und eine Zeitkorrektur vornehmen (lassen)

Hier dann gleich der zweite Stolperstein.
Arch war bei mir jetzt eine Stunde voraus (die Uhr im Bios hatte die gewünschte, „richtige“ Zeit.
Die ersten Suchtreffer im www zeigten zwar, dass dieses Problem mehrere Leute haben, aber auch hier waren die ersten gefundenen Antworten eher die Richtung, dass man die Uhrzeit im BIOS auf UTC zu stellen hätte und lieber in der Registry das Windowssystem auf UTC anpassen sollte (inkl. gepostete Registry-Einträge – immerhin).
Ausserdem wäre UTC sowie die einzig richtige Zeit und man sei selber Schuld, wenn man M$-Produkte verwendet usw usw.
Ist es in heutigen Zeit zuviel verlangt in einem Forum klare Aussagen zu einem Problem zu bekommen, ohne daß man sich Hasspredigen oder Moralfragen, meist entstanden aus Ignoranz und tiefer Subjektivität, anhören muss?
Echt jetzt …
Auch wenn ich mich im Linux relativ sicher bewege und Systeme warten kann, gibt es noch genug Situationen die eingefleischte Linux-User nur ein müdes Lächeln abringen, mich aber doch noch vor die eine oder andere Herausforderung stellen.
Hier z.B.: war mir der Befehl „timedatectl“ bis dato noch völlig unbekannt, aber nach einer längeren Internetrecherche war dieser Befehl nun doch der Schlüssel zum Erfolg.
Auslesen der aktuellen Einstellung

Ergab, dass die rtc nicht auf local gestellt ist.

„Mangel“ beheben mit:

Ergebnis

Läuft …
Weiter geht’s.

Für mich als tippfaulen User habe ich dann noch die bash-completion installiert

Und war freudig überrascht, dass die notwendige Zeile in der /etc/bash.bashrc bereits automatisch angefügt und aktiv war.

Nach einem erneuten ab- und anmelden war die bash-completion auch aktiv und ich war glücklich … erst mal … Aber dazu später.

Der nächste Schritt war die Installation einer grafischen Oberfläche; der Gnome 3 sollte es sein.
Was einfach klingt, wurde dann aber doch etwas „kriminell“ und ich musste öfter mein Backup zurück spielen.
Der langen Rede kurzer Sinn:
Ich weiß, dass ich für meine Grafikkarte den „nvidia 340xx“-Treiber benötige und dieser auch funktioniert, dennoch war es mir bei der Installation nicht ein einziges mal möglich diesen Treiber bereits bei der Installation vom xorgserver funktionstüchtig zu integrieren.
Verantwortlich ist hierfür mit Sicherheit auch mein Halbwissen.
Der Hinweis, dass man mit

alle verfügbaren Treiber einbinden kann und der Richtige würde sich dann das System schon selber heraussuchen, schien jedoch mein System nicht zu wissen oder es machte sich einen Spaß daraus auch hier den falschen Treiber zu nehmen. Ein Start hiermit war jedenfalls bei keiner meiner Installationen erfolgreich.
Naja gut…
Für die Installation auf meinem Vostro 1310:

Auswahl (mesa-libgl)
Als Grafiktreiber konnte ich hier nur den Treiber

verwenden.
(Alternativ wäre hier, wie oben erwähnt, der Befehl: „sudo pacman –S xorg-drivers“, welcher bei mir nicht funktionierte)

Um auch im Xorg das deutsche Tastatur-Layout zu bekommen muss noch die Datei
/etc/X11/xorg.conf.d/20-keyboard.conf mit folgendem Inhalt erstellt werden.

Wobei ich diesen Schritt auch schon übersprungen habe und nach der Tastatur- und Regions-Einstellung im Gnome gleichen Erfolg hatte.

Installation von Gnome3

Danach die .xinitrc kopieren und anpassen

Hier dann die Zeile mit „exec gnome-session“ aktivieren (aushashen).
Jetzt kann mit startx schon mal der Gnome-Desktop gestartet werden.
Grund zur Freude: das klappte.

Vom Gnome wieder abmelden um den GnomeDisplayManager (gdm) zu installieren und aktivieren.

Da mir die ständige DHCP-Netzwerkadresse-Abruferei hier schon langsam auf den Kecks ging, habe ich gleich noch den Networkmanager samt Applet hinterher installiert, …

… aktiviert …

… und die GUI installiert.

Nach dem Neustart des Rechners kam die Gnome Anmeldeseite und ich konnte mich am Gnome-Desktop anmelden/einloggen. Dank dem Networkmanager wurde das Netzwerk auch schon automatisch erkannt.
Wie ich oben schon beschrieben hatte, benötigt meine Grafikkarte den nvidia-340xx Treiber.
Den konnte ich auch bei jeder meiner Versuchsinstallationen ab diesen Punkt ohne Probleme nachinstallieren.

Die Treiber wurden sauber ausgetauscht und das System konnte ich ohne Probleme neustarten.
Zumindest fast immer …
Einmal habe an dieser Stelle den LTS-Kernel installiert und hatte dann erstmal wieder einen schwarzen Bildschirm.
Na ok – es war eher ein Terminal mit 3 Zeilen weißen Text an oberen Rand, aber eben keine grafische Anmeldung mehr.
Liegt daran, dass es den nvidia-340xx auch als lts-Version gibt.
Wenn man also den lts-Kernel installiert, sollte man immer darauf achten, ob es bei den Paketen die man installieren möchte, auch eine xxx-lts-Version gibt.
Merke: Wenn ja, dann diese verwenden.

Wer den LTS-Kernel verwenden möchte; das geht mit:

Ändern der Grub-Bootkonfig

Erzeugen des Linux-Systems

Und bei meinem Gerät dann halt auch die Installation des LTS-Nvidia-Treibers …

Nach dieser etwas längeren Try-and-Error-Phase, war es dann doch endlich geschafft: das Grundsystem läuft.
Eigentlich sollte es jetzt ja entspannter weiter gehen … Ob es das tat, seht Ihr im Teil 3