GentooForum.de

http://www.linuxforum.ru/lofiversion/index.php/t29812.html

Ich kann zwar kein russisch, aber "revdep-rebuild" kann eigentlich nicht schaden

wie hast du den kernel erstellt?
genkernel, oder selbst gemacht,
hast du hotplug + filesystem support mit eingebaut?

hallo zusammen.

Also huzeyfe, ich vermute, du hast irgendein Packet emerged, das als Abhaengigkeit udev hatte... ergo udev wird auf den neuesten Stand gebracht, aber die config files bleiben die von der alten Version.

Diese Aufrufe scheittern, weil es bei der neuen udev Version diese Programme nicht gibt (oder sie werden einfach nicht mitkompilliert).

Was mir bei dem Problem geholfen hat, ist ein einfaches:

Der Hacken dabei ist - udev wird beim booten nicht gestartet. Solltest du also Probleme mit den device files haben, a la "couldn't open /dev/vmmon" (vmware player spuckt den hier aus), dann musst du den udev daemon starten


Dieser sorgt dafuer, dass die benoetigten device files angelegt werden, wenn vom Kernel ein entsprechener Event kommt. Aehnlich wirkt sich auch "udevstart" aus, nur dass udevstart nicht als daemon laeuft (genauer kannst du es in den manpages nachlesen).

cu

Quatsch, wenn überhaupt, dann hat sich der Pfad geändert und da könnte man dann einfach einen Symlink verwenden (würde ich aber nicht so machen, siehe unten).

Ich sehe da zwei Möglichkeiten:
Entweder du schaust, was auf /sbin/udev_run_XXX zugreifen will und du baust dieses Paket neu oder du machst einen Symlink.

Bei mir war das zum Beispiel mal wegen libgphoto2 so. Nach einem neuen Mergen von diesem Paket war wieder alles okay.
Diese Vorgehensweise (schauen, was den Aufruf verursacht und dieses Paket neu zu bauen) würde ich bevorzugen, weil es "sauberer" ist, als manuell den Symlink zu erstellen.

Zitat

Original von maggu2810
Quatsch, wenn überhaupt, dann hat sich der Pfad geändert und da könnte man dann einfach einen Symlink verwenden (würde ich aber nicht so machen, siehe unten).

	Quellcode
1 2 3	# locate udev_run_ /lib/udev/udev_run_devd /lib/udev/udev_run_hotplugd

tatsache - habe im falschen verzeichnis gesucht.

Na ja, wie gesagt, mir hats gereicht udev neuzukompillieren und udevd nach bedarf zu starten.

Zitat

Der Hacken dabei ist - udev wird beim booten nicht gestartet.

Haken nicht Hacken
Dann würde ich das aber in Ordnung bringen.

Zitat

Original von maggu2810

Zitat

Der Hacken dabei ist - udev wird beim booten nicht gestartet.

Haken nicht Hacken

richtig, Haken

Zitat

Original von maggu2810Dann würde ich das aber in Ordnung bringen

Na ja, ich kann damit leben, dass ich udevd starten muss, bevor ich hardware anschliesse, fuer die es noch keinen device file gibt (was in meinem Fall selten vorkommt).

Um jetzt zum eigentlichen Thema zurueck zu kommen - ich wuerde huzeyfe raten die Links wiederherzustellen, wie maggu28 es vorgeschlagen hat... oder gucken, ob er mit meiner Loesung leben kann.

cu

Setz doch mal in deiner /etc/conf.d/rc
RC_DEVICES auf udev

Zitat

Original von maggu2810
Setz doch mal in deiner /etc/conf.d/rc
RC_DEVICES auf udev

war das erste, was ich versucht habe. Es kommt eine Fehlermeldung a la "udev konnte nicht gestartet werden". Aber ich habe an die Symlinks nicht gedacht, als ich das gemacht habe. Werd gleich die Links setzen und noch mal versuchen.

cu

--edit--

... leider nicht geklappt. So vorausschauend wie ich bin, habe ich mir die Fehlermeldung nicht notiert, aber sie lautet so aehnlich "You wanted to use udev, but it is not available."

Die Links beheben doch das andere Problem, aber so soll mans ja gar nicht machen.
Deines ist ja wieder was anderes.

also am Anfang sah mein Problem genau so aus, wie bei huzeyfe. Dann habe ich udev mit CONFIG_PROTECT="-*" kompilliert, und es lief alles wieder... bis auf den "Haken", dass udev nicht mehr automatisch starten wollte.

Morgen Maedels!

Habs jetzt! ein "emerge baselayout udev" behebt das Problem in meinem Fall vollstaendig. Keine Fehlermeldungen mehr und udev startet automatisch.

cu