Sonntag, 23. Juli 2017

Openmediavault on RaspberryPi3: I have fixed the problem of error message which reported /etc/cron.daily/logrotate: error: log /var/log/alternatives.log last rotated in the future --rotation forced

Durch ein Kommentar von Piere Wöhl auf meinen Blogeintrag "Openmediavault on RaspberryPi3 - Part 2" versuchte ich das Problem der täglichen Fehlermeldung des Systems, welche ich per Email erhielt, auf den Zeitfaktor einzugrenzen.

Zunächst erkundete ich einmal logrotate und dessen genaue Aufgabe.
In den tiefen des Internets bin ich auf einen uralten Artikel (aus 2004) gestoßen, aus dem ich entnehmen konnte, das sich logrotate an der "local.time" orientiert.

Ich erinnerte mich, dass ich beim Aufsetzen des Systems von Openmediavault im Menü "Datum & Zeit" die Einstellung des Abgleiches über einen ntp-Server (Network-Time-Protocol) gewählt habe. Wählte ich mich per ssh in die Konsole des Systems ein, wurde mit dem Befehl "date" auch die korrekte Zeit angezeigt.

Als Versuch änderte ich die Einstellung auf manuelle Zeiteingabe. Danach startete ich das System neu und wartete die ersten 24 Stunden ab.

Dies ist nun drei Tage her. Seither gab es keine Fehlermeldung diesbezüglich mehr.

Ob es mit dem ntp-Server, oder an sich mit der Einstellung die Zeit über einen Server abzugleichen anstatt einer manuellen Eingabe, zu tun hatte weiß ich nicht. Auch nicht, ob hier vielleicht generell ein Bug vorliegt.
Fakt ist, dass das System nun keine Fehlermeldung mehr aussendet und scheinbar fehlerfrei läuft.

Roman.

Mittwoch, 19. Juli 2017

NAS (Network-Attached-Storage) with Openmediavault on RaspberryPi 3 - (Part 2)

Im zweiten Teil geht es nun an die Einrichtung von Openmediavault.

Zu Beginn wurde das Adminpasswort im Menüpunkt "Allgemeine Einstellungen" geändert.


Hier könnte man auch noch den Port ändern und die Verbindung mithilfe eines Zertifikates verschlüsseln. Unter dem Menüpunkt "Zertifikate" kann man sich auch ein eigenes Zertifikat erstellen.


Im zweiten Menüpunkt ist das Datum und die Zeit anzupassen.

Unter "Benachrichtigungen" kann man, falls man es wünscht, sich Systemmeldungen per Mail senden lassen. Dazu aber später.


Bei "Geplante Aufgaben" kann man z.B. einen automatisierten Neustart festlegen.


Wie bereits zuvor erwähnt ist es möglich unter dem Menüpunkt "Zertifikate" sich ein eigenes Zertifikat zu erstellen.



Über den Menüpunkt "OMV-Extras" waren bereits beim allerersten Upgrade (siehe Part 1) zahlreiche Zusatzpakete installiert worden. Eine genaue Auflistung findet man hier .



Bei "Reale Festplatten und Dateisysteme bindet man nun externe Datenträger ein. Bei mir hat es sich gezeigt, dass es notwendig war den USB-Stick zuvor mit ext4 zu formatieren (siehe Part 1).


Bei den Punkten "Benutzer und Freigegebene Ordner" ist es leicht einen Benutzer, dessen Passwort und Ordner anzulegen die später freigegeben werden sollen. Die Menüführung ist hier selbsterklärend. Auch die Einstellung der Rechtevergabe ist sehr übersichtlich gestaltet.

Ich habe diese "freigegebenen Ordner" danach unter dem Punkt SMB/CIFS (Samba) für das lokale Netzwerk sichtbar-, und mit dem geeigneten Passwort, auch als bearbeitbar konfiguriert.

Auch dieses Menü ist schlichtweg selbsterklärend.


Ein toller Punkt ist "Systeminformationen". Hier erfährt man anhand einer übersichtlichen Grafik Auslastung der Festplatten, CPU und RAM.





