Как исправить & ldquo; sulogin: не могу прочитать / dev / tty7: операция не разрешена & rdquo; при загрузке - 17.10 внешний привод

Вы можете установить пакет network-manager-openvpn-gnome, чтобы включить OpenVpn GUI в Ubuntu или других Linux, у которых есть network-manager:

sudo apt-get install network-manager-openvpn-gnome
1
задан 8 November 2017 в 02:11

3 ответа

UPDATE 20180327: Недавно я встретил довольно эзотерическую команду, которая в течение последних двух недель исправила мои проблемы с запуском. Вот что я сделал ...

Удерживайте ALT + SysRq (на моем ноутбуке, SysRq - это функциональный ключ в END), затем, удерживая все эти клавиши, МЕДЛЕННО - подождите секунду или два между каждый ключ - введите REISU B. Это приведет к ряду вещей, включая перезагрузку компьютера. И вуаля! Последние две недели я был без проблем.

Итак, что именно это делает?

R: переключить клавиатуру из режима raw в режим XLATE E: отправить сигнал SIGTERM ко всем процессам, кроме init I: отправить сигнал SIGKILL всем процессы, кроме init S: Синхронизация всех смонтированных файловых систем U: Переустановка всех смонтированных файловых систем в режиме только для чтения B: Немедленно перезагрузите систему без размонтирования разделов или синхронизации. Если вы хотите выключить компьютер, введите O вместо этого.

UPDATE 20171120: Кажется, что существует повторяющаяся проблема с / dev / sdb3, где inodes становятся сиротами. Всякий раз, когда система загружается в режиме обслуживания, выполнение следующего последовательно исправляет проблему:

$ umount /dev/sdb3 # as a precaution, sdb3 is usually not mounted yet
$ fsck -y /dev/sdb3

Это обычно возвращает уведомление о том, что «Свободные блоки подсчитываются неправильно ...», тогда «Свободные индексы ошибочны. .. », за которым следует исправление.

Почему система регулярно путает это, жюри все еще не работает. Но в то же время это исправляет систему и возвращает все в рабочий режим.

UPDATE 20171113: Welp ... Оказывается, этот ответ был в лучшем случае временной мерой. .. Система будет загружаться несколько раз подряд без проблем. Но затем, казалось бы, из ниоткуда, он начнет загружаться в режим обслуживания. Тогда единственное «исправление» - это загрузка в режим восстановления и запуск контрольного диска. И если это не исправляет загрузку по умолчанию, тогда загрузите live CD и запустите полную проверку fsck.

Тот факт, что система отлично работала в режиме восстановления, заставила меня уверенно, что диск не был поврежден. Кроме того, поскольку видеодрайверы не полностью загружены в режиме восстановления, это заставило меня подозревать, что это как-то связано с встроенным чипом AMD Radeon на моем ноутбуке.

В результате я обнаружил следующую команду:

$ unbuntu-drivers devices

В этой команде перечислены доступные пакеты, которые соответствуют аппаратным средствам системы. В моем случае этот список «amd64-microcode». После установки этого пакета я больше не сталкивался с проблемами при загрузке (стук по дереву). Я повторил тот же процесс, когда привод подключен к моему основному рабочему столу, поэтому диск должен быть полностью готов к работе в обеих средах.

0
ответ дан 22 May 2018 в 16:25

UPDATE 20180327: Недавно я встретил довольно эзотерическую команду, которая в течение последних двух недель исправила мои проблемы с запуском. Вот что я сделал ...

Удерживайте ALT + SysRq (на моем ноутбуке, SysRq - это функциональный ключ в END), затем, удерживая все эти клавиши, МЕДЛЕННО - подождите секунду или два между каждый ключ - введите REISU B. Это приведет к ряду вещей, включая перезагрузку компьютера. И вуаля! Последние две недели я был без проблем.

Итак, что именно это делает?

R: переключить клавиатуру из режима raw в режим XLATE E: отправить сигнал SIGTERM ко всем процессам, кроме init I: отправить сигнал SIGKILL всем процессы, кроме init S: Синхронизация всех смонтированных файловых систем U: Переустановка всех смонтированных файловых систем в режиме только для чтения B: Немедленно перезагрузите систему без размонтирования разделов или синхронизации. Если вы хотите выключить компьютер, введите O вместо этого.

UPDATE 20171120: Кажется, что существует повторяющаяся проблема с / dev / sdb3, где inodes становятся сиротами. Всякий раз, когда система загружается в режиме обслуживания, выполнение следующего последовательно исправляет проблему:

