Samstag, 10. Februar 2018

Update failed on openSUSE 42.3 - ('/repodata/repomd.xml' not found ............/repo/non-oss/')

Es kommt schon mal vor, dass beim Versuch der Systemaktualisierung - sei es über die automatisierte Softwareaktualisierung oder mittels zypper up in der Konsole - ein Repositorium nicht eingelesen werden kann. Im Normalfall ist dies jedoch binnen Stunden oder maximal am nächsten Tag behoben. Schuld dafür, nehme ich an, sind Wartungsarbeiten am Server.
Doch seit ein paar Tagen schlug der Aktualisierungsversuch immer fehl. Wollte man das System manuell per zypper up (benötigt natürlich root-Rechte) aktualisieren, wurde folgende Meldung ausgegeben:


Nach kleiner Recherche im eigenen System hatte ich festgestellt, dass es sich um diese beiden Repos handelte:


Eine Suche in diversen Foren ergab gleich mehrere Lösungsansätze. Angefangen von der Verwendung eines neuen/anderen Spiegelservers bis hin zur Deaktivierung der betroffenen Repos.

Doch ein kurzer Eintrag in einem Forum im Jahr 2014 brachte die richtige Lösung:

Mit dem Befehl     zypper lr -d    wurden die eingebundenen Repos aufgelistet.


(Hier sah man bereits, dass alle Repos den selben Typ haben - "rpm-md".)


Auflistung ebenso mit     ls -l /etc/zypp/repos.d


Die Verbindung mit dem Server wurde mittels    ping -c1 download.opensuse.org   erfolgreich getestet.


Da laut des Forumeintrags der Typ des Repos mit rpm-md falsch war - er hätte yast2 lauten müssen - musste dieser mit folgenden Befehlen geändert werden:

- su        (root-Rechte)
- cd /etc/zypp/repos.d       (wechselt in das /etc/zypp/repos.d Verzeichnis)
- grep type repo-non-oss.repo repo-oss.repo      (listet den Typ der Repos auf)


- sed -i 's|type=rpm.md|type=yast2|g'  repo-non-oss.repo repo-oss.repo    (wechselt den Repo-Typ)

- grep type repo-non-oss.repo repo-oss.repo     (zeigt den gewünschten Erfolg - geänderter Typ)


- clear         (bereinigt nur die Konsolendarstellung zur besseren Darstellung des Folgenden)
- zypper ref     (aktualisiert alle Repos)



Die Systemaktualisierung konnte danach sofort ohne Probleme durchgeführt werden.


Warum es zu diesen Problem überhaupt kam und sich der Typ zweier Repos änderte ist mir nicht bekannt. Auch im Forumeintrag wurde nicht darauf eingegangen. 

Da der Thread bereits geschlossen wurde, konnte ich mich leider nicht bei "RainMaker" dafür bedanken. Schade, denn solche Problemlösungen sind "goldeswert" und haben ein Danke verdient!

Roman

Dienstag, 2. Januar 2018

How time flies!

Wie die Zeit vergeht! Unglaublich, aber es ist schon wieder ein halbes Jahr her, seit meinem letzten Blogeintrag.

Irgendwie gab es scheinbar keine so wichtigen Themen oder Neuerungen. Ich war aber nicht untätig.

im November stand wieder der Marathon an. Ich konnte meine Zeit gegenüber des Vorjahres um drei Minuten verbessern und lief die 42,195KM in einer Zeit von 3:31h.

Was Linux und openSUSE betrifft, ist alles unverändert. Weiterhin kommt leap 42.3 sowohl am Laptop als auch am PC zum Einsatz. Auch mein NAS (RaspberryPI - openmediavault) läuft wie am Schnürchen.

Nebenbei beschäftige ich mich zur Zeit, motiviert durch einen Freund (Softwareentwickler), etwas mit Datenbanken und deren praktischen Einsatz. Daher versuche ich mich näher mit LibreOffice Base auseinander zu setzen. Es ist zwar kein MS Access (Programm meines Freundes), aber zum Einstieg in diese Materie völlig ausreichend.

Als Ziel habe ich mir eine Softwarelösung zur Verwaltung eines Laufvereins gesetzt. Einige Abfragen und Formulare funktionieren bereits top. Formulare mit mehreren Unterformularen spießen sich noch.


Roman.


Mittwoch, 9. August 2017

Yahoo authentication failed in KMail 5.5.2 on openSUSE leap 42.3. The solution....

Zuerst ist es mir gar nicht aufgefallen, aber mein Yahoo IMAP Mailkonto wurde über KMail 5.5.2 in openSUSE leap 42.3 - im Gegensatz zu openSUSE leap 42.2 nicht mehr synchronisiert.
Es kam zwar eine Fehlermeldung, das scheinbar die Zugangsdaten nicht richtig sind, diese kam aber auch alle heiligen Zeiten mal in der Vorgängerversion. Diese hab ich zumeist ignoriert, denn nach einem Neustart war alles wieder o.k. Da über dieses Konto selten Emails laufen, bestand auch kein dringender Handlungsbedarf.

Doch nun scheint es als wäre ich mit KMail völlig von Yahoo ausgesperrt. Android-Mail (auf meinem Smartphone) hat mit Yahoo Mail keinerlei Probleme. Ebenso funktioniert der Einstieg über die Webseite völlig reibungslos.
Auch Änderungen an der Authentifizierung in KMail (Port, SSL/TLS, PLAIN, Klartext,...) brachten keinen Erfolg.

Zu erwähnen ist auch, dass GMX und GMAIL weiterhin ohne Probleme funktionieren.


Lösung:
Die Lösung fand ich als ich mich über den Browser in mein Yahoo Mail einloggte. Hier kam wie gewohnt gleich einmal die Sicherheitsmeldung "externe Zugriffe" zu unterbinden. Gemeint sind hier Android-Mail und dergleichen.

Unter dem Menüpunkt "Account-Info / Account-Sicherheit" fand ich den Eintrag "App-Passwort-Generator". Hier wählt man aus einer Reihe von Apps das Richtige aus, beziehungsweise erstellt einen neuen Eintrag. Mithilfe des erstellten Passwortes, welches anschließend in KMail unter "Benutzernamen / Passwort" eingetragen wird (anstelle des üblichen Passwortes), ist bereits der erste Schritt getan. Nun muss nur noch in KMail bei "Authentifizierung" NTLM ausgewählt werden.
(was NTLM ist findet man hier )











... und schon ist der Yahoo-Account wieder bereit!



Diese "Zwei-Schritt-Authentifizierung" ist von Yahoo zwar nett, aber etwas im Verborgenen.

Roman.

Donnerstag, 27. Juli 2017

openSUSE leap: Upgrade from 42.2 to 42.3

Gestern erschien die neueste Version von openSUSE leap - 42.3.

Die Vernunft sagt einem, dass man besser immer etwas zuwartet mit dem Upgrade. Erste Bugs sind dann eventuell bereits beseitigt.

Doch wie heißt es so schön - "Der Geist ist willig nur der Körper ist schwach!"

So machte ich mich bereits ein paar Stunden nach der Veröffentlichung ans Werk um das Upgrade durchzuführen.

Ich wählte dabei das gleiche Vorgehen wie beim Upgrade von 42.1 auf 42.2 .
(For upgrading 42.2 to 42.3 I used the same procedure like 42.1 to 42.2 )

Alles lief reibungslos. Nach einem Download von mehr als 4100 Paketen und einem Reboot startete openSUSE leap 42.3. Alle Systemeinstellungen wurden übernommen. Sogar das von mir nachträglich konfigurierte Wlan (rtl8723be - dazu gab es einen Blogeintrag) war sofort wieder startklar.
(After download of more than 4100 packages and one reboot the system works well. All system-settings are remained intact.)

Roman.



Update 28.07.2017:

Aufgrund eines Kommentares beim Blogeintrag 42.1 auf 42.2 möchte ich nochmals darauf hinweisen, dass es sehr wichtig ist alle die dort beschriebenen Schritte auch in deren Reihenfolge auszuführen. Auch ist beim Bearbeiten der Repos nur der "2" von 42.2 auf einen"3" (42.3) zu ändern - sonst bleibt der Link des Repos unverändert.

Dann sollte es reibungslos klappen und nach einen Reboot in der Systeminfo folgendes Bild erscheinen:



Das System läuft nach einem Tag immer noch ohne Probleme. Optisch - bis auf etwas buntere Plasma-Icons - kein Unterschied. Doch merkt man vor allem bei akonadi (Mail, Kalender,..) eine Performance-Steigerung!

Roman.



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