Die Bearbeitung der Datein auf dem NAS können wie bei mir einfach über den Dateimanager Dolphin (KDE), oder z.B über Midnight-Commander (Paket heißt mc) erfolgen.
Bei Dolphin war einfach über den Eintrag "Netzwerk" (unter Orte) auf Samba-Freigaben zu klicken. Fast sofort erschien das NAS. Durch Doppelklick wurden die freigegeben Ordner angezeigt. Wollte man einen davon öffnen wurde das Passwort verlangt. Dies klappte und klappt nach wie vor reibungslos.

Beim Midnight-Commander konnte ich einfach unter Datei durch den Eintrag  "Samba-Protokoll" das NAS aufrufen und nach der Passworteingabe auf den jeweiligen freigegeben Ordner zugreifen.


Da ich das NAS zur Zeit nur im lokalen Netzwerk verwende, habe ich die Ports noch nicht geändert.
Den SSH-Port kann man leicht im Menüpunkt SSH ändern. Will man danach über die Konsole und per ssh auf das NAS zugreifen benötigt man zusätzlich den Befehl -p[Port].

Also:    ssh -p[neuer Port ohne Klammern] root@[IP-Adresse ohne Klammern]

Nach fast einem Monat Laufzeit gibt es keinerlei Probleme. Alles läuft reibungslos und ist so nützlich, dass es bereits jetzt fast nicht mehr wegzudenken ist.


Allerdings bekomme ich über die Systemmails oft Meldungen wie z.B.:

/etc/cron.daily/logrotate:
error:log /var/log/alternatives.log last
rotated in the future -- rotation forced

Die beeinflussen zwar die Funktion nicht, aber dem Wort "error" möchte ich doch auf den Grund gehen (event. in Part 3). Bis jetzt war meine Internetrecherche, auch beim OMV-Wiki, aber erfolglos.

Roman.


Mittwoch, 5. Juli 2017

NAS (Network-Attached-Storage) with Openmediavault on RaspberryPi 3 - (Part 1)




"Irgendwann findet der RaspberryPi den Weg in jedes Haus!" - Diese Worte habe ich vor kurzem auf Twitter geschrieben.
Der RaspberryPi hat den Weg zu mir gefunden, da ich mich schon seit längerem mit dem Gedanken beschäftigte, mir ein kostengünstiges NAS anzuschaffen oder selbst zu bauen. Dessen Funktion sollte ein immer erreichbarer Datenträger sein, auf den die PC's, Laptops und Smartphones zuhause zugreifen können (im Haus befinden sich Linux, Android und (leider) Geräte die mit Windows laufen).
Schlicht gesagt eine kleine "Heim-Cloud". Ein "Spiegeln" (RAID 1) diverser Festplatten auf dem NAS wäre nicht unbedingt von Nöten, sowie (zur Zeit) ein Zugang von jenseits des Routers.
Die Möglichkeit einfach einen USB-Stick in den Router zu stecken und als externes Laufwerk zu mounten bestand/besteht bei meinem Router nicht. Weiters reizte es mich einfach mit dem RaspberryPi zu hantieren.

Kaum war der Entschluss gefasst, wurde auch schon die Hardware bestellt.

Einkaufsliste:
  1. RaspberryPi 3 Modell B
  2. 16 GB SD-Karte (Class 10)
  3. Netzteil 5V / 3A
  4. Gehäuse (transparent) mit 2 Kühlkörper
  5. USB-Stick mit 16 GB (als Festplatte) (mit ext4 formatiert!!)
Da ich den 16 GB USB-Stick bereits hatte, beliefen sich die Kosten auf rund € 62,-. In einem RaspberryPi-Forum wurden die Jahresstromkosten im 24/7-Betrieb mit rund € 12,- veranschlagt. (Schande - als ehemaliger Elektriker sollte ich mir das auch selbst ausrechnen können :-) ) Kosten und Nutzen-Faktor ist also in Ordnung.






Als Software sollte "Openmediavault", eine freie Software die auf Debian/GNU (Jessie) beruht zum Einsatz kommen.



Ablauf:

Das aktuelle Image von Openmediavault für den RaspberryPi 3 wurde von hier heruntergeladen.





Das Entpacken der .gz-Datei führte ich mit dem Dateimanager Dolphin von KDE per Rechtsklick und "hier entpacken" durch. Die rund 530 MB wuren so zu einer 3,6 GB großen Datei.
Die SD-Karte wurde mittels dem mitgelieferten Adapter in den PC (bei mir ein openSUSE leap 42.2  System mit der KDE Oberfläche) gesteckt. Danach wurde in der Konsole/Terminal mit root-Rechten (su oder sudo) durch den Befehl  fdisk -l  (fdisk -kleines L) der Mountpoint der SD-Karte herausgefunden. fdisk -l gab bei mir  /dev/sdb1 aus.