$ umount /dev/sdb3 # as a precaution, sdb3 is usually not mounted yet $ fsck -y /dev/sdb3

Это обычно возвращает уведомление о том, что «Свободные блоки подсчитываются неправильно ...», тогда «Свободные индексы ошибочны. .. », за которым следует исправление.

Почему система регулярно путает это, жюри все еще не работает. Но в то же время это исправляет систему и возвращает все в рабочий режим.

UPDATE 20171113: Welp ... Оказывается, этот ответ был в лучшем случае временной мерой. .. Система будет загружаться несколько раз подряд без проблем. Но затем, казалось бы, из ниоткуда, он начнет загружаться в режим обслуживания. Тогда единственное «исправление» - это загрузка в режим восстановления и запуск контрольного диска. И если это не исправляет загрузку по умолчанию, тогда загрузите live CD и запустите полную проверку fsck.

Тот факт, что система отлично работала в режиме восстановления, заставила меня уверенно, что диск не был поврежден. Кроме того, поскольку видеодрайверы не полностью загружены в режиме восстановления, это заставило меня подозревать, что это как-то связано с встроенным чипом AMD Radeon на моем ноутбуке.

В результате я обнаружил следующую команду:

$ unbuntu-drivers devices

В этой команде перечислены доступные пакеты, которые соответствуют аппаратным средствам системы. В моем случае этот список «amd64-microcode». После установки этого пакета я больше не сталкивался с проблемами при загрузке (стук по дереву). Я повторил тот же процесс, когда привод подключен к моему основному рабочему столу, поэтому диск должен быть полностью готов к работе в обеих средах.

0
ответ дан 18 July 2018 в 03:41

UPDATE 20180327: Недавно я встретил довольно эзотерическую команду, которая в течение последних двух недель исправила мои проблемы с запуском. Вот что я сделал ...

Удерживайте ALT + SysRq (на моем ноутбуке, SysRq - это функциональный ключ в END), затем, удерживая все эти клавиши, МЕДЛЕННО - подождите секунду или два между каждый ключ - введите REISU B. Это приведет к ряду вещей, включая перезагрузку компьютера. И вуаля! Последние две недели я был без проблем.

Итак, что именно это делает?

R: переключить клавиатуру из режима raw в режим XLATE E: отправить сигнал SIGTERM ко всем процессам, кроме init I: отправить сигнал SIGKILL всем процессы, кроме init S: Синхронизация всех смонтированных файловых систем U: Переустановка всех смонтированных файловых систем в режиме только для чтения B: Немедленно перезагрузите систему без размонтирования разделов или синхронизации. Если вы хотите выключить компьютер, введите O вместо этого.

UPDATE 20171120: Кажется, что существует повторяющаяся проблема с / dev / sdb3, где inodes становятся сиротами. Всякий раз, когда система загружается в режиме обслуживания, выполнение следующего последовательно исправляет проблему:

$ umount /dev/sdb3 # as a precaution, sdb3 is usually not mounted yet $ fsck -y /dev/sdb3

Это обычно возвращает уведомление о том, что «Свободные блоки подсчитываются неправильно ...», тогда «Свободные индексы ошибочны. .. », за которым следует исправление.

Почему система регулярно путает это, жюри все еще не работает. Но в то же время это исправляет систему и возвращает все в рабочий режим.

UPDATE 20171113: Welp ... Оказывается, этот ответ был в лучшем случае временной мерой. .. Система будет загружаться несколько раз подряд без проблем. Но затем, казалось бы, из ниоткуда, он начнет загружаться в режим обслуживания. Тогда единственное «исправление» - это загрузка в режим восстановления и запуск контрольного диска. И если это не исправляет загрузку по умолчанию, тогда загрузите live CD и запустите полную проверку fsck.

Тот факт, что система отлично работала в режиме восстановления, заставила меня уверенно, что диск не был поврежден. Кроме того, поскольку видеодрайверы не полностью загружены в режиме восстановления, это заставило меня подозревать, что это как-то связано с встроенным чипом AMD Radeon на моем ноутбуке.

В результате я обнаружил следующую команду:

$ unbuntu-drivers devices

В этой команде перечислены доступные пакеты, которые соответствуют аппаратным средствам системы. В моем случае этот список «amd64-microcode». После установки этого пакета я больше не сталкивался с проблемами при загрузке (стук по дереву). Я повторил тот же процесс, когда привод подключен к моему основному рабочему столу, поэтому диск должен быть полностью готов к работе в обеих средах.

0
ответ дан 24 July 2018 в 17:54

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

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