• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Failed to start udev Kernel Device Manager

Bin mal wieder um Euren Rat verlegen :

Schon vorgestern wollte mein Desktop-Rechner nicht richtig hochfahren. Nachdem er mir recht lange das Suse-Chamaeleon zeigte, kam anschließend eine Textkonsole mit einer Menge Meldungen, die sich aber im wesentlichen wiederholten, bis ich dann in einem "emergency mode" landete, wo ich mich einloggen konnte. Allerdings war mir unklar, was ich in diesem Textmodus machen sollte. Ich startete den Rechner neu und konnte problemlos ordentlich hochfahren.

Eben zeigte der Rechner mir wieder das gleiche Verhalten. Irgendetwas ist wohl nicht in Ordnung. Hierzu bitte ich um Euren Rat. Was könnte meinem Rechner fehlen?

Das Betriebssystem ist openSuse 12.1 KDE. Der Rechner läuft im 32-Bit Modus.

Ich poste hier von meinem Notebook und tippe mal die wesentlichen Infos vom Desktoprechner-Monitor ab :

Code:
Failed to start udev Kernel Device Manager
See 'systemctl status udev.service' for details.
Starting udev Kernel Device Manager...
     5.744662] udevd[405]: bind failed: Address already in use
     5.744831] udevd[405]: error binding udev control socket

Dieser Fehlerblock wiederholt sich (mit anderen Zeitangaben) noch 7 mal.

Dann folgen etwa 15 Zeilen über erfolgreich gestartete Systeme (Kernel variables, Media Directory, Lock Directory usw). Anschließend 6 Fehler "dependency failed" für verschiedene Mountpunkte und Partitions.

Dann stehe ich im erwähnten "emergency mode" :

Code:
Welcome to emergency mode. Use "systemctl default" or ^D to activate default mode.
Give root password for login:

Ich denke zwar, daß ich den Rechner mit Neustart wieder hoch bekomme, möchte aber (weil der Fehler sich zu häufen scheint) Euren fachkundigen Rat einholen.

Ich lasse den Rechner jetzt mal in diesem Zustand, falls die Hilfe schon bald kommen sollte. Mit dem Notebook bin ich ja noch online.

Gruss H.

P.S. ich habe auch den Monitor auf Digitalkamera aufgenommen, so daß ich auch später noch Infos bieten kann.
 
Hallo,

Das Problem hat vermutlich :D mit udevd "timing" zu tun (braucht mehr Zeit für einen stop). Siehe z.B.

udevd fails to start: bind failed: Address already in use
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/787610

oder

Fails to start: failed to bind control socket (address in use)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624469

Du könntest dies testen mit:
Code:
break=init
in der Boot Zeile (dann mit ctrl-d weitermachen) -- dies macht ein Delay.

Wenn bestätigt, dann könntest Du (sofern ich die obigen Links richtig verstanden habe) in der Datei /etc/init.d/boot.udev den stop loop
Code:
        stop)
                echo -n "Stopping udevd: "
                killproc /sbin/udevd
                rc_status -v
                ;;
ersetzen durch:
Code:
        stop)
                echo -n "Stopping udevd: "
                udevadm control --exit
                ;;

Falls es für Dich ein udev Update gibt, wäre dies vielleicht auch eine Lösung.

Gruss,
Roland
 
Guten Morgen Roland,

vielen Dank für Deine Antwort. Deine geposteten Links scheinen sich tatsächlich mit meinem Problem zu beschäftigen.

Allerdings wird dort abschliessend gemeldet, daß der Bug mit udev 169-1 behoben sei. Meine udev Version ist schon 173-3.6.1. Eine neuere liegt anscheinend auch nicht vor.

RME schrieb:
... Du könntest dies testen mit:
Code:
break=init
in der Boot Zeile (dann mit ctrl-d weitermachen) -- dies macht ein Delay ...

Abgesehen davon, daß der Fehler bei mir bisher erst zweimal und damit nicht permanent auftrat, habe ich noch ein Verständnisproblem mit Deinem Vorschlag :