Beim Übertragen der entpackten .img-Datei auf die SD-Karte gab es ein kleines Problem. Der, in diversen Anleitungen und Linuxzeitschriften empfohlene Konsolenbefehl dd (dd if=omv_rpi2_rpi3_3.063.img of=/dev/sdb1) klappte trotz Erfolgsbestätigung nicht. Der RaspberryPi fand danach auf dieser SD-Karte keine bootbare Datei.
Deshalb habe ich das Programm imagewriter von SUSE Studio für das Kopieren der .img-Datei verwendet. Imagewriter ist ein grafisches Tool, dessen Zweck es ist bootfähige USB-Sticks zu erstellen. Das Programm ist in den Standard-Repos von openSUSE enthalten. Damit klappte es sofort. Auffallend war jedoch, dass imagewriter den Mountpoint der SD-Karte auf /dev/sdb statt auf /dev/sdb1 fand. Hier lag wahrscheinlich der Fehler.

Anschließend kam die SD-Karte in den RaspberryPi. Ein Netzwerkkabel wurde als Verbindung in den RaspberryPi und in den Router gesteckt, sowie das Netzteil in die Steckdose. Der RaspberryPi erwachte zum Leben.

Am PC ermittelte ich durch den Aufruf des Dashboard des Routers im Browser (IP-Adresse des Routers in die Adresszeile eingeben) alle derzeit verbundenen Geräte mit dem Router und entdeckte auch bereits den RaspberryPi. Durch Anklicken konnte ich dessen (derzeitige) IP-Adresse in Erfahrung bringen, und durch einen weiteren Klick konnte ich auch den Router anweisen zukünftig den RaspberryPi immer die gleiche IP-Adresse zu zuweisen. Eine gleiche IP-Adresse ist wichtig für das spätere Arbeiten mit dem NAS.
Nach dem Speichern der Änderungen verließ ich wieder das Router-Dashboard.

Da SSH (Secure Shell) bei Openmediavault bereits standardmäßig aktiviert war, öffnete ich die Konsole am PC und rief mit dem Befehl ssh root@[ermittelte IP-Adresse] Openmediavault auf. Hier, beim ersten Einstieg wurde die Bestätigung des Fingerprints verlangt. Danach das Passwort. Standardmäßig ist für root das Passwort "openmediavault" eingestellt. Nach dessen Eingabe war man auch schon als root angemeldet.



Es wurde empfohlen zuerst eine Aktualisierung und anschließend einen shutdown durchzuführen. Daher führte ich die System-Aktualisierung mit den Befehlen apt-get update und danach apt-get upgrade durch. Nach der Aktualisierung, welche rund 5min dauerte, fuhr ich mit shutdown -h 0 das System herunter und nahm den RaspberryPi vom Strom.

Erst Jetzt wurde der 16 GB USB-Stick in den RaspberryPi gesteckt und dieser wieder mit Strom versorgt, sodass er das frische Betriebssystem auf der SD-Karte wieder hochfuhr ( erneut bootete  - Satzänderung nach Blogkommentar von Didi). In weiterer Folge zeigte sich ein Problem mit der Formatierung des USB-Sticks. Dieser war mit FAT formatiert. In Wikipedia stand zwar, dass Openmediavault mit FAT umgehen könne, aber auf dessen Website wurde FAT nicht aufgelistet. In einschlägigen Foren wurde als Formatierung ext4 empfohlen. Interessanterweise gab es keine Probleme beim Einbinden des Datenträgers, sondern in weiterer Folge mit der Rechtevergabe der einzelnen Benutzer. Die Umformatierung des vom RaspberryPi wieder entferneten und in den PC gesteckten USB-Sticks erledigte ich mit dem openSUSE Partitionierer, den ich über das YasT-Kontrollzentrum aufrief. Danach steckte ich den Stick zurück in den RaspberryPi.



Erneut meldete ich mich als root über die Konsole des PC's mit ssh root@[ermittelte IP-Adresse] an. Mit dem Befehl passwd root änderte ich das Standardpasswort für root und meldete mich wieder ab.

