[gelöst] init 5 wird ab und an nicht erreicht

[agrupe]

Moin moin,

seit ein paar Wochen stockt der Bootprozess beim Erreichen von Level5 ab und an. Fehlermeldung: Failed service in runlevel 5: earlysyslog.

Ich kann mich dann auf der shell als root einloggen, reboote das System und alles läuft danach ein paar Tage lang (in denen ich das System mehrmals täglich problemlos boote). Irgendwann hängt der Boot dann erneut.

Habt ihr eine Idee? Ich würde nur ungern neu installieren, da der Rechner sonst echt prima läuft.

Danke & Gruß aus Hannover

Andreas
OpenSuse 11.3, KDE 4

 

[spoensche]

Was sagen die Logfiles?

 

[agrupe]

Ich bin mir nicht im klaren, ob das Logfile, dass ich gerade sehe, wo das System problemlos gebootet hat, Aufschluss gibt.

Die einzige Fehlermeldung, die ich zur Zeit sehen kann ist die, dass mein alten Mountpunkt für (jetzt nicht mehr verwendete) Festplatten fehlt. Und scheinbar kommt die Fehlermeldung mit dem earlysyslog immer :

exportfs: Warning: /mnt/data/ does not exist
mountd statd nfsd sm-notifydone
<notice -- Sep 19 17:42:25.91990000> service dhcpd doneStarting ISC DHCPv4 4.x Server grep: /proc/3364/cmdline: No such file or directory
[chroot]done
Starting service MySQL
<notice -- Sep 19 17:42:27.235839000> service mysql donedone
<notice -- Sep 19 17:42:27.236071000> service stoppreload start<notice -- Sep 19 17:42:27.248150000> service stoppreload donedone
Master Resource Control: runlevel 5 has been reached
Failed services in runlevel 5: earlysyslog
<notice -- Sep 19 17:42:27.256621000> killproc: kill(1265,3)


Soll ich mal das gesamte (sehr lange) Logfile posten?

Gruß

Andreas

 

[josef-wien]

Ich bin mir nicht im klaren, ob das Logfile, dass ich gerade sehe, wo das System problemlos gebootet hat, Aufschluss gibt.

Hinsichtlich Deines Problems lautet die Antwort "nein". Beim nächsten Vorkommen würde ich mich einmal als Benutzer anmelden und startx ausführen, um zu sehen, ob es ein Problem mit dem grafischen System ist. In /var/log/boot.msg ist der aktuelle Boot-Vorgang dokumentiert, der vorhergehende Boot-Vorgang ist in /var/log/boot.omsg ersichtlich.

Und scheinbar kommt die Fehlermeldung mit dem earlysyslog immer

Du kannst schauen, ob zwischen service earlysyslog start und service earlysyslog failed etwas zu finden ist. Einen Zusammenhang mit Deinem Problem sehe ich nicht. Welcher Syslog-Dämon ist bei Dir im Einsatz:

