Może być interesujące wiedzieć, której wersji używasz i czy zdarzyło Ci się ostatnio zaktualizować pakiety.

Napotkałem podobny komunikat o błędzie na moim pi2 raspberry po dzisiejszej aktualizacji do testów raspbian (z wydania stretch ). Jednak obawiam się, że może to być spowodowane wieloma różnymi przyczynami.

Dokładniejszy komunikat o błędzie, jaki otrzymałem (z journalctl -u systemd-udevd ) brzmiał:

  27 września 16:33:46 raspberrypi systemd-udevd [10856]: / lib / systemd / systemd-udevd: błąd podczas ładowania bibliotek współdzielonych: / usr / lib / arm-linux-gnueabihf / libarmmem .so: nie można przywrócić ochrony segmentu po reloc: operacja niedozwolona  

Wydaje się, że nie jest powiązany z samym lib / systemd / systemd-udevd . Rzeczywiście, jeśli systemctl restartuję inną usługę, pojawia się podobny błąd:

  root @ raspberrypi: / home / pi # systemctl restart systemd-timesyncd.serviceJob for systemd -timesyncd.service nie powiodło się, ponieważ proces sterowania zakończył działanie z kodem błędu. Zobacz „systemctl status systemd-timesyncd.service” i „journalctl -xe” po szczegóły.root@raspberrypi: / home / pi # journalctl -xe [...] 27 września 18:54:50 raspberrypi systemd-timesyncd [26811]: / lib / systemd / systemd-timesyncd: błąd podczas ładowania bibliotek współdzielonych: /usr/lib/arm-linux-gnueabihf/libarmmem.so: nie można przywrócić zabezpieczenia segmentu po reloc: Operacja niedozwolona [...]  

Rozumiem, że systemd uruchamia pliki binarne w środowisku, które koliduje z relokacją używaną w libarmmem.so . Jest to albo błąd w systemd (tutaj wersja 234-3), albo w pakiecie, który zawiera libarmmem.so ( raspi-copy-and-fills , wersja 0.6 z stretch tutaj).

systemd jest oczywiście niezbędny, podczas gdy raspi-copy-and-fills nie (jest to ważna optymalizacja, ale system może działać bez niego). Rozwiązałem swój problem za pomocą następującego tymczasowego rozwiązania:

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

Oczywiście będę monitorować możliwe aktualizacje raspi-copy-and-fills (do tej pory w wersji 0.6), mając nadzieję, że uda mi się uzyskać zarówno system startowy i szybkie memcpy .

Od systemd 235-2 nadal występuje ten sam błąd.

Dla osób lądujących tutaj z Google:

Jeśli widzisz, że po apt dist-upgrade następuje awaria udev , journald lub nawet timesyncd ,

Dopóki raspi-copy-and-fills zostanie zaktualizowany, usunięcie go tak, jak sugerował Emmanuel Thomé, jest jedynym realnym rozwiązaniem.

Odbudowanie raspi-copy-and-fills z https://github.com/bavison/arm-mem rozwiązuje ten problem w buster.

Miałem ten sam problem z zainstalowanymi pi-3 i raspi-copy-and-fills . Udev / systemd 232-25 + deb9u1 był ostatnią działającą wersją. Wszystkie aktualizacje do nowszej wersji udev nie powiodły się i zawsze byłem zmuszony powrócić do wersji 232-25 + deb9u1

Teraz usunąłem raspi-copy-and-fills i zaktualizowałem do wersji 239 -7 działało bez błędów.

Miałem podobny problem po aktualizacji z Raspbian 8 do Raspbian 9. Po aktualizacji pakietu udev do najnowszej wersji Backport, malina uruchamiała się w trybie awaryjnym:

  Witamy w trybie awaryjnym! Po zalogowaniu wpisz „journalctl -xb” w celu wyświetlenia dzienników systemu, „systemctl reboot”, aby zrestartować, „systemctl default” lub ^ D, aby spróbować ponownie uruchomić system w trybie domyślnym. :  

usuwanie raspi-copy-and-fills rozwiąż to !!

Dziś napotkałem ten sam problem po aktualizacji do wersji Raspbian buster. Udało mi się ponownie uruchomić system po wyczyszczeniu wersji 0.11 raspi-copy-and-fills z trybu odzyskiwania zgodnie z odpowiedzią @ emmanuel-thomé.

Biorąc pod uwagę odpowiedź @ vhdirk (że przebudowa z arm-mem działa), oto jak odbudowałem nowy pakiet raspi-copy-and-fills ...

Wyciągnąłem upstream (arm-mem) i RPi Distro repos, następnie podbiłem wersję do 0.12 (czarne listy pakietu udev 241-5 wcześniejszych wersji raspi-copy-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

działa (testowane z sudo systemctl zrestartuj udev po instalacji).