Category Archives: Erfahrungsberichte

Erfahrungen aus dem Alltag eines Linux-Anwenders

Crash, Linux, GA-EP45T Extreme, nohz und F5i

Posted on by

Eine kleine Geschichte aus meinem Alltag, die ich mit einer rethorischen Frage beginnen möchte:

Ist Linux ist besser als Windows? Ja, unbedingt – aber …. Bei dem nachfolgend beschriebenen Erlebnis fühlte ich mich doch wieder an Schrecken aus längst vergangen geglaubten “Blue Screen” Zeiten erinnert.

Ich konnte das nachfolgende Problem zwar beseitigen, aber es war ein richtig ernsthafter Incident/Crash im laufenden Betrieb. Die Behebung glich dabei einer kleinen Odysee durch wenig befahrene Gewässer. Die Ursache des Crashes habe ich bis jetzt nicht verstanden. In den Logfiles ist nichts Ungewöhnliches zu finden. Irgendwie ist sowas nicht gut …..Vielleicht hat ja da draussen jemand einen kleinen Tipp für mich …. Ich möchte nicht an Viren unter Linux glauben ….

Mein Arbeitsplatz-PC beruht auf einem GA-EP45T Motherboard. Dieses Motherboard ist mit 8GB ausgestattet und hat bereits Opensuse 11.0, 11.1 und 11.2 und damit eine Reihe von 2.6.X Kernelversionen brav überstanden. Als Prozessor werkelt ein Q9550. Ich fahre das Board mit wirklich moderaten BIOS-Einstellungen (BIOS-Version 5Fi) und nutze das Enhanced Intel Speed Stepping. Die Graka ist eine Nvidia GeForce 9800 GTX+ -Variante. Ich fahre auf dem Desktop KDE 4 – aktuell KDE 4.4.2. Die aktuelle Kernelversion ist 2.6.31.12 – vor kurzem upgedated ! Meist laufen 1 bis 2 VMware Workstation-Instanzen im Hintergrund mit. Bis zur vergangenen Samstagnacht war das System nun über 1,5 Jahre hinweg auch unter Last ein sehr stabiles System (von den üblichen KDE 4 Kinderkrankheiten mal abgesehen).

Aber was geschah nun vergangenen Samstag ? Das System war ca. 2 Stunden sich selbst überlassen gewesen. Das Aktivieren eines Ruhezustands war aber nicht als Energesparoption eingestellt. Entsprechend reagierte das System zunächst auch ganz normal auf meine Bedienung. Dann aber wollte ich aus einem bestimmten Grund unter KDE eine neue Kontroll-Leiste einrichten. Das System stand dabei in keiner Weise unter Last. Temperatur, Lüfter etc. völlig in Ordnung. Plötzlich verhielt sich der Desktop merkwürdig. Stockender Bildaufbau, Verzögerungen in der Ausführung, Mausreaktion schlecht, etc.. Und dann begann das System aus heiterem Himmel neu zu booten.

Leider kam es dabei nicht weit – Grub war noch OK, dann erschien wie gewohnt der grafische Boot-Bildschirm von Opensuse 11.2 auf der Konsole – und das war es denn auch. Das System stand – gem. SUSE-Laufbalken offenbar noch weit vor der Analyse der Plattenpartitionen. Zudem war kein Wechsel vom grafischen Splash-Screen zum Textkonsolenmodus mehr möglich.

Nun habe ich für solche Zwischenfälle ja immer 2 voll lauffähige Linux-Systeme auf unterschiedlichen Partitionen installiert – also dachte ich mir: Kein Problem, dann bootest du halt das andere System und kümmerst dich von da aus um den Schaden (z.B. Fehler im Filesystem nach dem Crash) und dessen Ursachen. Aber da kam ich ganz genauso weit wie vorher – nämlich keinen Millimeter. Sprich: Das Laden des Kernels meiner zweiten Systemkonfiguration führte auch nicht zu einem ordentlichen Boot-Vorgang. Das war für mich dann schon ein ernstes Alarmsignal. Hier stimmte irgendetwas Grundlegendes nicht – und es war zumindest wahrscheinlich, dass das nichts mit einer defekten Partition zu tun hatte.

Also testweise ein dritter Anlauf: Konnte ich eigentlich noch ein neues System installieren ? Antwort: Nein! Auch der 64-Bit-Kernel, der von einer SUSE 11.2 initial für die Installationsphase geladen wurde, ließ sich nicht mehr installieren. Oh, oh, ….

