It might be interesting to know which version you are running, and if you happened to update packages recently.
I encountered a similar error message on my raspberry pi2 after upgrading to raspbian testing today (from stretch). However I fear that it may be caused by a full range of different reasons.
The more precise error message I got (from
journalctl -u systemd-udevd) was:
Sep 27 16:33:46 raspberrypi systemd-udevd: /lib/systemd/systemd-udevd: error while loading shared libraries: /usr/lib/arm-linux-gnueabihf/libarmmem.so: cannot restore segment prot after reloc: Operation not permitted
It does not seem to be related to
lib/systemd/systemd-udevd itself. Indeed, if I
systemctl restart another service, I get a similar error:
root@raspberrypi:/home/pi# systemctl restart systemd-timesyncd.service
Job for systemd-timesyncd.service failed because the control process exited with error code.
See "systemctl status systemd-timesyncd.service" and "journalctl -xe" for details.
root@raspberrypi:/home/pi# journalctl -xe
Sep 27 18:54:50 raspberrypi systemd-timesyncd: /lib/systemd/systemd-timesyncd: error while loading shared libraries: /usr/lib/arm-linux-gnueabihf/libarmmem.so: cannot restore segment prot after reloc: Operation not permitted
My understanding is that systemd runs binaries in an environment that clashes with a relocation that is used in
libarmmem.so. That is either a bug in systemd (version 234-3 here), or in the package that provides
raspi-copies-and-fills, version 0.6 from stretch here).
systemd of course is essential, while
raspi-copies-and-fills is not (it's an important optimization, but the system can run without it). I solved my problem with the following interim solution:
root@raspberrypi:/home/pi# apt purge raspi-copies-and-fills
Clearly, I'll monitor the possible updates to
raspi-copies-and-fills (so far at version 0.6), hoping to get both a bootable system and the fast