Вопросы Теги

Не удается удалить журнал ошибок 750G, созданный после изменения разрешения для / usr / bin / (sudo не разрешено)

Таким образом, вам нужно сделать какой-то супер подлый материал, но в итоге он будет работать. Первый шаг - убедиться, что установлен Alsa. Затем откройте файл 

sudo gedit /etc/modprobe.d/alsa-base.conf

В нижней части страницы вставьте новую строку: 

options snd-hda-intel model=auto

Сохраните и перезапустите! После этого он должен работать нормально. Удачи!

1
задан 5 September 2017 в 17:48

6 ответов

Я столкнулся с той же проблемой для ubuntu 16.04 после изменения разрешения группы. Некоторое время назад мне удалось получить права root через терминал после запуска режима восстановления.

Попробуйте ввести sudo su или su,, а затем nautilus. Имея эти разрешения, вы можете удалить эти файлы. Но, как и вы, я не понял постоянного увеличения GB в ноутбуке. Для меня, кажется, увеличивается на 100 ГБ после 1 часа использования.

Я знаю, что это не правильный ответ, но у меня недостаточно очков для ответа на другие ответы.

Кстати, если есть решение остановить увеличивающиеся файлы error_log, дайте мне знать. Самый простой способ - переустановка ubuntu, но это не идея.

С уважением

0
ответ дан 18 July 2018 в 07:33

Чтобы попытаться восстановить систему в полу-работоспособное состояние ...

Если это не сработает, вам просто нужно переустановить Ubuntu ...

boot в меню GRUB выберите «Дополнительные параметры», выберите «Режим восстановления», выберите «Корневой доступ» в строке # приглашения

:

mount -o rw,remount / #, чтобы перемонтировать диск как r / w

rm -i /var/log/cups/error_log # удалить большой файл журнала

rm -i /var/log/cups/error_log.1 # удалить большой файл журнала

chmod -R 755 /usr/bin # попытаться поместить / usr / bin обратно в нечто близкое к normal

chmod u+s /usr/bin/sudo # setuid on sudo command

chown root:root /usr/bin/sudo # на всякий случай, это тоже испортилось

reboot # перезагрузить компьютер

Обновление # 1:

Обновление # 1: . Вы внесли больше изменений в свою систему, чем мы знали, и исправление ее кусочка просто не сработает. Снимите флажок формата и сохраните текущий / домашний каталог.

0
ответ дан 18 July 2018 в 07:33

Ну, «решение» должно быть не так уж плохо.

Загрузите Live Flash Drive / CD или в режим восстановления и удалите большие файлы журналов. Чтобы удалить файлы, вам необходимо перемонтировать корневую файловую систему rw mount -o remount,rw / . Подробнее см. Https://wiki.ubuntu.com/RecoveryMode. Если вы сейчас используете режим перезагрузки Flash / USB для восстановления. Если вы уже находитесь в режиме восстановления, продолжайте работу с apt-get --reinstall install \`dpkg --get-selections | grep install | grep -v deinstall | cut -f1\` . Подробнее см. На странице http://hyperlogos.org/page/Restoring-Permissions-Debian-System
1
ответ дан 18 July 2018 в 07:33

Я столкнулся с той же проблемой для ubuntu 16.04 после изменения разрешения группы. Некоторое время назад мне удалось получить права root через терминал после запуска режима восстановления.

Попробуйте ввести sudo su или su,, а затем nautilus. Имея эти разрешения, вы можете удалить эти файлы. Но, как и вы, я не понял постоянного увеличения GB в ноутбуке. Для меня, кажется, увеличивается на 100 ГБ после 1 часа использования.

Я знаю, что это не правильный ответ, но у меня недостаточно очков для ответа на другие ответы.

Кстати, если есть решение остановить увеличивающиеся файлы error_log, дайте мне знать. Самый простой способ - переустановка ubuntu, но это не идея.

С уважением

0
ответ дан 24 July 2018 в 18:49

Чтобы попытаться восстановить систему в полу-работоспособное состояние ...

Если это не сработает, вам просто нужно переустановить Ubuntu ...

boot в меню GRUB выберите «Дополнительные параметры», выберите «Режим восстановления», выберите «Корневой доступ» в строке # приглашения

:

mount -o rw,remount / #, чтобы перемонтировать диск как r / w