Interessanterweise ware es aber noch möglich, das SuSE-Rettungssystem von der Installations-DVD zu starten und einige der wichtigen Ext3- und Ext4-Partitionen auf der Platte zu reparieren. Also Kernel in bestimmten Konfigurationen booteten doch ! Was sollte ich davon in meiner Verzweiflung halten? Hier denkt man zwangsläufig an ein Problem zwischen einem regulär parametrierten Kernel und dem Motherboard.

Nächster
Schritt: Ich versuchte, das installierte System in der “sicheren” Variante zu starten. Dabei werden dem Kernel etliche Zusatzparameter übergeben, die bestimmte Features abschalten. Durch systematische Verringerung der Aufruf-Parameter stellte sich dann heraus, dass die Option “nohz=off” entscheidend war. Das ist ein interessanter Paramter, denn er hat etwas mit der Taktung des Systems zu tun (Tickless Kernel). Siehe etwa

http://www.phoronix.com/scan.php?page=article&item=651&num=1
http://kerneltrap.org/node/6750

Umgekehrt habe ich dann ins BIOS gesehen und versucht herauszufinden, ob ich dort etwas verändern konnte, so dass das System wieder bootete. Der Schlüssel war hier letztlich das Deaktivieren der CPU EIST Funktion ((Enhanced Intel SpeedStep Technology). Auch das half, das usprüngliche System wieder zum Booten zu bewegen – auch ohne “nohz=off”. Nun könnte man denken, dass etwas an der CPU fehlerhaft gewesen sein könnte. Dem stand aber entgegen, dass bei einem Boot mit aktiviertem EIST und “nohz=off” das Speedstepping einwandfrei funktionierte.

Zuletzt ein Blick auf die am Board angezeigten Post Error Codes des BIOS. Dort tauchte ein CXX-Zustand auf, der in der POST-Tabelle von Gigabyte nicht verzeichnet war.

Was nun? Irgendwie kam der Kernel wohl nicht mehr mit der Hardware klar. BIOS defekt ? Falsche BIOS-Version ? Hoppla, tatsächlich, ich finde ja plötzlich statt der gewohnten F5i-Version die ältere Bios-Version F4 vor! (Dafür gäbe es immerhin die Erklärung, dass die “Dual-Bios”-Absicherungsfunktion des Boards im Crash aktiviert wurde.) Ich entschloss mich deshalb, das BIOS mit der aktuellen Version “5Fi” zu flashen und danach erneut auf die gewohnten alten Werte einzustellen. Ich habe allerdings den C4/C4E Support bislang noch nicht wieder aktiviert.

Und siehe da: Danach lief das System wieder – ohne spezielle Kernelparameter beim Booten und mit aktiviertem EIST. Die ganze vergangene Woche ohne jede Einschränkung.

Das Merkwürdige: Im Nachhinein waren für den Zeitraum vor dem Crash keine zugehörigen besonderen Log-Einträge im System auszumachen – weit und breit nicht.

Die offenen Fragen:

  1. Was um Himmels Willen löst einen solchen Crash im normalen Linux/KDE-Betrieb aus ? Gibt es ein Problem im Kernel oder liegt/lag einfach ein anderer Hardware-Defekt vor?
  2. Wieso war dabei das BIOS betroffen?
  3. Hat die übliche “Dual BIOS”-Absicherung des Gigabyte-Boards nach dem Crash tatsächlich automatisch ein Backup-Bios mit veränderten Einstellung in den Main-Bios-Chip eingespielt ?
  4. Führt die C4/C4E-Aktivierung im BIOS zu irgendwelchen Problemen im aktuellen Kernel ? (Mit dem F5i-BIOS kann ich damit booten!).
  5. Ist das “F5i”-BIOS notwendig, damit die aktuellen Kernel einwandfrei mit dem EP45T zusammenarbeiten?
  6. Kommt ein unbekannter Virus unter Linux als Ursache in Frage ? Bitte nicht; an sowas möcht eich wirklich nicht mal denken ….

Tja, auch unter Linux kann man also bislang ungeahnte Crash-Welten erforschen ….

Wenn ich mehr weiss, melde ich mich wieder …. Hinweise nehme ich gerne über E-Mail entgegen.

Mails im Ausland über deutsche SMTP-Server

Posted on by

Immer wieder begegnet man dem Problem, dass man bei Auslandsaufenthalten genötigt wird, für den Mailversand den SMTP-Server desjenigen Providers zu verwenden, an dessen Netzwerk man gerade angebunden ist. Ich stosse auf dieses Problem u.a. immer wieder in Norwegen (Telenor, Tele2) und Frankreich (Orange, France Telekom, Bouygues, Free(box)).

Die Provider filtern Zieladressen für eine SMTP-Kommunikation (Port 25), die sich nicht auf den Provider-eigenen SMTP-Server beziehen. Angeblich, weil man auf diesem Wege Spam-Probleme besser in den Griff bekommen will. Na ja, wer’s glauben mag ….

Das Problem ist der dadurch für den Anwender generierte Aufwand. In der Regel hat man den Mail-Client (MUA, bei mir Kmail) auf seinem Notebook/Laptop ja so vorkonfiguriert, dass als SMTP-Server in der Regel ein Server des hauseigenen deutschen Providers eingestellt ist.

[Es kann aber auch auf Laptops noch komplizierter sein – nämlich dann, wenn ein eigener SMTP-Server, evtl. sogar ein lokaler SMTP-Server auf dem Laptop mit einer Relay-Server-Anbindung die SMTP-Kommunikation handhabt (z.B. in Form eines lokalen Postfix MTA mit einem IMAP MDA wie Cyrus) ].

In jedem Fall aber ärgert man sich bei Auslandsreisen jedesmal über die Notwendigkeit einer Re- oder Zusatzkonfiguration des Mail-Clients oder aber anderer Mailkomponenten (wie Postfix).

Am Schluss schleppt man eine Liste ausländischer SMTP-Server in seinen Mail-Programmen herum, aus der man je nach Standort einen bestimmten Server als den aktuellen Standard definieren muss. Schon bei manchen MUAs ist das ein Thema, denn der Mailclient sollte dann so intelligent ist, mehrere account-übergreifende SMTP-Server verwalten zu können ….

Bei einigen der ausländischen Netze habe ich deshalb mal mit einigen Linux-Tools überprüft, ob tatsächlich nur der Port 25 gefiltert wird. Dies war der Fall. Da kommt man dann auf den Gedanken, ob nicht ein anderer Port den Zugang zum SMTP-Server eines meiner deutschen Provider ermöglichen würde.

Man denkt dabei an eine TLS/SSL-Anbindung – in Frage kommen die Ports 465 und 587.

Und ja, tatsächlich ist bei zweien meiner deutschen Provider entweder der Port 465 (SMTP via SSL) oder der Port 587 zugänglich. Einer der Provider verwendet 465 in Kombination mit SMTP-AUTH, beim Port 587 ist eine Authentifizierung sowieso zwingend vorgeschrieben. Auf dem Mail-Client müssen dann natürlich die notwendigen Einstellungen für eine SMTP-Authentifizierung vorgenommen werden – was bei Kmail kein Problem darstellt.

Eine Anbindung über einen der beiden Ports 465 oder 587 kann man natürlich auch aus dem Inland vornehmen. Damit ist dann die Chance gegeben, im Inland wie auch in vielen ausländischen Netzwerken seinen Mailversand über den gewohnten SMTP-Server seines Vertrauens abzuwickeln. Standortspezifische Einstellungen entfallen dann. (Nebenbei finde ich, dass nicht jeden Provider mein Mail-Gebaren etwas angeht).

Nach meinen Erfahrungen klappt das Verwenden der Alternativports mindestens mal in Norwegen und Frankreich bestens – gefiltert wird dort nur der Port 25. Natürlich muss aber auch der eigene deutsche Provider mitspielen und die genannten Ports anbieten …..

Es lohnt sich bei häufigen Auslandsaufenthalten aber wirklich, das abzufragen und seine Mailprogramme (einmalig) auf einen der Ports 465 opder 587 umzustellen. Viel Spaß nun beim Mailen im Ausland !

Links:

http://de.wikipedia.org/wiki/E-Mail-Programm
http://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
http://de.wikipedia.org/wiki/SMTPS
http://de.wikipedia.org/wiki/SMTP-Auth
http://forum.df.
eu/forum/showthread.php?t=49183

KDE 4.4, Kontact, Kmail und das Adressbuch

Posted on by

In einem Beitrag am 25.12.2009 hatte ich nach einer ersten Entäuschung geschrieben, dass man den Weg zu KDE 4.4 noch nicht im produktiven Umfeld beschreiten sollte. Inzwischen habe ich diese Zurückhaltung aufgegeben – ich setze KDE 4.4 nun produktiv ein und fühle mich in dieser Desktop-Umgebung in der täglichen Arbeit gut unterstützt.

Entsprechend habe vor kurzem einem Kollegen empfohlen, doch mal KDE 4.4 auszuprobieren. Er fand das auch gut, kam aber nicht mir der Einrichtung von Kontact/Kmail klar. Sein Kontact Adressbuch funktionierte zwar irgendwie, aber er konnte die Adressen nicht unter Kmail nutzen. Das verstehe ich gut, weil ich selber große Schwierigkeiten hatte, die aktuelle Philosophie für Kontacts Adressbuch nachzuvollziehen.

Daher auch an andere Interessierte oder Betroffene zwei Hinweise:

1) Das “Default Adress Book” unter “Kontakte” ist nicht das “Default Adressbook” unter “Kmail” !

