Hallo allerseits,
nach einen Update (YOU und SuSE Supplementary’s von KDE, GNOME, misc und Pacman) hängt ein neu aufgesetztes Notebooks (i386) beim Booten. Mein Desktop (x86-64) läuft aber mit gleichen Updatestand läuft aber ohne Probleme.
Nach einem starten der Notebooks im Runlevel 3 (Bootparameter init 3) bootet der Rechner fehlerfrei bis zur Kommandozeile. Ein anschließendes init 5 bleibt aber genau so hängen (nach dem ermitteln des aktuellen Runlevels). Nach ausgiebigen suchen in meinen LOGs (z.B. via dmesg) und auch die Kontrollausgabe des Initscripts bringt mich nicht weiter. Eine Internet Recherche hat auch nichts produktives erbracht.
Für mich stellt sich nun die Frage wie man den init Befehl gesprächiger macht. Bzw. wie man die Runlevel sinnvoll am Stück testen kann (manuell aufgerufen funktionieren die ersten Scripte auch einwandfrei). Dabei starte ich mit den K01... Script weil schon dieses beim Manuellen Wechsel nicht auf der Konsole erscheint. Auch die Scripte welche beim automatischen Booten im Runlevel 5 erscheinen (S17powersaved wird noch OK angezeigt) und auch dessen nachfolge script arbeiten manuell einwandfrei.
Ein manuelles starten von kdm klappt auch einwandfrei. Jetzt weiß ich nicht mehr weiter. Kann es sein, daß der init 5 Prozeß auch nicht im rc5.d befindliche scripte startet?
Ciao
Ulf
Hallo
ich habe seit dem Update von KDE Supplementary auf 3.5.1.1, (SUSE10) genau dasselbe Problem,
bei mir liegt dies am Startskript earlykdm. Beim Start über Displaymanager, bei init 5, und bei /etc/init.d/earlykdm wird diese skript nicht “beendet”; bei /earlykdm restart im Runlevel 3 wird der Displaymanager gestartet.
Da ich derzeit wenig Zeit hatte, habe ich /etc/init.d/rc5.d/S03earlykdm einfach nach s03earlykdm umbenannt. Der Displaymanager wird bei mir wegen eines Skriptes S17xdm trotzdem gestartet, Vielleicht kennt ja jemand die Ursache für dieses Problem.
Mir wäre eine funktionierendes Konfiguration ohne Workaround lieber, da ich bisher noch nicht so ganz darüber im Klaren bin welche weiteren Einflüße diese Lösung hat.
Gruß Ralf
Hallo,
Wenn du in der earlykdm folgendes aenderst sollte es wieder gehen:
Hier reicht es eigentlich ein “
Hi Bjørn,
Danke. Genau das war der Richtige hinweiß. Nach der Änderung funktioniert es bei mir wieder einwandfrei. Auch auf meinem x86-64 ist dieser Fehler vorhanden, wirkt sich aber wohl wegen einer anderen Verzweigung Gott sei Dank nicht aus.
Bin mal gespannt wann dieser Fehler gefixt wird (update der earlykdm war vom 24.02.2006).
Danke und Ciao
Ulf
Hallo,
ihr habt das Update kdebase3-kdm-3.5.1-27 genießen dürfen. Wenn ihr ein
Downgrade auf kdebase3-kdm-3.5.1-18 macht, müsste es wieder laufen.
Micha
Hi,
ich hatte das gleiche Problem. Die aktuellen KDEbase-Packs (33) sind aber wieder OK und alles funktioniert wieder.
FF.,
Karsten.
Hi Ralf,
danke, das war der richtige Tip. Eine kurze Analyse hat auch ergeben, daß das Script entweder nur den /etc/init.d/xdm aufruft, was ja auch funktioniert. Oder aber eine Zeile mit folgedem Inhalt
/sbin/preload /etc/preload.d/kdm
aufruft. Diese hängt sich aber aus irgend einem Grund auf. Ich habe mir auch mal dir Datei /etc/preload.d/kdm angesehen. Hier sind Zahlreiche Dateien aufgelistet. Diese beiden Dateien haben sich nicht geändert. Weshalb es an einer der in /etc/preload.d/kdm aufgelisteten Dateien oder an earlykdm selbst liegen muß.
Ich habe jetzt wie Du auch das Script unbenannt, wodurch sich eigentlich nur die Bootzeit etwas verlängert. Ich werde die Sachlage mal weiter im Auge behalten, und bei einer Veränderung hier posten.
Ciao
Ulf