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

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.

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.

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.

Which OCR tool works well on openSUSE Leap 42.1? - Here is a brief overview.

OCR  (optical character recognition) ist eine automatisierte Texterkennung. Texte in gescannten Bildern können erfasst werden und anschließend in eine Textdatei umgewandelt werden, wodurch diese bearbeitbar sind. Dies braucht man selten, aber doch.
Welches dieser Programme unter Linux, speziell bei openSUSE, effizient arbeitet, zeigt der folgende kurze Überblick:

Ausgangspunkt ist eine Textdatei in deutscher Sprache aus Wikipedia, die auf meinem HP Deskjet 2050-J510 series mit 300 dpi (grayscale) ausgedruckt wurde und anschließend mit 300 dpi (Graustufen) wieder mit dem HP Deskjet eingescannt wurde. Es wurden bewusst unterschiedliche Schriftgrößen verwendet und auch das eine oder andere Wort in englischer Sprache. Der Treiber des HP "All-in-one" kommt von hplip.


Testtext:

XSane:

Um einen Scanner unter Linux zu betreiben führt der Weg an XSane kaum vorbei. Auch dieses Tool kann mit Texterkennung umgehen. XSane benötigt dazu aber die Pakete "gocr" und "gocr-gui" aus den Standard-Repos.

"Text" wählen und die anschließend gescannte Datei als.txt Datei speichern. Das Ergebnis ist jedoch mehr als fraglich. Kaum ein Wort wurde richtig erkannt.

gimageReader

gimageReader ist eine grafische Oberfläche (GUI) von tesseract . Es ist in den Standard-Repos nicht enthalten, und muss über die Paketsuche eingebunden werden (als instabiles Paket). Es ist jedoch voll funktionstüchtig. Natürlich muss dazu auch tesseract installiert sein.

Auch hier wird der Text mit 300 dpi gescannt. Anschließend mit "Text erkennen" überprüft.

Ich habe das Ergebnis in ein LibreOffice Writer Dokument kopiert, verbessert und anschließend als .pdf gespeichert. Das Ergebnis ist hier bereits viel besser. Die rotmarkierten Stellen sind Fehler der Texterkennung. Typische Fehler sind Namen, Satzzeichen,...

Tesseract

Tesseract ist ein Tool rein für die Kommandozeile. Es liegt in den Standard-Repos vor und funktioniert einwandfrei. Das Ergebnis ist ident mit dem von gimageReader (natürlich, denn gimageReader arbeit ja mit tesseract).

Nun ist aber die Hürde mit der Konsole zu arbeiten für manche zu groß. Noch dazu ist im Jahre 2016 eine GUI für ein Programm kein Luxus mehr.

Online Dienst: Free Online OCR

Ein Beispiel für einen Web Dienst zu diesem Thema ist Free Online OCR . Hier habe ich den Testtext gesannt und in eine .pdf Datei umgewandelt. Diese wird hochgeladen und nach nicht mal einer Minute hat man die fertige Textdatei. Wahlweise .txt oder .docx. Ich habe wieder das Ergebnis (.txt) in ein LibreOffice Writer Dokument kopiert, verbessert und als .pdf gespeichert. Das Ergebnis ist das Beste meiner kleinen Testreihe. Die Fehler sind wieder rot gekennzeichnet.

Proprietäre und Open Source Software:

Natürlich gibt es noch einige proprietäre Software-Tools, auf diese möchte ich aber nicht weiter eingehen. Mein Interesse liegt doch eher bei Open Source.

Bei den Open Source Tools sollte Transkribus nicht unerwähnt bleiben. Dieses Tool befasst sich vor allem mit handgeschriebenen Texten (dazu fällt mich gleich die automatisierte Briefsortierung bei der Post ein). Dieses habe ich jedoch nicht getestet. 

Fazit:

Trotz einiger Möglichkeiten, installierbare Open Source OCR Tools zu nutzen, fällt mein Ergebnis doch eindeutig aus. Der Onlinedienst "Free Online OCR" hat die beste Erkennung und somit das beste Ergebnis.

Roman.

Die Konsole / Das Terminal

Wenn man nicht unbedingt ein Informatiker ist, oder zumindest in einer höheren technische Schule die Grundbegriffe des Programmierens erlenrt hat, scheut man vor der Bedienung des Terminals (oder Konsole) doch zurück.
Erstens fehlt einem die Kenntnis der Befehle und Zweitens die Angst etwas Falsch zu machen.

