Frage:
Fehler beim Starten des udev-Kernel-Geräte-Managers
Liam
2017-09-16 22:04:01 UTC
view on stackexchange narkive permalink

Nach dem Neustart meines Himbeer-Pi 2 mit Raspian funktioniert es nicht mehr. Wenn ich es einschalte, funktioniert alles einwandfrei, bis diese Fehlermeldung wiederholt angezeigt wird.

[FEHLGESCHLAGEN] Start fehlgeschlagen udev Kernel Device Manager

Das Gerät wechselt dann in den Notfallmodus. Ich habe online keine Antwort gefunden, keine Ideen?

Vor Jahren hatte ich nach einem Raspbian-Update das gleiche Problem mit udev (es stürzte ab und / oder der Neustart funktionierte nicht). Aber heute ** gute Nachricht: Ich habe Raspbian aktualisiert, ein udev scheint gut zu funktionieren ** (auch nach Neustarts usw.)! Ich gehe also davon aus, dass das Problem inzwischen gelöst ist.
Sechs antworten:
#1
+10
EThome
2017-09-28 00:12:24 UTC
view on stackexchange narkive permalink

Es könnte interessant sein zu wissen, welche Version Sie ausführen und ob Sie kürzlich Pakete aktualisiert haben.

Nach dem heutigen Upgrade auf Raspbian-Tests (von Stretch) ist auf meinem Himbeer-Pi2 eine ähnliche Fehlermeldung aufgetreten ). Ich befürchte jedoch, dass dies aus einer Reihe verschiedener Gründe verursacht werden kann.

Die genauere Fehlermeldung, die ich erhielt (von journalctl -u systemd-udevd ), war:

  27. September 16:33:46 raspberrypi systemd-udevd [10856]: / lib / systemd / systemd-udevd: Fehler beim Laden gemeinsam genutzter Bibliotheken: / usr / lib / arm-linux-gnueabihf / libarmmem .so: Segmentprotokoll nach Reloc kann nicht wiederhergestellt werden: Operation nicht zulässig  

Es scheint nicht mit lib / systemd / systemd-udevd selbst in Beziehung zu stehen. Wenn ich einen anderen Dienst systemctl neu starte , erhalte ich einen ähnlichen Fehler:

  root @ raspberrypi: / home / pi # systemctl starte systemd-timesyncd.serviceJob für systemd neu -timesyncd.service ist fehlgeschlagen, weil der Steuerungsprozess mit dem Fehlercode beendet wurde. Weitere Informationen finden Sie unter "systemctl status systemd-timesyncd.service" und "journalctl -xe" [email protected]: / home / pi # journalctl -xe [...] 27. September 18:54:50 raspberrypi systemd-timesyncd [26811]: / lib / systemd / systemd-timesyncd: Fehler beim Laden der gemeinsam genutzten Bibliotheken: /usr/lib/arm-linux-gnueabihf/libarmmem.so: Segmentprotokoll kann danach nicht wiederhergestellt werden reloc: Vorgang nicht zulässig [...]  

Meines Wissens nach führt systemd Binärdateien in einer Umgebung aus, die mit einem Umzug kollidiert, der in libarmmem.so verwendet wird . Dies ist entweder ein Fehler in systemd (hier Version 234-3) oder in dem Paket, das libarmmem.so ( raspi-copy-and-fills , Version 0.6 von) bereitstellt hier strecken).

systemd ist natürlich wichtig, raspi-copy-and-fills nicht (dies ist eine wichtige Optimierung, aber das System kann ohne sie ausgeführt werden). Ich habe mein Problem mit der folgenden Zwischenlösung gelöst:

  root @ raspberrypi: / home / pi # apt bereinigen Raspi-Kopien-und-Füllungen
 

Natürlich werde ich die möglichen Aktualisierungen von raspi-copy-and-fills (bisher in Version 0.6) überwachen, in der Hoffnung, beide ein bootfähiges System zu erhalten und die schnellen memcpy .

#2
+7
ddrjm
2017-10-28 18:41:42 UTC
view on stackexchange narkive permalink

Ab Systemd 235-2 wird dies immer noch mit genau demselben Fehler fortgesetzt.


Für Personen, die hier von Google landen:

Wenn Sie sehen, dass nach apt dist-upgrade entweder udev , journald oder sogar timesyncd abstürzen,

Bis raspi-copy-and-fills aktualisiert wird und gelöscht wird, wie Emmanuel Thomé vorgeschlagen hat, ist die bislang einzig praktikable Lösung.

#3
+2
vhdirk
2018-06-25 15:37:48 UTC
view on stackexchange narkive permalink

Das Neuerstellen von Raspi-Kopien und -Füllungen von https://github.com/bavison/arm-mem behebt dies in Buster.

Könnten Sie bitte näher erläutern, wie das geht?
#4
+1
user170045
2018-08-18 17:34:40 UTC
view on stackexchange narkive permalink

Ich hatte das gleiche Problem mit meinem pi-3 und raspi-copy-and-fills installiert. Udev / systemd 232-25 + deb9u1 war die letzte Arbeitsversion. Alle Updates für eine neuere udev-Version sind fehlgeschlagen und ich musste immer auf 232-25 + deb9u1

zurückgreifen. Jetzt habe ich raspi-copy-and-fills entfernt und auf 239 aktualisiert -7 hat fehlerfrei funktioniert.

#5
  0
Damien L.
2019-06-08 01:08:12 UTC
view on stackexchange narkive permalink

Nach dem Upgrade von Raspbian 8 auf Raspbian 9 hatte ich ein ähnliches Problem. Nachdem das udev-Paket auf die neueste Backport-Version aktualisiert wurde, wurde die Himbeere im Notfallmodus gestartet:

  Willkommen im Notfallmodus! Geben Sie nach dem Anmelden "journalctl -xb" ein, um die Systemprotokolle anzuzeigen, "systemctl reboot", um einen Neustart durchzuführen, "systemctl default" oder ^ D, um erneut zu versuchen, in den Standardmodus zu starten. :  

Entfernen von Raspi-Kopien und -Fills Lösen Sie es !!

Und warum sollte das helfen?
Was ist das "Raspi-Kopien-und-Füllungen"? Wo ist es?
#6
  0
p00ya
2019-06-22 16:53:49 UTC
view on stackexchange narkive permalink

Nach dem Upgrade auf Raspbian Buster bin ich heute auf dasselbe Problem gestoßen. Ich konnte das System wieder booten lassen, nachdem ich Version 0.11 von Raspi-Copies-and-Fills aus dem Wiederherstellungsmodus gemäß der Antwort von @ emmanuel-thomé gelöscht hatte.

Angesichts der Antwort von @ vhdirk (dass ein Neuaufbau von Arm-Mem-Quelle funktioniert), hier ist, wie ich ein neues raspi-copy-and-fills -Paket neu erstellt habe ...

Ich habe den Upstream (arm-mem) und RPi- gezogen. Distro repos, dann die Version auf 0.12 erhöht (das udev 241-5-Paket listet frühere Raspi-Copy-and-Fills-Versionen auf).

  git clone https://github.com/p00ya/ arm-mem.git -b p00yacd arm-memdebuild -b -uc -ussudo dpkg -i ../raspi-copies-and-fills_0.12+nmu1_armhf.deb 

Dies scheint zu sein Arbeit (getestet mit sudo systemctl udev nach der Installation neu starten).



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...