Durch Aufrufen der nun ständig gleichbleibenden IP-Adresse des NAS im Browser gelangte ich nun zum Dashboard von Openmediavault. Hier stellt man zuerst die Sprache ein und meldet sich als admin mit dem Standardpasswort (für admin) "openmediavault" an. Gleich zu Beginn führte ich eine Passwortänderung unter dem ersten Menüpunkt "Webadminpasswort"durch.






Das Fundament für mein NAS war somit erstellt.

Das Einrichten von Openmediavault (Datenträger einbinden, Benutzer anlegen, Samba-Freigaben, Portänderung, .....) wird in Teil 2 folgen.


Roman.

Montag, 8. Mai 2017

The Tux-Kurbel has finished another half marathon!

Am 1. Mai war es soweit. Nach dem Marathon im November letzten Jahres sollte nun ein Halbmarathon in Bad Blumau, ein Ort der durch seine Hundertwasser-Therme bekannt ist, absolviert werden. Bei den 21 Kilometern sollte nicht nur das Durchkommen, sondern auch eine entsprechende Zeit angezielt werden. Die Marathonzeit von 3:34:24 versprache doch eine Zeit unter 1:40.
Im Training laufe ich solche Distanzen öfters, aber seit ca. 25 Jahren nicht mehr im Wettkampftempo. Meinen letzten Halbmarathonbewerb hab ich als 20-jähriger mit 1:33:50 beendet. Das ist lange her.....

Das Wetter hat gepasst und top motiviert bin ich zu einer Zielzeit von rund 1:35 bis 1:40 gestartet. Schon nach der ersten Runde habe ich gemerkt, - heute gehts was!

So habe ich den Bewerb mit 1:32:14 - meine schnelleste, je gelaufene Zeit über diese Distanz - beendet (Ergebnisliste) . Es gelang mir sogar in meiner Altersklasse M40 den 18. - und in der Gesamtwertung der Männer den 43. Platz zu belegen. Der Bewerb war top organisiert, was sicher bei den rund 3000 Startern in allen Bewerben nicht einfach war. Zusätzlich gab es einen gratis Thermeneintritt für die Finisher!

Das gezielte Training für den Novembermarathon beginnt mit Juni. Vielleicht kann ich auch hier meine letzte Zeit unterbieten?


Roman.

Freitag, 21. April 2017

I have found the hardware list of my first PC!

Kleine Renovierungsarbeiten und der Frühlingsputz brachten die Hardwareliste meines ersten PC hervor. Akten und Ordner wurden entrümpelt, Bedienungsanleitungen und Garantiebestätigungen - von Geräten die schon lange nicht mehr im Haus sind - entsorgt.

Doch dieser kleine Zettel wird archiviert. Es war mein erster PC. Als auch er entsorgt wurde, waren bis auf das Mainboard, Floppy-Disk und das Gehäuse sämtliche Komponenten ausgetauscht. Mehr Ram, bessere CPU, zusätzliche Grafikkarte, neues Netzteil, neues DVD-Laufwerk, neuer DVD-Brenner, bessere Lüfter, größere HDD und nicht zu vergessen - eine neue Batterie am Mainboard.
Diese Umbauten und dem Ausprobieren diverser Linuxdistributionen zogen mich immer tiefer in die Materie und erweiterten mein Wissen auf diesem Gebiet.
Man merkt, hier liegt eine kleine emotionale Bindung vor. :-)


Pure Nostalgie, wenn man diese Werte sieht!

Nach kurzer Recherche fand ich natürlich diverse Linux-Ableger, welche noch mit 256 MB Ram zurechtkommen würden. Hier wären z.B. Puppy Linux , antiX  oder Bodhi Linux zu nennen. Bei Bodhi Linux, bei welchem das Gesamtkonzept am Besten ankommt, wären die Mindestanforderungen sogar noch darunter.

Die Sinnhaftigkeit des Einsatzes so eines Systems als Arbeits-PC ist jedoch meiner Meinung nach zweifelhaft. Alleine schon mit einem Browser wie Firefox wäre das System überfordert. Wie auch aus dem Systemanforderung des Firefoxs hervorgeht. Chromium verhält sich da nicht anders. Natürlich gibt es andere, nicht so systemhungrige Browser oder Konsolenbrowser, diese sind aber in ihrer Funktion beschränkt.