Deshalb sieht man dieses Zeichen nicht so gerne.

Ich selbst würde mich auch eher als "Lehrling" auf diesem Gebiet bezeichnen. Doch muss ich sagen, dass es sehr viele Hiflestellungen über das Internet gibt. So findet man nach kurzer Suche bereits unzählige Listen mit Linuxbefehlen und Tutorial-Videos.

Kleiner Tipp: Auf YouTube einfach mal nach "LinuxTerminal: Ein paar Grundlagen" suchen, und eine Menge Videos helfen das Terminal zu bedienen.

Glaubt mir, Berührungsängste sind rasch abgebaut.

Damit die Konsole auch seinen biederen Schrecken von weißer Schrift auf bedrohlichem schwarzen Hintergrund verliert, ist es möglich das Terminal (hier im KDE Desktop) optisch anzupassen.

Terminal aufrufen:

Über Einstellungen - auf "aktuelles Profil bearbeiten":

Erscheinungsbild wählen:

Hier sind bereits vorgegebene Ansichten inkludiert. Wenn man eine Ansicht wählt und anschließend auf "bearbeiten" klickt, ist es möglich einen selbstgewählten Hintergrund einzufügen.

Fertig! Meine Konsole zeigt nun "the power of LINUX"

Viel Spass beim Anpassen der Konsole!

Roman.

Sysrq-Magic-Keys des Linux-Kernels

In der Oktober/November 2013 Ausgabe der "Linux-Welt" Zeitschrift bin ich über einen netten und hilfreichen Artikel gestoßen.

"Linux läuft bekannt stabil. Aber wie bei jedem System gibt es Pannen und Benutzerfehler, die scheinbar den harten Reset über die Stromtaste erfordern. Sanfter und mit geringerem Risiko eines Datenverlustes arbeiten die Kernel-Hotkeys."

          Linux-Welt: 5-6/2013 Seite 24 f

Diese Notfalls-Hotkeys nennen sich die "Sysrq-Hotkeys" und bestehen aus drei gedrückten Tasten. Immer mit dabei ist die "Alt-Taste" und die "Druck-Taste".

Die "Druck-Taste" trägt auf vielen Tastaturen auch die Bezeichnung "S-Abf" - englisch "SysRq" - also "Systemabfrage" oder "System Request".

Die Hot-Keys sind nicht überall standardmäßig aktiviert. Das dauerhafte Aktivieren der Hot-Keys erledigt man so:

Terminal

sudo gedit /etc/sysctl.conf

Die Datei mit dem Eintrag "kernel.sysrq" suchen und den Wert auf "1" setzen. Also:

kernel.sysrq = 1

Datei speichern!

Ab dem nächsten Systemstart arbeiten die Hot-Keys dauerhaft.

Bei openSUSE gehts noch einfacher:

Aufruf von Yast - System - Kernel-Einstellungen und "SysRq-Tasten" aktivieren.

Eine Auflistung der möglichen Hot-Keys-Vartianten finden man hier .
(Wobei bitte die Taste "SysRQ" als die "Druck-Taste" zu verstehen ist)

Bei mir klappt diese Funktion des Linux-Kernels wunderbar, und konnte so mein System schon mal schonend herunterfahren.
Weiters muss ich zugeben, dass ich bis dato noch nichts von diesen Tasten-Kominationen gehört habe.

Fazit: Es lohnt sich doch Linux-Zeitschriften zu kaufen!

Roman.

Speicher der Grafikkarte

Ich denke die meisten Linux-User wissen auch welche Hardware unter der Haube ihres  PC´s verschraubt ist. Doch wenn man mal auf einem fremden PC, ich denke hier mal an Freunde die auf Linux umsteigen und bei der Installation Hilfe brauchen, ein Linux System installiert, kann die Hardware natürlich auch ausgelesen werden.

"sysinfo"  - eine GUI bei openSUSE z.B. oder ein  "hwinfo"  bzw. "lspci"  in der Konsole (mit root-Rechten) zeigen zwar Alles auf, jedoch den Speicher der Grafikkarte nicht.

Abhilfe:

1. Terminal öffnen
2. root-Rechte erlangen (su oder sudo)
3. Eingabe von " grep -i memory /var/log/Xorg.0.log "
4. Eingabe von " dmesg | grep drm "

In der folgenden Auflistung wird der Grafikkartenspeicher in MB angegeben.

Roman.