Ich gebe "break=init" in die Bootoptionszeile ein. Wann muß ich dann ctrl-d geben? Sofort? Oder nach ENTER?

Mein System fährt heute schon zweimal mit beiden von mir versuchten Optionen sauber hoch. Wie gesagt: der Fehler ist nicht fest! Also kann der Test (wenn er richtig von mir durchgeführt wird) vermutlich erst nach etlichen Versuchen eine verlässliche Aussage bringen.

Eine Information muß ich noch nachreichen: bei der Umstellung von openSuse 11.4 auf 12.1 hatte ich zunächst die Bootoption "init=/sbin/sysvinit" mitgegeben, weil mein Rechner Probleme mit "systemd" hatte. Ich bin dann monatelang mit dieser Option gefahren. Vor einiger Zeit (1-2 Wochen?) habe ich probeweise diese Bootoption wieder rausgenommen und fahre seitdem mit "systemd". Ich musste lediglich in den Systemeinstellungen das Abschaltkommando auf "/sbin/shutdown -h -P now" ändern, da der Rechner ansonsten nicht sauber runterfuhr.

Könnte also diese erst kürzlich vorgenommene Änderung die Wurzel meines Problems sein?

Gruss H.
 
Hallo,

Allerdings wird dort abschliessend gemeldet, daß der Bug mit udev 169-1 behoben sei. Meine udev Version ist schon 173-3.6.1. Eine neuere liegt anscheinend auch nicht vor.
Allerdings ist die dort gepostete Lösung (d.h. udevadm control --exit) in openSUSE 12.1 nicht implementiert (auf meiner live-CD jedenfalls ist immer noch killproc /sbin/udevd). Wenn Du das Problem weiterhin beobachtest, könntest Du trotzdem mal die vorgeschlagene Lösung testen (kannst es ja jederzeit wieder rückgängig machen).

Ich gebe "break=init" in die Bootoptionszeile ein. Wann muß ich dann ctrl-d geben? Sofort? Oder nach ENTER?
Ja da hast Du recht! Dieser Parameter ist offenbar nicht (mehr) eingebaut. Vielleicht gibts etwas anderes stattdessen... ich weiss es nicht.

Gruss,
Roland
 
RME schrieb:
... könntest Du trotzdem mal die vorgeschlagene Lösung testen (kannst es ja jederzeit wieder rückgängig machen).
...

Habe das Script, wie von Dir vorgeschlagen, geändert. Der Rechner fährt auch fehlerfrei hoch.

Ich lasse das Thema zunächst noch offen, weil ich das doch über einige Tage beobachten will.

Danke nochmal für Deine Mühe.

Gruss H.
 
Habe das Script, wie von Dir vorgeschlagen, geändert. Der Rechner fährt auch fehlerfrei hoch.
Super :thumbs:

Ich habe auf meinem Desktop das (kleine) Problem dass von Zeit zu Zeit (etwa einmal pro 20 Boots) die Tastatur sowie Mouse (beide usb) im Grub-Menü nicht reagieren. Das heisst, das System bootet dann das Linux welches zuoberst im Menü aufgelistet ist (und dann funktioniert Tastatur+Mouse wieder). Dies ist jedoch nicht das Linux mit welchem ich normalerweise arbeite. Ich muss dann ein Reboot machen und dann ist alles wieder wie es soll.

Ich habe nun ebenfalls /etc/init.d/boot.udev wie gepostet editiert. Mal sehen ob es etwas bewirkt. Mit Fehlern die nur selten auftreten ist das Testen natürlich nicht eben schnell gemacht.

Werde dann auch melden.

Gruss,
Roland
 
Nachdem der Fehler jetzt seit mehr als zwei Wochen nicht mehr auftrat, markiere ich das Thema mal als gelöst.

Gruss H.
 
Hallo halo44 und RME

Ich betreibe eine openSUSE-12.1 (32 bit) unter KDE-4.7.4, ganz ähnlich wie halo44, der vor einigen Wochen den thread hier eröffnet hat.

