Posts mit dem Label Konsole werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Konsole werden angezeigt. Alle Posts anzeigen

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

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.



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


Montag, 28. November 2016

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.

Donnerstag, 28. Juli 2016

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.

Mittwoch, 20. November 2013

openSUSE - Upgrade 13.1






Ja, da schlagen die Herzen höher, wenn es wieder einmal eine neue "SUSE" gibt. Brandneu, seit gestern Mittag auf dem Markt!

Nach einer morgendlichen Radrunde, bei der ich mir nur durch unermüdlichen  Einsatz meine Fahrspur in den schier blickdichten Novembernebel schnitt (?! ich hätte Philosoph werden sollen), möchte ich nun meine Erfahrung mit dem Upgrade von 12.3 auf 13.1 der Linux-Distribution "openSUSE" schildern.

Nachdem ich Laptop und PC besitze, und beide stets gleichauf sind mit Betriebssystem und Programmen, wollte ich doch zuerst den Laptop "upgraden".

Eine Möglichkeit ist natürlich die neue Version in DVD-Form herunterzuladen, sie zu booten und die Aktualisierung durchführen. Dies ist mir aber zu umständlich. Ich benutze/benutzte  "zypper"


Los gehts!

Zuerst Konsole öffnen, "root"-Rechte erlangen und mit folgenden Befehlen das System einmal aktualisieren:

zypper ref
zypper up



Mit dem Befehl exit wieder raus aus der Konsole und über Yast die Repo-Verwaltung aufrufen.
(folgendes würde sich auch mit dem Befehl zypper mr -adR erledigen lassen, ist mir aber andersrum lieber)

In der Repo-Verwaltung werden nun alle eingebundenen Repos deaktiviert und gelöscht!



Anschließend gehts zurück in die Konsole mit "root"-Rechten. Nun werden die neuen Repos mit den folgenden Befehlen eingebunden.

zypper ar -n "openSUSE-13.1 OSS" http://download.opensuse.org/distribution/13.1/repo/oss/ repo-13.1-oss
zypper ar -n "openSUSE13.1 Non-OSS" http://download.opensuse.org/distribution/13.1/repo/non-oss/ repo-13.1-non-oss
zypper ar -f -n "openSUSE13.1 Updates OSS" http://download.opensuse.org/update/13.1/ repo-13.1-update-oss
zypper ar -f -n "openSUSE-13.1 Updates Non-OSS" http://download.opensuse.org/update/13.1-non-oss/ repo-13.1-update-non-oss

Danach kommt noch ein:

zypper clean -a
zypper ref


Und dann endlich das "heilige" zypper dup


Kurz darauf werden die Pakete abgeglichen und das Downloadvolumen berechnet. Mit der Bestätigung gehts los!



Dann erscheinen nacheinander die Aufforderungen die Lizenzbestimmungen für "flash-player" und "gstreamer fluendo-mp3" zu bestätigen.





und es läuft und läuft,...(wie man an der Uhr erkennt mehr als 2 Stunden!!!)


Wenn der Download abgeschlossen ist, gleich mit den "root"-Rechten ein reboot eibgeben und das System startet neu.
Wenn alles, so wie bei mir, reibungslos geklappt hat, merkt man gleich (bis auf das neue Login-Fenster) keinen Unterschied. Alle Einstellungen wurden übernommen. Sogar Choqok zeigte sofort wieder neue Twitter-Post an.

Aber in der Systeminformation sieht man es:


Sekunden später, war auch bereits wieder das erste Update da!

(Cool - wird nun mit einem "Bug-Käfer" angezeigt!


Fertig!

Alles im allem zeigt sich die neue SUSE stabil und artig. Da ich das KDE-Repo eingebunden hatte, hatte ich bereits die Version 4.11.3 installiert. Die neue SUSE hat nur die Version 4.11.2 an Bord, was mich aber nicht stört, da ich zwischen den beiden Versionen keinen Unterschied feststellen konnte.

Auch LibreOffice hatte ich aus einem Build-Repo in neuerer Version. Während der Installation musste ich einmal bestätigen die bereits installierte Version zu löschen, damit die Neue geladen werden kann. Es hat sich aber dieselbe Version installiert.

So, jetzt gehts an kochen! Am Nachmittag ist dann der PC dran. Der ist übrigens vor einer Woche mit einem 24 Zoll LED-Hintergrundbeleuchtung Monitor von Benq aufgerüstet worden. Ich kann nur sagen - pralle Farben!

Roman.

Sonntag, 10. November 2013

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.

Mittwoch, 6. November 2013

KDE 4.11.3-1.1

Soeben werden die Pakete von KDE 4.11.3-1.1 eingespielt. Es sollen ja ca. 120 Bugs ( hier nachzulesen) beseitigt worden sein.

Für mich war KDE 4.11.2 bereits sehr stabil, deshalb bin ich gespannt, was es da noch zu verbessern gab.

Sobald die ersten Erfahrungen gemacht wurden, werden sie hier gepostet.

Weiters sind es nur noch 12 Tage bis openSUSE 13.1!

Da freue ich mich schon auf ein "zypper dup" (Konsolen-Upgrade)

Roman.


Dienstag, 10. September 2013

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.