Jahre später werden diese Zeilen geschrieben mit:

  • 4-Kernprozessor mit je 2,4 GHz
  • 4 GB RAM
  • Grafikkarte mit 1 GB RAM
  • 1 Terabyte HDD
...... und nicht zu vergessen - LINUX!!



Die Zeit bleibt nicht stehen!

Roman

Montag, 27. Februar 2017

How to fix the rtl8723be (Realtek-Wifi) problem on openSUSE leap 42.2

Da mein altes Notebook mir bereits seit 8 Jahren dient, ist es natürlich in die Jahre gekommen. CPU und GPU sind für ein Linuxsystem mit KDE-Oberfläche noch mehr als ausreichend, aber an der Peripherie merkt man doch deutlich das Alter. So gibt es einige Gebrauchsspuren. Der Rand des Displays hat einen Sprung im Plastik. Der Akku - dieser wurde bereits einmal ausgetauscht - hält keine Stunde mehr. Der Lüfter ist nervig laut geworden - ein Ersatz würde ca. € 45,- kosten. Nicht viel Geld, aber in ein so altes Gerät noch investieren?

Also musste ein neues Notebook her. Da ich aber meinen Desktop PC als Haupt-PC nutze aber mein Notebook nur für Office-Anwendungen und Vorträge, hatte ich diesbezüglich keine großen Ansprüche. Deshalb entschied ich mich für ein kostengünstiges Einsteiger-Notebook von HP. AMD A6 Prozessor, 4 GB RAM, 1 TB HDD, DVD Laufwerk, 15,6 Zoll Display mit 1920x1080 Auflösung, sollten für meinen Gebrauch reichen. Mit einem Gewicht von 2,4 Kilogramm ist es dazu noch knapp mehr als einen Kilogramm leichter als mein altes Notebook. Weiters entschied ich mich absichtlich für ein Gerät ohne vorinstalliertem Windows.
Eine Internet-Recherche ergab, dass es mit der AMD  A-Reihe keine Probleme seitens Linux gibt, und deshalb war es rasch bestellt. Auch fand ich HP - hier vor allem im Druckerbereich - den Linuxusern immer sehr entgegenkommend (Bereitstellung von Treibern).

Am Gerät selbst gibt es nichts zu meckern. Alles so wie bestellt.

Konfiguration:

OpenSUSE leap 42.2 wurde mittels bootfähigen USB-Stick ohne Probleme installiert.

Doch bei der Konfiguration der Wlan-Verbindung wollte es nicht so recht klappen. Über YasT / Hardware fand ich heraus, dass es sich um einen rtl8723be Wifi Chipsatz handelt. "hwinfo" und "lspci" brachten auch keine anderen Ergebnisse. In den Standardrepos gab es keine extra Firmware dafür. Eine Internetrecherche ergab, dass dieser Chipsatz von Realtek jedoch seit Kernel 4.2.x unterstützt wird - also auch bei openSUSE leap 42.2.

Also holte ich mir über das openSUSE Softwareportal (rtl8723be in Suche eingeben) ein Repo mit der neuesten Firmware.
Doch auch das brachte keinen Erfolg.
Das Wlan funktionierte - aber nur mit einer Reichweite von ca. einem Meter Abstand vom Router. Danach brach die Verbindung ab.

Eine weitere Internetrecherche brachte die Lösung: Das Problem lag am Setup der "Antenne" der Wlan-Karte. Mit Hilfe dieser Anleitung konnte ich mein Problem lösen.

Man geht wie folgt vor:

Konsole/Terminal öffnen und "root-Rechte" erlangen (mittels su und Passwort für root).

Danach folgende Befehle eingeben:

 modprobe -rv rtl8723be   (Enter)

modprobe -v rtl8723be ant_sel=1  (Enter)  

Damit das Setup auch nach einen Neustart bestehen bleibt, gibt man folgenden Befehl ein:

echo "options rtl8723be ant_sel=1 fwlps=0" | tee /etc/modprobe.d/rtl8723be.conf

Danach nur noch:

modprobe -r rtl8723be

modprobe rtl8723be


Fertig! Nun sollte das Wlan anstandslos funktionieren.