Ich habe das aktuelle Vorgehen der KDE-Entwicklung aus einem Forum-Dialog wie folgt verstanden: Offenbar gibt es den Plan, in der Zukunft diverse Ressourcen des KDE-Desktops über einen lokalen Akonadi-Server bereitzustellen. Um sich systematisch an das Thema heranzutasten, wurde Kontacts Adressbuch als erste Applikation auf Akonadi umgestellt. Das, was man als Unbedarfter dann erwartet, ist natürlich, dass das “neue” Akonadi-basierte Adressbuch auch unter Kmail genutzt werden kann.

Nun, da irrt man. Das Akonadi-basierte “Default Adressbook” im Adressbereich von Kontact ist im Moment (!) keineswegs ein Adressbuch, welches von anderen Kontact-Applikationen genutzt werden würde oder könnte – auch wenn unter Kmail in diversen Dialogfenstern ein “Default Adress Book” aufgeführt wird.

Wenn ich das richtig sehe, so ist das Akonadi-basierte Adressbuch zur Zeit das Ergebnis eines ersten Test- und Übungsbeispiels für die KDE-Entwickler – das verwirrende Resultat für den normalen Anwender ist bislang eine “stand alone”-Lösung, die im Kontakte-Bereich von Kontact als (sinnentleerte?) Zugabe herumgeistert. Dieses Adressbuch wird im PIM nicht von anderen Applikationen benutzt !

