Что вызывает отказ в разрешении на монтирование rootfs, home, очереди сообщений, файловой системы ядра во время загрузки?
Я не думаю, что есть одношаговый способ сделать это с одним Клиппером. Если вы посмотрите на его настройки ярлыков, есть только ограниченное количество команд, доступных для привязки к клавишам. Возможно, вы можете настроить что-то в «Действиях», но вам все равно понадобится одно нажатие клавиши для «Вызов действия в текущем буфере обмена вручную», а другое - для фактической вставки. Я думаю, что ваше единственное пошаговое решение - это самостоятельно создать независимую команду.
Например, вы можете установить xvkbd , а затем связать следующее с сочетанием клавиш:
xclip -o -selection clipboard | xclip -selection clipboard | xvkbd -xsendevent -text "\\Cv" 2>/dev/null
Он читает из буфера обмена (в виде обычного текста), направляет его обратно в буфер обмена, затем вызывает Ctrl + v , чтобы вставить его.
Несколько предостережений:
- При этом содержимое буфера обмена заменяется на "обычную" версию.
- Это зависит от сочетания клавиш для вставки Ctrl + v , что может быть неверным (например, в некоторых эмуляторах терминала).
Проблема была вызвана неправильным контекстом файла /usr/bin/mount:samba_share_t.
Изменение контекста файла было вызвано не какой-то ошибкой из-за полной перезагрузки, а... моим неосторожным решением последовать первому предложению SELinux Alert Browser. Смотрите скриншот ниже.
Это первое предложение состояло в том, чтобы изменить контекст файла /usr/bin/mountна samba_share_t, чтобы разрешить smbd доступ к getattr.
Решение было:
- удалить неверный контекст файла, восстановить значение по умолчанию и переименовать файл :
[root@atlas ~]# ls -Z /usr/bin/mount system_u:object_r:samba_share_t:s0 /usr/bin/mount [root@atlas ~]# semanage fcontext -d /usr/bin/mount [root@atlas ~]# restorecon -v /usr/bin/mount Relabeled /usr/bin/mount from system_u:object_r:samba_share_t:s0 to system_u:object_r:mount_exec_t:s0 [root@atlas ~]# ls -Z /usr/bin/mount system_u:object_r:mount_exec_t:s0 /usr/bin/mount - перезагрузить систему.
Это можно сделать в аварийной консоли, но я использовал консоль, чтобы перевести SELinux в разрешающий режим, загрузить систему и затем изменить контекст файла, как описано выше.
Когда я проверил измененные контексты файлов SELinux (, см. стр. 10 моего первоначального поста )я заметил, что контекст монтирования выглядит подозрительно. На данный момент я понял, что незадолго до того, как проблема началась, я неосторожно последовал первому предложению SELinux Alert Browser изменить контекст файла монтирования. Такое же предложение появилось сейчас, после восстановления и перезапуска системы, поэтому я смог прикрепить скриншот ниже.
Спасибо @sourcejedi за указание на то, что SELinux может быть причиной проблемы, и за его любезную помощь!