Sollte es nicht funktionieren kann man noch alternativ  ant_sel=2 oder ant_sel=0 ausprobieren. In der von mir im Internet gefundenen Anleitung war zum Beispiel ant_sel=2 der Schlüssel zum Erfolg. Bei mir war es ant_sel=1.
Dieses Antennen-Setup scheint daraus zu resultieren, da Wlan und Bluetooth ein und dieselbe Schnittstelle bzw. Adapter sind und der Treiber an der Einstellung scheitert.

Mein Wlan funktioniert nun einwandfrei. Die Reichweite ist ausgezeichnet.

Auf der Webseite von HP fand ich dazu leider keine Lösungsansätze.

Roman


Donnerstag, 15. Dezember 2016

Screenfetch - a nice bash tool on openSUSE leap 42.2

Screenfetch ist ein nettes kleines Tool zur Darstellung eines Systemüberblickes im Terminal (bash). Screenshots davon habe ich schon öfters mal bei Twitter und Co. gesehen, wurde aber jetzt erst bei intux.de zufällig fündig.

Bei openSUSE leap 42.2 liegt es bereits in den Standardrepositorien auf und ist daher lediglich über YasT / Software installieren oder mittels zypper install screenfetch  (in der Konsole mit root-Rechten) zu installieren.



Danach öffnet man die Konsole und gibt den Befehl screenfetch ein.



Je nach Farbeinstellung (Profil) der Konsole ist das Erscheinungsbild unterschiedlich.



Fällt eindeutig unter "klein aber oho"!

Danke an intux.de!

Roman.


Montag, 28. November 2016

Snapshot management with Snapper claims a lot of space in the root partition on openSUSE leap 42.2

Das System Recovery Tool "Snapper" ist bereits seit openSUSE 12.1 Teil der Distribution. Es werden damit automatisch sogenannte Snapshots - also Wiederherstellungspunkte - erstellt.

Ausführliche Erklärung zu Snapper

Es war mir bis jetzt noch nie in diesem Maße aufgefallen, doch ließ mich die Größe meiner root-Partition nach dem Upgrade auf openSUSE leap 42.2 zweifeln. Von der automatisch angelegten Größe von 40 GB für /root  waren nur noch knapp 7 GB frei. Normalerweise hat meine root-Partition ein Volumen von 10 bis max. 15 GB.

Das Übel wurde rasch gefunden. Es waren die Snapshots. Denn es waren auch noch alle Snapshots von openSUSE 42.1 vorhanden.

Diese konnten über Anwendungsmenü / Yast / Snapper / gelöscht werden. Nur die letzten 3 Snapshots von der langen Liste ("vorher&nachher" und einmal mit "important=yes" markiert) behielt ich. Standardmäßig behält sich openSUSE leap 42.2 die 10 letzten Snapshots.

Nach dieser Aktion waren wieder mehr als 27 GB auf meiner root-Partition frei.

Roman.


Moving of /var/cache to a separate subvolume - openSUSE leap 42.2

Wenn man auf openSUSE 42.2, so wie ich hier beschrieben habe, das Upgarde durchführt, wird seitens openSUSE empfohlen /var/cache in ein eigenes Subvolumen zu verschieben.Bei einer kompletten Neuinsatllation ist dies nicht nötig!

Wie dies durchzuführen ist, kann man hier unter Punkt 3 Move /var/cache to a separate subvolume auf der openSUSE Webseite nachlesen. Es ist ganz einfach. Man öffnet die Konsole (Terminal) - erlangt root-Rechte - und führt Punkt für Punkt aus. Man gibt die jeweiligen Befehle per Copy and Paste ein und bestätigt mit Enter. Ich z.B. hatte keine Datei mit /var/cache.old.

Ist man bei dem Absatz "....entry to /etc/fstab for the new /var/cache subvolume......" angekommen, so hilft vielleicht die folgende kurze Beschreibung:

Über das Anwendermenü / System / File Manager - Super User mode / wird der Dateimanager Dolphin mit root-Rechten geöffnet. Über Basisordner / etc / gelangt man in den etc Ordner, in welchen sich die Datei fstab befindet. Diese wird mit Doppelklick geöffnet.

Hier habe ich die Zeile

UUID=821........cc..........e-ea......acc......bfd..  /var/tmp btrfs subvol=@/var/tmp  @ @

einfach kopiert und am Ende der Auflistung wieder eingefügt. Anschließend werden in der neuen Zeile die Wörter "tmp" durch das Wort "cache" ersetzt und fstab gespeichert. Dolphin wird anschließend geschlossen und in der Konsole der letzte Befehl von der openSUSE Webseite ausgeführt. Nach einem Neustart ist /var/cache in ein eigenes Subvolumen verschoben worden. Dies soll deshalb wichtig sein, da durch Snapshots des Tools Snapper das Datenvolumen in /var/cache rasant ansteigen kann.

Roman.

Sonntag, 20. November 2016

openSUSE leap: Upgrade from 42.1 to 42.2

Nach rund einem Jahr war es wieder so weit und eine neue Version von openSUSE leap ist erschienen.Die 42.2´er Version wurde veröffentlicht.

Also Zeit das Upgrade durchzuführen.

Das Upgrade der 13'er Versionen habe ich  hier in meinem Blog ausführlich beschrieben. Dies ist bis heute auch die meistbesuchte Seite in meinem Blog.

Das Upgrade von 13.2 auf leap 42.1 führte ich nicht so durch, da sich openSUSE leap bereits im Grundaufbau komplett von den bisherigen Versionen unterschieden hat. Ich wählte eine Neuinstallation.

Nun aber, da dies nur ein Upgrade von "leap zu leap" war, wählte ich wieder die Methode mit "zypper". Allerdings in leicht geänderter Form.

Upgrade:

Einfach aus Interesse wählte ich eine Mischform aus "Yast" und "zypper". Es erspart eine Tipparbeit in der Konsole und ist dadurch für "Laien" nicht so abschreckend.

Los gehts!

Zuerst wichtige Daten sichern, oder das gesamte Betriebssystem! (z.B. mit Clonezilla)

Über das Anwendermenü und Yast gehts zu den Repositorien (root-Rechte erforderlich!):


Hier löschen wir alle eingebundenen Repositorien außer diese:


Non-Oss, Oss, Update und Update Non-Oss bleiben erhalten!!

Danach verlassen wir Yast und öffnen die Konsole. Erlangen root-Rechte (Administratorrechte) mit dem Befehl "su" und der anschließenden Passworteingabe (diese sieht man beim Tippen nicht!!).

Es folgt der Befehl "zypper ref" (mit Enter bestätigen)

Hier werden die (noch verbliebenen Repos) aktualisiert.



Danach der Befehl "zypper up" (mit Enter bestätigen)

Hiermit wird das System auf den neuesten Stand gebracht. Die Aktualisierung muss mit einem "j" für "ja" bestätigt werden.

Ist dies geschehen, so verlassen wir die Konsole wieder und gehen zurück zu den Repositoren mittels Yast.



Nun klicken wir jedes einzelne Repo an und öffnen es mittels den "Bearbeiten" - Button. Das Fenster "Server und Verzeichnis" erscheint. Nun ersetzen wir einfach 42.1 durch 42.2 sowohl in der oberen, als auch in der unteren Zeile.
Wie gesagt, diese Änderung führen wir bei allen vier Repositorien durch. Dabei ließt sich das System stets beim neuen Server ein. Beim letzten Repo muss die Lizenzvereinbarung mittels "Weiter" bestätigt werden.

Nun wieder raus aus Yast und rein in die Konsole. Wieder root-Rechte mittel "su" und Passwort.erlangen.

Es folgen die Befehle:

  •  "zypper clean --a" (mit Enter bestätigen) (hierbei werden die Repos bereinigt)
  •  "zypper ref" (mit Enter bestätigen) (hier werden die Repos neu eingelesen)


                                                             
Nun folgt der Upgrade-Befehl "zypper dup" (mit Enter bestätigen)

Nach zwei bis drei Bestätigungen mit "j" für "Ja" und durchgelesenen Lizenzen (diese können mit "q" übersprungen werden) beginnt der Download der neuen Pakete.



...und es läuft und läuft.....

Ist der Download beendet so wird gleich in der Konsole der Befehl "reboot" eingegeben. Das System startet neu, und wenn alles glatt gelaufen ist, ist das Upgrade ist vollbracht.


In der Systeminformation sollte nun 42.2 zu sehen sein mit der KDE 5.8.2 Version.


Nun kann man wieder über Yast / Repositorien gewünschte zusätzliche Repos (für Multimedia etc,..) einbinden (zumeist über Hinzufügen / Community-Repos).

Ich hoffe das Alles gelingt!

Roman.