Question:
échec du démarrage du gestionnaire de périphériques du noyau udev
Liam
2017-09-16 22:04:01 UTC
view on stackexchange narkive permalink

Après avoir à peine redémarré mon raspberry pi 2 exécutant raspian, il ne fonctionne plus, quand je l'allume, tout fonctionne bien jusqu'à ce que ce message d'erreur s'affiche à plusieurs reprises.

[FAILED] Échec du démarrage udev Kernel Device Manager

La machine passe alors en mode urgence.Je n'ai trouvé aucune réponse en ligne, aucune idée?

Il y a des années, j'ai eu le même problème avec udev après une mise à jour de Raspbian (il s'est écrasé et / ou le redémarrage n'a pas fonctionné). Mais aujourd'hui, ** bonne nouvelle: j'ai mis à jour Raspbian, un udev semble bien fonctionner ** (même après les redémarrages, etc.)! Je suppose donc que le problème a été résolu maintenant.
Six réponses:
#1
+10
EThome
2017-09-28 00:12:24 UTC
view on stackexchange narkive permalink

Il peut être intéressant de savoir quelle version vous utilisez, et si vous avez mis à jour des paquets récemment.

J'ai rencontré un message d'erreur similaire sur mon raspberry pi2 après la mise à niveau vers raspbian testing aujourd'hui (de stretch ). Cependant, je crains que cela puisse être causé par une gamme complète de raisons différentes.

Le message d'erreur plus précis que j'ai reçu (de journalctl -u systemd-udevd ) était:

  27 septembre 16:33:46 raspberrypi systemd-udevd [10856]: / lib / systemd / systemd-udevd: erreur lors du chargement des bibliothèques partagées: / usr / lib / arm-linux-gnueabihf / libarmmem .so: impossible de restaurer le segment prot après relocalisation: opération non autorisée  

Il ne semble pas être lié à lib / systemd / systemd-udevd lui-même. En effet, si je systemctl redémarre un autre service, j'obtiens une erreur similaire:

  root @ raspberrypi: / home / pi # systemctl restart systemd-timesyncd.serviceJob pour systemd -timesyncd.service a échoué car le processus de contrôle s'est terminé avec un code d'erreur. Voir "systemctl status systemd-timesyncd.service" et "journalctl -xe" pour plus de dé[email protected]: / home / pi # journalctl -xe [...] 27 sept 18:54:50 raspberrypi systemd-timesyncd [26811]: / lib / systemd / systemd-timesyncd: erreur lors du chargement des bibliothèques partagées: /usr/lib/arm-linux-gnueabihf/libarmmem.so: impossible de restaurer le segment prot après reloc: Opération non autorisée [...]  

Je crois comprendre que systemd exécute des binaires dans un environnement qui entre en conflit avec un déplacement utilisé dans libarmmem.so . C'est soit un bogue dans systemd (version 234-3 ici), soit dans le paquet qui fournit libarmmem.so ( raspi-copies-and-fills , version 0.6 de stretch ici).

systemd est bien sûr essentiel, alors que raspi-copies-and-fills ne l'est pas (c'est une optimisation importante, mais le système peut fonctionner sans elle). J'ai résolu mon problème avec la solution provisoire suivante:

  root @ raspberrypi: / home / pi # apt purge raspi-copies-and-fills

Clairement, je vais surveiller les mises à jour possibles de raspi-copies-and-fills (jusqu'à présent à la version 0.6), dans l'espoir d'obtenir à la fois un système amorçable et les memcpy rapides.

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

Depuis systemd 235-2, cela continue avec exactement la même erreur.


Pour les personnes qui arrivent ici depuis Google:

Si vous voyez qu'après apt dist-upgrade que soit udev , journald ou même timesyncd plantent,

Jusqu'à ce que raspi-copies-and-fills soit mis à jour, le purger comme suggéré par Emmanuel Thomé est la seule solution viable à ce jour.

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

La reconstruction de raspi-copies-and-fills depuis https://github.com/bavison/arm-mem corrige ce problème dans buster.

Pourriez-vous s'il vous plaît expliquer comment procéder?
#4
+1
user170045
2018-08-18 17:34:40 UTC
view on stackexchange narkive permalink

J'ai eu le même problème avec mon pi-3 et mon raspi-copies-and-fills installés. Udev / systemd 232-25 + deb9u1 était la dernière version fonctionnelle. Toutes les mises à jour d'une version plus récente d'udev ont échoué et j'ai toujours été obligé de revenir à 232-25 + deb9u1

Maintenant, j'ai supprimé raspi-copies-and-fills et la mise à jour vers 239 -7 a fonctionné sans erreur.

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

J'ai eu un problème similaire après la mise à niveau de Raspbian 8 vers Raspbian 9. Après la mise à niveau du paquet udev vers la dernière version de backport, la framboise démarrait en mode d'urgence:

  Bienvenue en mode d'urgence! Après vous être connecté, saisissez "journalctl -xb" dans les journaux du système de visualisation, "systemctl reboot" pour redémarrer, "systemctl default" ou ^ Dpour essayer à nouveau de démarrer en mode par défaut. :  

suppression de raspi-copies-and-fills résoudre le problème !!

Et pourquoi cela aiderait-il?
Qu'est-ce que c'est "raspi-copies-and-fill"? Où est-ce?
#6
  0
p00ya
2019-06-22 16:53:49 UTC
view on stackexchange narkive permalink

J'ai rencontré le même problème aujourd'hui après la mise à niveau vers Raspbian Buster. J'ai pu redémarrer le système après avoir purgé la version 0.11 de raspi-copies-and-fills du mode de récupération selon la réponse de @ emmanuel-thomé.

Étant donné la réponse de @ vhdirk (qu'une reconstruction à partir de arm-mem source fonctionne), voici comment j'ai reconstruit un nouveau paquet raspi-copies-and-fills ...

J'ai tiré l'amont (arm-mem) et RPi- Distro repos, puis repoussé la version à 0.12 (le paquet udev 241-5 liste noire les versions précédentes de raspi-copies-and-fills).

  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

Cela semble fonctionne (testé avec sudo systemctl restart udev après l'installation).



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...