Das von halo44 beschriebene spontane Hängenbleiben beim booten kannte ich aus den letzen Monaten ebenfalls aus ca. 10 Fällen. Daraufhin habe ich vor 15 Tagen die hier empfohlene Änderung in der /etc/init.d/boot.udev vorgenommen.

Danach war erstmal Ruhe...bis heute. Vor einigen Stunden kam der ganze Schlamassel wieder hoch - exakt so wie früher.

OK, das war jetzt natürlich kein Beitrag zur Klärung. Ich wollte nur melden, dass die vorgeschlagene Lösung, wenigstens in meinem Fall, nicht greift.

Sommerliche Grüße aus Franken
Hazel
 
Hallo,

@halo44
Danke für die Rückmeldung :thumbs:

Bei mir hat die Tastatur seit dem Edit nicht mehr "geklemmt" und hoffe es bleibt so.

...dass die vorgeschlagene Lösung, wenigstens in meinem Fall, nicht greift.
...schade. Diese Timing-Probleme sind manchmal sehr tükisch. Ich hatte mal das Problem dass ich KDE (nach einem Update) nicht mehr booten konnte; sobald ich das Passwort eingegeben hatte wurde nach einer Verzögerung das Login-Fenster wieder angezeigt. Dann habe ich einen anderen Windowmanager gebootet (hat funktioniert) und danach funktionierte auch das KDE Login wieder.

Was Du versuchen könntest: noch eine (kurze) Pause einfügen:
Code:
        stop)
                echo -n "Stopping udevd: "
                udevadm control --exit
                sleep 1
                ;;
sleep 1 = eine Sekunde (kannst auch mit "sleep 2" testen).

Gruss,
Roland
 
Hallo RME

Danke für deinen Vorschlag. Ich habe die Ergänzung in die /etc/init.d/boot.udev eingebracht.

Jetzt heisst es abwarten. Da der Fehler bisher nur spontan auftrat, macht es wenig Sinn, eine feste Beobachtungszeit vorzugeben. Sobald es aber wieder kracht, melde ich mich an dieser Stelle wieder.

Grüße
Hazel
 
RME schrieb:
Timing-Probleme sind manchmal sehr tükisch
Das ist die einzige wirkliche Tatsache bei diesem Thema. Ansonsten sehe ich nur Zufälligkeiten. (Würde ich lästern, spräche ich von Sagen und Märchen.)

RME schrieb:
Tastatur sowie Mouse (beide usb) im Grub-Menü nicht reagieren
RME schrieb:
/etc/init.d/boot.udev wie gepostet editiert
Zwischen diesen beiden Aussagen gibt es absolut keinen Zusammenhang. Solange der Boot-Manager am Werk ist, ist von einem Linux weit und breit nichts zu sehen, somit ist es völlig bedeutungslos, was in irgendwelchen Linux-Dateien steht. Hier patzt offenbar das BIOS.

halo44 schrieb:
See 'systemctl status udev.service' for details.
halo44 verwendet also systemd, dessen Konfiguration in /lib/systemd bzw. /etc/systemd zu finden ist. Welchen Einfluß soll eine Änderung in einer von sysvinit verwendeten Datei haben?

RME schrieb:
in der Datei /etc/init.d/boot.udev den stop loop
Beim Hochfahren erfolgt der Start von udev. Das Beenden von udev passiert beim Herunterfahren, wie soll eine hier vorgenommene Änderung etwas beim Start bewirken?
 
Hallo Josef

Darf ich deine letzten Anmerkungen zusammenfassend so interpretieren, dass RME und ich hier eine völlig falsche Spur verfolgen?

Hier patzt offenbar das BIOS.

Das BIOS patzt dann aber bei mir offensichtlich nur beim Hochfahren der openSUSE 12.1. Meine parallel installierte 11.4 läuft seit ihrer Erstinstallation wie geschmiert hoch, und auch eine ältere 11.3 hatte niemals derartige Probleme. Passt diese Beobachtung zu deiner "heißen Spur" in Richtung BIOS?