ls /var/run/*syslog*.pid

 

[agrupe]

Hatte gerade mal wieder einen "Hänger" beim Erreichen von level5.

Nach dem Einloggen und "startx" lief das System dann völlig problemlos hoch.

Ich habe mir vorher die /var/log/boot.msg kopiert, sodass ich jetzt die Fehlermeldungen habe. Ohne hier alles zu posten fiel mir auf:

service earlysyslog doneStarting syslog services/sbin/syslog-ng: error while loading shared libraries: libevtlog.so.0: cannot open shared object file: No such file or directory

service mysql doneStarting service MySQL chmod: cannot access `/var/run/mysql/mysqld.pid': No such file or directory

und zum Schluss:

Master Resource Control: runlevel 5 has been reached
Failed services in runlevel 5: earlysyslog mysql
<notice -- Sep 20 18:37:19.840463000> killproc: kill(1252,3)

Ich deaktiviere jetzt mal mysql.

Das Kommando ls /var/run/*syslog*.pid führt zu keinem Ergebnis. Daher:

ls /var/run/*sys*
ergibt:
/var/run/syslog-ng:
additional-log-sockets.conf

/var/run/systemtap:

Gruß

Andreas

 

[josef-wien]

Ich habe mir vorher die /var/log/boot.msg kopiert

"Vorher" nützt nichts, wir brauchen die Datei, die nach dem erfolgreichen startx vorhanden war.

error while loading shared libraries: libevtlog.so.0

Das würde ja bedeuten, daß das Paket libevtlog0 fehlt, und ohne dieses Paket sollte sich syslog-ng nicht installieren lassen. Ist dieses Paket installiert bzw. gibt es die Verknüpfung /lib[64]/libevtlog.so.0 und die Datei /lib[64]/libevtlog.so.0.0.0?

Das Kommando ls /var/run/*syslog*.pid führt zu keinem Ergebnis.

Als Laie wundere ich mich, aber mein Wissen über syslog-ng (der bei mir auch unter 11.3 problemlos läuft) ist eher als nicht vorhanden zu bezeichnen.

 

[agrupe]

"Vorher" nützt nichts, wir brauchen die Datei, die nach dem erfolgreichen startx vorhanden war.

OK, mache ich nächstes Mal. Ich habe gedacht, die Fehlermeldungen vor dem X-Start wären wichtig.

gibt es die Verknüpfung /lib[64]/libevtlog.so.0 und die Datei /lib[64]/libevtlog.so.0.0.0?

Nö,scheinbar nicht:
ls /lib/libevt*
ls: Zugriff auf /lib/libevt* nicht möglich: Datei oder Verzeichnis nicht gefunden

Habe gerade in yast nachgeschaut und die libevtlog0 ist tatsächlich nicht installiert. Das mache ich jetzt mal. Aus der Paketbeschreibung geht aber nicht hervor, in welchem ursächlichen Zusammenhang das mit dem stoppen der Services beim booten stehen könnte.

Danke für die bisherige Unterstützung!

Andreas

 

[Geier0815]

Warum fällt mir gerade eine Parallele zu diesem Thread auf? Mag jetzt erst einmal nichts mit deinem Problem zu tun haben aber es sieht für mich so aus als würde mysql derzeit ziemlich viel Ärger verursachen.

 

[agrupe]

Habe gestern Mysql deaktiviert. Mal sehen, ob das was mit dem Problem zu tun hatte. Bislang startet das System; das sagt aber noch nix endgültiges ;-(

 

[agrupe]

Hi,

ich bins wieder ;-)

Nachdem nun eine Zeit lang alles lief, brach der Bootprozess heute wieder ab. Danach als User eingeloggt, startx durchgeführt - geht alles. Dann habe ich die /var/log/boot.msg gespeichert. Danach neu gestartet und das System läuft problemlos hoch. Da staunt der Laie und der Fachmann wunder sich ...

In der Logdatei steht übehaupt nichts problematisches drin. Sie endet so:

notice -- Sep 25 16:36:44.811909000> service dhcpd done[chroot]done
<notice -- Sep 25 16:36:44.812199000> service stoppreload startdone
<notice -- Sep 25 16:36:44.825112000> service stoppreload doneMaster Resource Control: runlevel 5 has been reached
<notice -- Sep 25 16:36:44.828774000> killproc: kill(1279,3)

libevtlog habe ich installiert:

ls /var/run/*syslog*.pid gibt nun das Ergebnis:
/var/run/syslog-ng.pid

Bin nach wie vor ratlos ...

Gruß

Andreas

 

[josef-wien]

Wenn boot.msg nichts verrät (es müßte zwischen service earlyxdm start und service xdm done sein), dann schau Dir beim nächsten Mal Xorg.0.log.old an (Xorg.0.log stammt bereits vom erfolgreichen X-Start). Auch in kdm.log könnte etwas stehen (dort gibt es für jeden X-Start ein paar Zeilen, darunter sogar eine Zeile mit Datum und Uhrzeit), aber ob es zur Fehlerfindung reicht?

 

[agrupe]

Also - den angesprochenen Teil des boot.msg habe ich hier mal kopiert, da ich kein Profi bin, siehst du ja vielleicht od das so ist, wie es sein sollte:

service earlyxdm startLoading CPUFreq modules
<notice -- Sep 25 16:36:27.843602000> startproc: execve (/opt/kde3/bin/kdm) [ /opt/kde3/bin/kdm ], [ DO_FASTBOOT=no CONSOLE=/dev/console ROOTFS_FSTYPE=ext3 TERM=linux SHELL=/bin/sh ROOTFS_FSCK=0 INIT_VERSION=sysvinit-2.88 DO_BLOGD=yes KDEROOTHOME=/root/.kdm REDIRECT=/dev/char/../tty1 COLUMNS=124 PATH=/bin:/sbin:/usr/bin:/usr/sbin DO_CONFIRM=no vga=0x317 RUNLEVEL=5 SPLASHCFG=/etc/bootsplash/themes/openSUSE/config/bootsplash-1024x768.cfg PWD=/ DO_QUIET=no LANG=de_DE.UTF-8 PREVLEVEL=N LINES=44 QT_SYSTEM_DIR=/usr/share/desktop-data SHLVL=2 HOME=/ XCURSOR_THEME=DMZ DO_FORCEFSCK=no WINDOWMANAGER= SPLASH=yes splash=silent ROOTFS_BLKDEV=/dev/disk/by-id/scsi-SATA_Hitachi_HDP7250_GEC534RF2RZYJE-part1 _=/sbin/startproc DAEMON=/opt/kde3/bin/kdm ]
<notice -- Sep 25 16:36:27.869636000> service earlyxdm done

Die anderen Files schaue ich mir beim nächsten Boot-hänger an. Momentan läuft mal wieder alles. Da der Fehle ja nur sporadisch auftaucht, bin ich mittlerweile fast so weit, an ein HW Problem zu glauben. Warum sollte sich der Bootprozess selbständig ändern?

Gruß

Andreas

 

[josef-wien]

Ich habe einmal einen fehlerhaften X-Start provoziert und daraufhin den ersten Satz meines gestrigen Beitrags angepaßt. In boot.msg steht diebezüglich nichts, also müssen kdm.log und Xorg.0.log.old herhalten.

an ein HW Problem zu glauben

Meine Gedanken gehen eher zu einer fehlenden Abhängigkeit, die hin und wieder dazu führt, daß eine Voraussetzung fehlt (der HAL-Dämon könnte ein Kandidat sein). Wie sehen die beim fehlerhaften X-Start erzeugten Zeilen in kdm.log aus?

 

[agrupe]

Ok, bin kurz vor dem Aufgeben ;-(

Also - nach dem letzten Boothänger habe ich die kdm.log mal angesehen.

Alle Einträge sind identisch bis auf die letzte Zeile. Bei normalem Start steht dort

Driver not XRANDR 1.2 capable, ignoring DISPLAYMANAGER_RANDR_MODE_* settings

Diese Zeile fehlt wenn die grafische Oberfläche nicht gestartet wird und der Bootprozess auf der Shellebene hängen bleibt.

In der Xorg.0.log sieht alles gut aus.
Könnte das Problem aus einem instabilen Nvidia Treiber resukltieren?

(II) LoadModule: "nvidia"
[ 18.751] (II) Loading /usr/lib/xorg/modules/updates/drivers/nvidia_drv.so
[ 18.751] (II) Module nvidia: vendor="NVIDIA Corporation"
[ 18.751] compiled for 4.0.2, module version = 1.0.0
[ 18.751] Module class: X.Org Video Driver
[ 19.630] (II) NVIDIA dlloader X Driver 256.35 Wed Jun 16 18:59:34 PDT 2010
[ 19.630] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[ 19.630] (++) using VT number 7

Irgendwo habe ich mal gelesen, dass es offene und properitäre Treiber gibt. Ich weiss allerdings nicht, welche mein System benutzt.

Gruß

Andreas

 

[josef-wien]

Ok, bin kurz vor dem Aufgeben ;-(

Bei dem Inhalt der Log-Dateien kann ich das verstehen.

Irgendwo habe ich mal gelesen, dass es offene und properitäre Treiber gibt. Ich weiss allerdings nicht, welche mein System benutzt.

Module nvidia: vendor="NVIDIA Corporation"

Bei Deinem Problem müssen Leute her, die sich mit Nvidia-Grafikkarten auskennen. Dazu solltest Du folgende Informationen liefern:

rpm -qa | grep nvidia
uname -ri
/usr/sbin/hwinfo --gfx

 

[agrupe]

Ok,

mal sehen, ob jemand das hier findet - ggf poste ich das Problem noch mal in einem anderen Bereich bezogen auf die GraKa.

rpm -qa | grep nvidia
x11-video-nvidiaG02-256.35-15.1.i586
nvidia-gfxG02-kmp-desktop-256.35_k2.6.34.0_12-14.1.i586

uname -ri
2.6.34-12-desktop i386

/usr/sbin/hwinfo --gfx
34: PCI 200.0: 0300 VGA compatible controller (VGA)
[Created at pci.318]
Unique ID: B35A.HHeSU3mlqdB
Parent ID: gZD2.KQxUGMM+us2
SysFS ID: /devices/pci0000:00/0000:00:0b.0/0000:02:00.0
SysFS BusID: 0000:02:00.0
Hardware Class: graphics card
Model: "nVidia GeForce GTS 250"
Vendor: pci 0x10de "nVidia Corporation"
Device: pci 0x0615 "GeForce GTS 250"
SubVendor: pci 0x196e
SubDevice: pci 0x0593
Revision: 0xa2
Driver: "nvidia"
Driver Modules: "nvidia"
Memory Range: 0xfd000000-0xfdffffff (rw,non-prefetchable)
Memory Range: 0xd0000000-0xdfffffff (ro,non-prefetchable)
Memory Range: 0xfa000000-0xfbffffff (rw,non-prefetchable)
I/O Ports: 0xdf80-0xdfff (rw)
Memory Range: 0xfcfe0000-0xfcffffff (ro,non-prefetchable,disabled)
IRQ: 18 (711781 events)
I/O Ports: 0x3c0-0x3df (rw)
Module Alias: "pci:v000010DEd00000615sv0000196Esd00000593bc03sc00i00"
Driver Info #0:
XFree86 v4 Server Module: nvidia
Driver Info #1:
XFree86 v4 Server Module: nvidia
3D Support: yes
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #28 (PCI bridge)

Primary display adapter: #34

Danke auf jeden fall für deine Hilfe!

Andreas

 

[josef-wien]

Wie ich sehe, verwendest Du den Erstauslieferungs-Kernel von openSUSE 11.3. Du solltest ein Update auf die aktuelle Kernel-Version 2.6.34.7-0.3-desktop vornehmen (und wenn Du Glück hast, löst sich Dein Problem).

 

[agrupe]

Also - ich glaube, das Thema ist gelöst. Es lag nicht am Update sondern (wahrscheinlich) am NFS Client. Ich hatte unter 11.3 schon die merkwürdigsten Fehler auf meinem Notebook mit per NFS gemounteten Filesystemen, die ich bislang knm in die Schuhe geschoben hatte. Hier - ohne knm - habe ich mein NAS abgeklemmt, die NFS mounts entfernt und seit dem bootet der Rechner wie frisch aufgesetzt.

Gruß

Andreas

 

[agrupe]

Ok, seit etwas mehr als hundert Bootvorgängen klapprt alles reibungslos. Thema ist erledigt; es lag am NFS.

Gruß

Andreas