So ist es auch kein Wunder, dass mein Freund und ich verzweifelt, aber vergeblich Testeinträge im Adressbuch anlegten, um dann herauszufinden, dass diese unter Kmail (z.B. im Rahmen der automatischen Adress-Vervollständigung) nicht angezeigt werden – obwohl sie natürlich in voller Schönheit im Adressbuch-Bereich such-, sicht- und editierbar sind. Da half und hilft kein Rumprobieren an den Einstellungen des Kmail-Editors oder das Verändern der Adressbuch-Reihenfolge – das unter diversen Kmail erwähnte “Default Adress Book” hat halt leider rein gar nix mehr mit dem im Adressbuch-Bereich angelegte “Default Adress Book” zu tun.

Liebe KDE-Truppe, der/die dafür Verantwortliche sollte wissen, dass sich das einem Anwender wahrlich nicht erschließt. Mit einer solchen Idee rechnet man schlicht nicht – ich selbst konnte es nach Jahren KDE-Verwendung auch überhaupt nicht glauben und habe das Ganze erst nach mehrmaligem Lesen eines Dialogs zwischen einem frustrierten Anwender mit einem KDE-Entwickler begriffen. Wenn man die User beim Umstieg auf KDE 4.4 verwirren wollte – dann wurde dieses Ziel in preisverdächtiger Weise erreicht.

Als fehlersuchender KDE-Anwender experimentiert ja man nicht nur mit Kontact-Einstellungen herum – nein, man wirft natürlich auch einen Blick auf den Akonadi-Server und die dort erscheinenden Ressourcen. Dieser Ausflug in eine bislang unerforschte Welt war natürlich hochinteressant – aber er nutzt einem bzgl. des Kmail-Problems nichts. Unter Akonadi erschien bei mir alles fehlerfrei – sprich der Akonadi-Server lief anstandslos und die Adressbuch-Ressource wurde auch angezeigt. Nur unter Kmail ließen sich die Adressen halt nicht verwenden.

Übrigens: Falls man bei der Einrichtung von Akonadi Probleme
haben sollte, hilft vielleicht Folgendes:

a) Virtuoso installieren

b) Bzgl. der Desktop-Suchmaschine Nepomuk folgenden Eintrag in der Datei “~/.kde4/share/config/nepomukserverrc” prüfen:

[main Settings]
Maximum memory=50
Storage Dir[$e]=$HOME/.kde4/share/apps/nepomuk/repository/main/
Used Soprano Backend=virtuosobackend

c) Ggf. “~/.config/akonadi/akonadiserverrc” löschen und den Akonadiserver über die Akonadi-Einrichtung neu starten

2) Lösung: Ignoriere im Moment das Akonadi-basierte Adressbuch und richte ein konventionelles Adressbuch unter Kontakt und ggf. auch unter KDE ein!