Grüße
Hazel
 
Grundsätzlich wollte ich darauf hinweisen, daß die beschriebene Ergänzung in boot.udev mit den genannten Problemen nichts zu tun haben kann.

Das BIOS-Problem betrifft nur RME, dessen USB-Eingabegeräte ab und zu im Boot-Manager (der auf korrekte BIOS-Funktionen angewiesen ist) nicht verwendbar sind.

Das udev-Problem deute ich als fehlende Abhängigkeit bei der systemd-Konfiguration (wenn udev das dadurch auftretende "Duell" verliert, entsteht das Problem), da ich systemd nicht verwende, kann ich dazu nichts beitragen.
 
Hallo,

Beim Hochfahren erfolgt der Start von udev. Das Beenden von udev passiert beim Herunterfahren, wie soll eine hier vorgenommene Änderung etwas beim Start bewirken?
Grundsätzlich wollte ich darauf hinweisen, daß die beschriebene Ergänzung in boot.udev mit den genannten Problemen nichts zu tun haben kann.
Bist Du sicher?

Es ist eben weil der Shutdown ("killproc /sbin/udevd") nicht richtig funktioniert hat, dass der folgende Boot Probleme hat:
Code:
Failed to start udev Kernel Device Manager...
Das
Code:
udevadm control --exit
bewirkt eine lange "settle time" (damit alle parallel laufenden Prozesse beendet werden können und erst dann "boot.udev" von selber endet (um Fehler in der udev Datenbank zu verhindern). (ich verstehe die Einzelheiten nicht -- es gibt etliche Beiträge im Netz, viele davon Bug-Reports). Darauf ist auch mein Vorschlag noch ein "sleep 1" anzuhängen begründet.

(es gibt ja noch andere Möglichkeiten wie ein Fehlerhafter Shutdown das folgende Boot beinträchtigen kann)

halo44 verwendet also systemd, dessen Konfiguration in /lib/systemd bzw. /etc/systemd zu finden ist. Welchen Einfluß soll eine Änderung in einer von sysvinit verwendeten Datei haben?
Soviel ich weiss wurde udev erst kürzlich (nach openSUSE 12.1) in systemd integriert (--> systemd-tools).

Udev will become part of systemd
http://www.h-online.com/open/news/item/Udev-will-become-part-of-systemd-1500832.html

Date: 2012-04-03 16:18:54 GMT
On Tue, Apr 03, 2012 at 06:15:13PM +0200, Kay Sievers wrote:
> We are about to merge the udev sources into the systemd source tree.
> After that, the next version of systemd will continue with udev’s
> version numbering, i.e. jump immediately from 45 to 184.
http://thread.gmane.org/gmane.linux.hotplug.devel/17392/focus=17393

Somit wären Deine Bemerkungen (für 12.1) nicht korrekt.

Aber ich gebe gerne (und etwas beschämt) zu, dass die Verknüpfung von halo44's Problem mit meiner "blockierte Tastatur" grosser Unsinn war. Ich entschuldige mich. Aber zu meinem Vorschlag für halo44's Problem stehe ich.

Gruss,
Roland
 
josef-wien schrieb:
da ich systemd nicht verwende, kann ich dazu nichts beitragen
Ausschließen kann man natürlich gar nichts, aber ich fände es schon als sehr seltsame Konstruktion, wenn das Starten von udev über /lib/systemd/system/udev.service (was bei halo44 der Fall ist) und das Stoppen über /etc/init.d/boot.udev erfolgt. Aber Ihr könnt es sehr leicht ausprobieren, wenn Ihr am Anfang der bewußten Stelle noch
Code:
systemctl status udev.service
echo "boot.udev: Bitte die Eingabe-Taste drücken."
read X
einfügt.
 
Ich muß meine Meldung vom 12.8. revidieren. Heute mittag trat der Fehler wieder auf. Ich habe daher den gelöst-Vermerk wieder entfernt.

Als erste Maßnahme habe ich Rolands Vorschlag (Einbau von sleep 1) realisiert. Mal abwarten, was passiert.

Ich würde auch Josef-Wiens Vorschlag umsetzen, wenn ich verstünde, wo ich exakt seine Befehle einbauen soll. Vielleicht kann er das noch mal für mich verdeutlichen.

Gruss H.
 
Wo liegt das Problem? Du sollst die drei Zeilen unmittelbar nach der Zeile
RME schrieb:
einfügen. Wenn die Datei beim Herunterfahren verwendet wird, siehst Du (bei splash=silent nach Drücken von Esc) die Meldungen und mußt die Eingabe-Taste drücken, um mit dem Herunterfahren fortzusetzen. Wenn die Datei nicht verwendet wird, dann passiert das alles nicht. Danach solltest Du die drei Zeilen wieder entfernen.
 
josef-wien schrieb:
Wo liegt das Problem? ...
Das Problem sitzt - wie zumeist - vor der Tastatur.

Aber ich habe die 3 Zeilen eingebaut und in der menu.lst den "splash=silent" rausgenommen.

Anscheinend wird die Datei nicht ausgeführt. Ich sehe nur kurz :
Code:
sending SIGTERM to remaining processes...
sending SIGKILL to remaining processes...
unmounting file systems.
unmounted /var/lib/nfs/rpc_pipefs.
unmounted /dev/mqueue.
unmounted /sys/kernel/debug.
unmounted /sys/kernel/security.
unmounted /dev/hugepages.
disabling swaps.
detatching loop devices.
detaching DM devices.
dann wird der Bildschirm dunkel und der Rechner fährt weiter runter.

Gruss H.
 
Hallo,

Anscheinend wird die Datei nicht ausgeführt.
Das sehe ich auch so, und somit stimmt mein Bild von systemd. Ihr dürft Euch jetzt auf die Suche machen, wo und wie systemd das Beenden von udev veranlaßt.
Ja das sieht so aus.

openSUSE 12.1 ist bei mir nicht installiert (und werde dies auch nicht tun); aber vielleicht 12.2 nächsten Monat... Bezüglich dem udev Problem muss ich (zumindest vorläufig) leider passen.

Ich hatte verstanden (nicht aus Erfahrung sondern gemäss Publikationen) dass udev erst nach openSUSE 12.1 in das systemd integriert worden ist. Aber offenbar ist da SUSE einen eigenen Weg gegangen. Wenn ich von der openSUSE liv-cd boote, dann:

Code:
linux:/ # ls -l /etc/init.d/boot.ud*
-rwxr-xr-x 1 root root 2000 Nov  8  2011 /etc/init.d/boot.udev
linux:/ # 

linux:/ # /etc/init.d/boot.udev stop && /etc/init.d/boot.udev start
redirecting to systemctl
redirecting to systemctl
linux:/ #

linux:/ # systemctl restart udev.service
linux:/ # 

linux:/ # systemctl status udev.service
udev.service - udev Kernel Device Manager
          Loaded: loaded (/lib/systemd/system/udev.service; static)
          Active: active (running) since Thu, 23 Aug 2012 13:20:04 +0000; 10min ago
        Main PID: 3019 (udevd)
          CGroup: name=systemd:/system/udev.service
                  └ 3019 /sbin/udevd
linux:/ #
Dies sagt doch etwas aus (redirecting to systemctl). Leider gibts kein "--verbose" Flag für systemctl.

Wenn nun tatsächlich der Source-Code von udev bereits im 12.1 in systemd integriert wurde, dann müssten die von mir vorgeschlagenen edits im udev Code von systemd gemacht werden (Sourcecode von systemd editieren, dann neu compilieren)... also nicht mehr ganz so einfach.

@halo44
Ein Update auf 12.2 (ab 5. Sept. http://en.opensuse.org/openSUSE:Roadmap) könnte die Problem-Lösung sein. Ansonsten kann ich mir dann mal die Source von systemd/udev anschauen.

Gruss,
Roland
 
Oben