rm -i /var/log/cups/error_log # удалить большой файл журнала

rm -i /var/log/cups/error_log.1 # удалить большой файл журнала

chmod -R 755 /usr/bin # попытаться поместить / usr / bin обратно в нечто близкое к normal

chmod u+s /usr/bin/sudo # setuid on sudo command

chown root:root /usr/bin/sudo # на всякий случай, это тоже испортилось

reboot # перезагрузить компьютер

Обновление # 1:

Обновление # 1: . Вы внесли больше изменений в свою систему, чем мы знали, и исправление ее кусочка просто не сработает. Снимите флажок формата и сохраните текущий / домашний каталог.

0
ответ дан 24 July 2018 в 18:49
  • 1
    Благодарю. Я позволю вам во вторник, работает ли это предложение или нет. – user11 3 September 2017 в 15:34
  • 2
    Команда chmod и chown, которую вы предложили, не вернулась к нормальным разрешениям. Мне удалось войти в систему, но те же файлы журнала ошибок продолжали быстро увеличиваться, поэтому мне пришлось снова выйти из системы и вернуться в режим восстановления, чтобы удалить их. – user11 5 September 2017 в 15:24
  • 3
    Даже находясь в командной строке оболочки, я не могу сделать sudo service cups stop. Он вызывает ту же ошибку об ..must be owned by uid 0. Плюс, всякий раз, когда я пытаюсь перезагрузить и вводить ваши предложенные команды, корневая оболочка иногда просто исчезает и начинает что-то загружать ... когда она возвращается, она накладывается на другие команды на экране. – user11 5 September 2017 в 15:39
  • 4
    @ user11 Не пытайтесь использовать sudo в корневой среде восстановления. Используйте команды, как я их показал. Удалите файлы журнала снова, попробуйте systemctl stop cups, а затем остальные команды. Загрузите фотографии на экране, чтобы увидеть, столкнулись ли вы с бедой. Скажите мне ТОЧНО, какие команды дают вам проблемы и сообщение об ошибке. – heynnema 5 September 2017 в 17:24
  • 5
    Когда я вхожу в ОС, sudo не работает даже после того, как я реализую ваши команды в корневой оболочке. – user11 5 September 2017 в 17:29

Ну, «решение» должно быть не так уж плохо.

Загрузите Live Flash Drive / CD или в режим восстановления и удалите большие файлы журналов. Чтобы удалить файлы, вам необходимо перемонтировать корневую файловую систему rw mount -o remount,rw / . Подробнее см. Https://wiki.ubuntu.com/RecoveryMode. Если вы сейчас используете режим перезагрузки Flash / USB для восстановления. Если вы уже находитесь в режиме восстановления, продолжайте работу с apt-get --reinstall install \`dpkg --get-selections | grep install | grep -v deinstall | cut -f1\` Подробнее см. На странице http://hyperlogos.org/page/Restoring-Permissions-Debian-System
1
ответ дан 24 July 2018 в 18:49
  • 1
    Что делать, если есть модули DKMS? Или это только материал dpkg, который нужно переустановить? – WinEunuuchs2Unix 1 September 2017 в 22:43
  • 2
    Вам нужно будет вручную исправить что-либо, установленное вне apt (apt-get / dpkg), включая модули DKMS, но вы, по крайней мере, будете иметь мощность sudo, и ваша бастовая система должна работать. – Panther 1 September 2017 в 22:47
  • 3
    @ bodhi.zazen Это не будет работать, как показано, потому что вы загрузились на Ubuntu Live DVD / USB и / не на жесткий диск. Режим восстановления также не работает из-за разрешений на / usr / bin. apt-get тоже не работает. Может быть, chroot, а затем chmod -R / usr / bin на жестком диске? – heynnema 2 September 2017 в 01:44
  • 4
    @heynnema не будет ли это chmod a+r /usr/bin вместо этого? В конце концов, он убрал разрешения на чтение с -r, которые начали фиаско, не так ли? – WinEunuuchs2Unix 2 September 2017 в 03:04
  • 5
    @ WinEunuuchs2Unix Я не дал полную и правильную команду chmod, поскольку я решил, что бодхи.зазен поймет мое намерение. -R был для рекурсивного, как первоначально это сделал OP. Хороший улов, хотя! – heynnema 2 September 2017 в 03:23

Другие вопросы по тегам:

Похожие вопросы: