Проблемы с udev
Перезагрузите систему в режиме восстановления с установочного диска.
Затем установите grub.
update-grub
grub-install <device name of your ubuntu installation>
Проблема со вторым вариантом заключалась в том, что мне приходилось использовать полные пути
ACTION=="add", SUBSYSTEM=="block",TAG+="systemd", RUN+="/bin/systemctl start sd-automounter@%k"
ACTION=="change", SUBSYSTEM=="block",TAG+="systemd", RUN+="/bin/systemctl start sd-automounter@%k"
и используйте опцию запуска также для добавления
systemd-udevна самом деле больше не хочет, чтобы вы монтировали файловые системы непосредственно из правила. Много вопросов по этому поводу можно найти на этом сайте :-).
В последних версиях systemd служебный файл udev имеет SystemCallFilter=@system-service @module @raw-io. Это не позволяет выполнять системные вызовы, необходимые для монтирования файловой системы.
(Кроме того, я считаю, что существует общий конфликт с systemd, если вы когда-либо напрямую используете mountдля файловой системы FUSE, например. ntfs-3g. Если вы запускаете серверный процесс FUSE, лучше всего, чтобы он находился в выделенном модуле systemd, таком как модуль .mount. Если вы позволите процессу FUSE оставаться внутри вашего текущего модуля, то время жизни процесса FUSE будет связано со временем жизни модуля, который вы используете в ).
Чтобы избежать будущих (или текущих )проблем с командами в RUN+=, ваше правило может вместо этого использовать ENV{SYSTEMD_WANTS}=my-automounter@%k.service, а затем
# /etc/systemd/system/my-automounter@.service
[Service]
Type=oneshot
ExecStart=/usr/local/libexec/my-automounter %I
#!/bin/sh
# /usr/local/libexec/my-automounter
DEV=/dev/"$1"
# You can make this script as complicated as you want.
# You can read udev properties if you want, using
# eval "$(udevadm info --query=property --export "$DEV")"
...
Если вы хотите протестировать вызов устройства вручную, вы можете использовать systemctl start my-automounter@sdc1.
Если во время запуска сценария systemd возникает ошибка, вы можете просмотреть сообщения об ошибках, используя systemctl status my-automounter@*или journalctl -b -u my-automounter@*.
Это также избавляет вас от необходимости иметь дело сudev-конкретными сообщениями об ошибках. Я думаю, что и sh, и systemdимеют полезные отчеты об ошибках на случай внезапной остановки программы. Например.они должны сообщить, если программа была убита сигналом SIGSYSиз-за попытки вызвать системный вызов, заблокированный с помощью SystemCallFilter=:-).