Hat man die obige “Philosophie” erst einmal verdaut, ist natürlich der Weg zur Lösung nicht weit. Man muss in Kontacts Adressbuch-Bereich (und ggf. unter den KDE-Ressourcen; s.u. den Hinweis vom 25.06.2010) einfach ein weiteres “Standard”-Adressbuch einrichten.

Zum Einrichtungs-Dialog für ein neues Adressbuch kommt man durch einen Klick mit der rechten Maustaste in den Seitenbereich “Adressbücher” unter “Kontakte”. Im erscheinenden Kontextmenü wählt man dann “Adressbuch hinzufügen”. In der nachfolgenden Auswahl schließlich “KDE-Adressbuch (herkömmlich)”. Es erscheint erneut ein Auswahldialog – hier muss man die für sich richtige Ressource anklicken. In meinem Fall ist das ein Adressbuch eines Open-Xchange-Servers, für das man dann die Verbindungsdaten wie in früheren Kontact-Versionen auch einträgt:

Adresse: http://my-OX-Server
User: my_user_name
Passwort: my_password

Danach Auswahl des OX-Adressbuch-Verzeichnisses – z.B. des globalen Adressbuches unter den OX-Systemordnern. Dieses so angelegte Adressbuch erscheint dann übrigens auch als Akonadi-Ressource – was einem unter Kmail aber leider nichts nutzt. ..

*******Wichtige Ergänzung vom 25.06.2010: *******
In der bei mir aktuellen Version (Kontact 4.4.5 und KMail 1.13.5) aus dem Factory-Repository von SUSE reicht der eben beschriebene Schritt unter “Kontakte” leider nicht (mehr?) aus, um die Ressource auch im KMail-Bereich verfügbar zu machen (z.B. für die automatische Adressvervollständigung). Vielmehr muss man die Adressbuch-Ressource nochmals manuell anlegen – und zwar in den KDE- “Systemeinstellungen” als allgemeine KDE-Ressource:

Entweder im KDE-Menü “Systemeinstellungen” starten oder in einem Terminalfenster “system-settings &” eingeben. Dort den Reiter “Erweitert” betätigen und dann den Eintrag “KDE-Ressourcen” wählen. Mit Hilfe der Auswahl-Combobox die Kategorie “Kontakte” einstellen. Prüfen, ob die gewünschte Adressbuch-Ressource schon als Eintrag vorhanden ist. Wenn – wie bei mir – nicht: “Hinzufügen” anklicken und in den folgenden Dialogen zum Hinzufügen einer Ressource die gleichen Schritte vornehmen, die oben für den “Kontakte”-Bereich von “Kontact” beschrieben wurden.

Im aktuellen Zustand von Kontact führt das Anlegen einer (herkömmlichen) Adressbuch-Ressource unter “Kontakte” offenbar nicht mehr zu den notwendigen KDE-Einträgen für die Ressourcen, die dann von KMail aufgegriffen werden. Was denkt der normale Anwender: Schade eigentlich … und regt sich am besten nicht auf ….
****** Ende Ergänzung 25.06.2010 *******

Hinweis: Für ein lokales Adressbuch sollte die zugehörige Datei übrigens auf

/home/user_xyz/.kde4/share/apps/kabc/std.vcf

verweisen, wenn das vcf-Format gewählt wurde.

Die so angelegten (herkömmlichen) Adressbücher werden schließlich auch unter Kmail erkannt und an den gewohnten Stellen aufgelistet. Der Adressbuch-Inhalt wird auch wie gewohnt in der automatischen Adress-Suche und -Vervollständigung beim Verfassen von Mails herangezogen. Die Reihenfolge, in der die “herkömmlichen” Adressbücher dabei verwendet werden sollen, legt man mit den üblichen Dialogen, z.B.
“Einstellungen – Kmail einrichten – E-Mail-Editor –
Vervollständigungsreihenfolge einstellen ….”,
fest. Alles wie gehabt. Ich kann seitdem wieder normal arbeiten.

Links

Einen Sinn hatte das ganze Theater aber doch: Man fängt an, sich für Akonadi zu interessieren. Als Einstieg hier ein paar Links:

http://de.wikipedia.org/wiki/Akonadi
http://pim.kde.org/akonadi/
http://userbase.kde.org/Akonadi

Schön ist übrigens die Einleitung zur UserBase (mit Hinweisen zur Fehlerbehebung):

“This page is mainly concerned with troubleshooting Akonadi, as there are inevitable glitches in early stages of migration. For many people the first signs of Akonadi activity will be in KDE SC 4.4, and many will be confused by it. ”

Oh, yes !