Hallo Tom, Am Mittwoch, 23. April 2003 21:33 schrieb Tom Walter:
enttäuschte Grüsse (nicht von Euch hier in der Liste, sondern vom Suse-Support), Tom
Dem kann ich nur beipflichten, absolut enttäuschend. Ich bin jetzt schon seit Tagen am testen. Selbst über lprng funktioniert es nicht richtig. Der Ausdruck wird abgebrochen, der Drucker falsch angesprochen oder er gibt garnichts von sich. Unter 8.1 hatte ich Turboprint genutzt, geht jetzt auch nicht mehr. Turboprint kann den Drucker nicht mehr ansteuern. Ohne anständige Software wie Turboprint kann ich aber keine Justierung des Druckers durchführen. Suse hat mir vor zwei Tagen folgendes geschrieben, vielleicht hilft Dir es ja weiter:
Sehr geehrter Herr Konietzke,
vielen Dank für Ihre Anfrage an den SuSE Installationssupport.
Ihre Anfrage geht eigentlich über den Installationssupport hinaus. Dieser ist in erster Linie als Hilfe zur grundlegenden Einrichtung eines lauffähigen Systems gedacht. Wir bitten um Ihr Verständnis, daß wir fortgeschrittene Themen wie Sie sie ansprechen, nicht erschöpfend beantworten können.
Beim ersten Start des CUPS-Server wir eine Datenbank mit 3000 Einträgen initialiesiert. Dieser Prozess verbraucht sehr viele Resourcen. Wenn es zu einem Abbruch während der Initialisierung kommt, dann ist das ein Zeichen für problematische Hardware bzw. problematische BIOS-Einstellungen.
Führen Sie zunächst den "Memory Test" aus um sicher zu stellen, dass kein defekt am Speicher vorliegt. Lassen Sie diesen Test mehrere Stunden laufen.
Habe ich gemacht, 10 Stunden am Stück, und alles in Ordnung.
Alternativ können Sie auch im laufenden System die Stabilität prüfen.
In unserer Supportdatenbank http://sdb.suse.de/ finden Sie dazu den nachfolgenden Artikel mit dem Stichwort 'sig11'.
-->8-- Titel: Überprüfung der System-Stabilität
http://sdb.suse.de/de/sdb/html/hmeyer_memtest-sig11.html _______________________________________________________
Anliegen
Sie möchten sicher gehen, dass Ihre Hardware unter Linux stabil läuft.
Vorgehen
Vorausgesetzt Sie haben die Kernelquellen und die benötigten Entwicklungswerkzeuge (Compiler usw.) installiert, können Sie mit dem folgenden kleinen Skript die Systemstabilität sehr gut überprüfen:
#!/bin/bash # # Adapted from http://www.bitwizard.nl/sig11 # #set -x
cd /usr/src/linux
t=1 while [ -f log.$t ] do t=`expr $t + 1` done
if [ ! -r .config ]; then echo -e echo -e "There was no .config file found in /usr/src/linux ." echo -e "This means that the kernel sources have not been configure d yet." echo -e "If you continue \"make cloneconfig\" will be executed to c reate" echo -e "a kernel configuration based on the currently running kern el." echo -e "\n" echo -e "Press <Ctrl>-<C> to abort or <ENTER> to continue ..." read make cloneconfig fi
touch log.1 watch "ls -lt log.*" &
while true do make clean &> /dev/null make -k bzImage > log.$t 2> /dev/null t=`expr $t + 1` done
Das Original dieses Skripts finden Sie unter http://www.bitwizard.nl/sig11. Dort wird auch der Hintergrund dieses Tests erläutert.
Vorteile dieser Überprüfung gegenüber anderen Methoden (z.B. memtest86) sind
1. Das gesamte System wird gestestet, nicht nur der Arbeitspeicher 2. Der Betrieb des Systems muss für diesen Test nicht unterbrochen werden
Das Skript lässt in einer Endlosschleife die Kernelquellen übersetzen (make bzimage) und speichert die Ausgabe von make für jeden Durchlauf in einer eigenen Logdatei (die übrigens recht groß wird).
Normalerweise wäre zu erwarten, dass der make Prozess bei jedem Durchlauf exakt die gleichen Ausgaben erzeugt.
Das Skript zeigt während es läuft einen ständig aktualisierten Blick auf
ls -l /usr/src/linux/log.*
Das könnte z.B. so aussehen:
Every 2s: ls -lt log.* Wed Aug 8 15:22:02 2001 -rw-r--r-- 1 root root 5472 Aug 8 15:22 log.4 -rw-r--r-- 1 root root 127120 Aug 8 15:21 log.3 -rw-r--r-- 1 root root 127120 Aug 8 15:12 log.2 -rw-r--r-- 1 root root 127120 Aug 8 15:04 log.1
In diesem Beispiel sind die ersten drei Durchläufe bereits abgeschlossen. Dass sich die Dateigröße der ersten drei Log-Dateien nicht unterscheidet ist bereits ein gutes Zeichen. Wer sicher gehen will sollte das Skript allerdings bis zu 24 Stunden laufen lassen und sich nicht nur auf die Dateigröße verlassen. Mit md5sum steht ein geeignetes Werkzeug zur Verfügung um zu überprüfen, ob die Logdateien tatsächlich identisch sind:
linux:/usr/src/linux # md5sum log.* 51e25c01370ce034b2c00d4c71995f02 log.1 51e25c01370ce034b2c00d4c71995f02 log.2 51e25c01370ce034b2c00d4c71995f02 log.3 a014cc76b1fb46a3cc5b84484403a1b7 log.4
Dass die vierte Logdatei eine unterschiedliche Prüfsumme ergibt muss nicht wundern, da dieser Durchlauf noch nicht abgeschloosen ist. Die Prüfsummen der bereits abgeschlossenen Durchläufe sollte allerdings identisch sein.
Anmerkung: Unter bestimmten Umständen kann es vorkommen, dass der erste Durchlauf ein leicht unterschiedliches Resultat im Vergleich zu den weiteren Durchläufen liefert. Als Faustregel kann also gelten, dass alle Durchläufe mit Ausnahme des ersten und des letzten (noch nicht abgeschlossen) identische Ergebnisse liefern müssen. --8<--
Habe ich auch gemacht, fast 20 Stunden lang, und auch alles in Ordnung.
Dann gilt es noch das BIOS zu prüfen. Verwenden Sie die Werkseinstellungen des BIOS und achten Sie darauf, dass die Option "Plug and Play OS installed" o.ä. deaktiviert ist.
BIOS auch geprüft, an der LPT Schnittstelle geändert und geändert, und - hat nichts gebracht. Tja, nun ist guter Rat - hoffentlich nicht - teuer ;-) Jetzt werde ich wohl die 8.1 wieder aus dem Keller holen müssen. Ohne Drucker ist die Kiste nicht zu gebrauchen. Vielleicht werde ich mich mal an den Kernel machen und versuchen ein selbst zu basteln. Sollte jemand einen Tipp haben, bitte helft. Gruß Harry