Hallo,
nun verwende ich openSuSE-11.2. Es läuft gut.
Mir fällt nur die Meldung während des Bootens auf, dass
/etc/init.d/boot.startpreload das hier aufgerufene
/usr/bin staprun, das dort existiert, nicht finde.
Ich habe in boot.startpreload statt "staprun" "/usr/bin/staprun"
geschrieben. Dennoch wird es nicht gefunden.
Was hat es damit auf sich?
Werner.
poste die EXAKTE Fehlermeldung.
Das kann alles nicht sein.......
Zitat von }ls{;11277poste die EXAKTE Fehlermeldung.
Ja, aber wie? Die Meldung fliegt rasch während der ersten Schritte des Bootens
vorbei, ohne dass ich hiervon irgendwo in /var/log/ etwas finde.
Die Meldung steht am Ende eines ersten Blockes, der mit einer Leerzeile endet.
Hier heißt es etwa:
/etc/init.d/boot.startpreload: line 44: staprun No such file or directory
Nach der darauf folgenden Leerzeile folgt: "starting udev".
Wie oben schon gesagt, habe ich in /etc/init.d/boot.startpreload staprun durch
den ganzen Pfad ersetzt, und somit heißt es jetzt:
/etc/init.d/boot.startpreload: line 44: /usr/bin/staprun No such file or directory
Hallo,
"staprun" ist Inhalt des Paketes "systemtap". Hast du "systemtap" installiert? Vielleicht hilft eine Deinstallation oder Neuinstallation, um die Nörgelei zu beenden. Aber brauchst du das wirklich? "SystemTap" ist ein Tracing- und Debugging-Framework.
Zitat
SystemTap erlaubt die detaillierte Analyse von Kernel und Anwendungen zur Laufzeit, ohne dass der Kernel oder die untersuchte Anwendung dazu speziell gepatcht werden müssen. Das Framework stellt über eine Vielzahl von Messfühlern Ereignisse bereit, an die mit Hilfe einer Skriptsprache Funktionen gekoppelt werden können. Damit ist es beispielsweise möglich, beim Aufruf einer bestimmten Kernelfunktion die Funktionsparameter ausgeben zu lassen.
Thomas
Edit: Ich vermute, dass es im Bootmoment zur Fehleranalyse des Kernels dient. Unklar ist, ob es unverzichtbarbar ist. Schau also bei einem Deinstallationsversuch genau auf die eventuellen Warnungen.
Zitat von tf.bb;11343
"staprun" ist Inhalt des Paketes "systemtap". Hast du "systemtap" installiert?
Ja, es wurde bei der Original-Installation installiert.
Zitat
Vielleicht hilft eine Deinstallation oder Neuinstallation, um die Nörgelei zu
beenden.
Du meinst wohl nur "systemtap" und nicht das ganze openSuSE-11.2
Ich habe "systemtap" per YaST neu installiert, was natürlich rein nichts
brachte.
Zitat
Aber brauchst du das wirklich? "SystemTap" ist ein Tracing- und Debugging-Framework.
Nein, ich brauche das nicht. Es hat mich nur neugierig gemacht, was das nun
bei 11.2 soll. 11.2 läuft, bis auf einige unbedeutende Probleme, bei mir einwand-
frei.
Zitat
Edit: Ich vermute, dass es im Bootmoment zur Fehleranalyse des Kernels dient. Unklar
ist, ob es unverzichtbarbar ist. Schau also bei einem Deinstallationsversuch genau auf
die eventuellen Warnungen.
Ich habe versuchsweise "systemtap" und "systemtap-runtime" deinstalliert.
Klar, dass "boot.startpreload" das Fehlen moniert. Die Wiederinstallation beider
brachte dennoch keine Besserung.
Übrigens hat 11.2 mehrere solche Merkwürdigkeiten:
http://groups.google.com/group…6cc9c399ce?lnk=raot&pli=1
Dank für die Information. Jetzt weiß ich wenigstens, was das soll.
Werner.
Probleme solcher Art ziehen sich im Moment durch alle Distri's. Nicht nur ich bin der Meinung, dass der aktuelle Kernel an dieser Misere nicht ganz unschuldig ist.
Thomas
Hallo,
hätte mich schon früher gemeldet, aber ich musste mich erst registrieren & aktivieren. Das habe ich leider erst jetzt fertig bekommen.
Also: die Sache ist ein Bug, siehe hier: https://bugzilla.novell.com/show_bug.cgi?id=531183. Voraussetzung: du hast - wie ich - den Pfad /usr in eine eigene Partition installiert - wenn nicht, weitersuchen, dann passt dieses hier nicht für deinen Fall.
Wenn doch: ich sehe keine Lösung. Ich habs probiert, indem ich staprun von /usr/bin nach /bin und die benötigten shared libs nach /lib64 kopiert habe. Dann kommt staprun zwar selbst zum Laufen, aber gleich danach die nächste Fehlermeldung. Da soll nämlich ein Programm namen stapio gestartet werden, das wird aber auch unter /usr erwartet. Und das noch passend hinzukriegen, sodass boot.startpreload glücklich ist ... ich habs noch nicht probiert, weil ich auch nicht sicher bin, obs überhaupt geht.
Mögliche Optionen: (1) ignorieren, bei mir läufts auch so (aber vielleicht etwas landsamer als üblich, s.u.). (2) Neu installieren und /usr _nicht_ in eine eigene Partition packen. (3) Abwarten, obs einen Bugfix gibt
Zum Zeck des Pakets: ich glaube, dass hier versucht wird, vorab zu ladende Module während des Bootens zu ermitteln (-> "preload"). Dazu passt, dass passend zu boot.startpreload ein weiteres Init-Skript names stoppreload existiert, das nämlich das oben erwähnte stapio wieder beendet und dessen Ausgabe verarbeitet. Aber genaueres muss ich noch erforschen.
