«Добро пожаловать в аварийный режим!» Думаю, это проблема fsck

Фрагмент journalctl -xb (что я считаю неправильным, он был хотя бы красным):

-- Unit systemd-fsckd.service has begun starting up.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: /dev/sdb1 contains a file system with errors, check forced.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: /dev/sdb1: Inodes that were part of a corrupted orphan linked list found.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: /dev/sdb1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: (i.e., without -a or -p options)
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: fsck failed with error code 4.
juli 09 15:40:16 kim-SSD-Sationary systemd-fsck[414]: Running request emergency.target/start/replace
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: systemd-fsck-root.service: main process exited, code=exited, status=1/FAILURE
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: Failed to start File System Check on Root Device.
-- Subject: Unit systemd-fsck-root.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit systemd-fsck-root.service has failed.
-- 
-- The result is failed.
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: Unit systemd-fsck-root.service entered failed state.
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: systemd-fsck-root.service failed.
juli 09 15:40:16 kim-SSD-Sationary systemd[1]: Starting Remount Root and Kernel File Systems...
-- Subject: Unit systemd-remount-fs.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Проигнорировали другие ошибки, такие как: сбой зонда ACPI PCC. NVIDIA не пропатентованный и т. Д.

РЕДАКТИРОВАТЬ: я могу получить доступ к своему компьютеру, нажав Ctrl+ D, но это раздражает.

Вы можете запустить fsckиз Ubuntu Live.

1. Включите свой компьютер. Загрузитесь с Ubuntu Live DVD / USB (попробуйте без установки).
2. После загрузки откройте терминал, нажав Ctrl+ Alt+T

3. В терминале запустите:

   sudo -i
   fdisk -l
   

   fdiskсообщит вам, как /называется ваш раздел (root). В этом вопросе это так /dev/sdb1.

   Затем вы должны продолжить, запустив:

   umount /dev/sdb1
   fsck -y /dev/sdb1
   poweroff
   

   Если umountкоманда жалуется, что sdb1она «не смонтирована», это не проблема. Мы хотели, чтобы это было "не установлено" :).

4. Удалить DVD / USB. Снова включите компьютер, чтобы загрузиться с SSD.

Я не знаю, решили ли вы свою проблему. Что я сделал, это:

sudo nano /etc/fstab

Затем удалите то, что вы там добавили, sdb1и запустите:

sudo systemctl reboot

Он говорит, что он поврежден, так что я не знаю, что об этом, но я надеюсь, что это может помочь кому-то, кто не может запустить свой Linux.

У меня просто был случай с аварийным режимом. В моей ситуации я следовал руководству по установке, в котором предлагалось отредактировать некоторые параметры для моих точек монтирования /etc/fstab. Удалив лишние опции, мой сервер перезагрузился без проблем.

Я использую Windows 10 и систему двойной загрузки Ubuntu 16.X.

Я не смог смонтировать один из ntfs разделов, и ошибка была связана с выключением / спящим режимом Windows. Я использовал, sudo ntfsfix /dev/sda3чтобы исправить проблему. Я смог смонтировать ntfs раздел sda3, но при перезапуске Ubuntu запускался в аварийном режиме.
Чтобы устранить эту проблему, выполните следующую команду в Windows

shutdown /s /t 5

Это исправляет проблему аварийного запуска Ubuntu.

Ответы Хушбу Рани и Кагана Арслана привели меня к окончательному решению.

В Windows 10 по умолчанию включена функция быстрой загрузки , которая, когда пользователь обычно выключается с помощью кнопки «выключить» или кнопки питания на компьютере, фактически сохраняет работающее ядро ​​и некоторые другие системные компоненты на жесткий диск, аналогичный в спящий режим после выхода из системы. Это также заставляет Windows «блокировать» раздел тем или иным способом, чтобы предотвратить повреждение данных, случайное или злонамеренное. Это означает, что Ubuntu не может смонтировать раздел Windows во время запуска.

В моем случае у меня есть записи для раздела Windows в / etc / fstab, так что Ubuntu не загружается.

Решение состоит в том, чтобы загрузиться в Windows, отключить «быструю загрузку», а затем нормально завершить работу. Теперь проблема должна быть решена навсегда!

Из ссылки, которой я поделился ранее, отключите быструю загрузку в Windows следующим образом:

1. Запустите панель управления
2. Зайдите в настройки «Оборудование и звук»
3. Перейти к «Параметры электропитания»
4. Нажмите «Выбрать, что делают кнопки питания»
5. Нажмите «Изменить настройки, которые в данный момент недоступны» и предоставьте доступ UAC.
6. Снимите флажок с помощью параметра «Включить быстрый запуск (рекомендуется)»

В моем случае (Dual Boot Windows 10) мне пришлось правильно закрыть Windows с помощью команды (на окнах):

shutdown /s /t 5

Когда я перезагружаюсь, Ubuntu загружается без проблем.

У меня точно такая же проблема была при загрузке Ubuntu LTS 16.04 с флешки. Выполнение sysctl defaultне исправило, fsckвскоре вспыхнуло с сообщением о прогрессе сканирования, а затем появилось то же приглашение. Вот что сработало:

fsck -y /dev/sda1
reboot

Если это происходит в виртуальной машине VirtualBox, то, возможно, ей не удалось смонтировать один из разделов /etc/fstab- к сожалению, произойдет сбой с «Добро пожаловать в аварийный режим!» даже если это не критический раздел - поэтому, если вы добавили неверно сформированную запись, чтобы попытаться смонтировать файловую систему, используя vboxsfее, вся система не сможет загрузиться, не сделав в журнале загрузки четкого представления о том, что это главная проблема.

В любом случае, чтобы устранить проблему, вам нужно либо закомментировать ошибочную запись, /etc/fstabлибо изменить ее так, чтобы mountона вас устраивала.

Подобно некоторым другим ответам, уловка для меня заключалась в том, чтобы закомментировать запись /etc/fstabдля моего дополнительного раздела LVM. Я не знаю, почему несколько дней назад он начал жаловаться на то, что Ubuntu 17.10 больше не может найти раздел LVM, и почему это заставляет систему загружаться в «аварийном» режиме.

Как только запись была закомментирована /etc/fstab, я успешно перезагрузил свой рабочий стол. Просматривая некоторые учебники, я заметил, что мне не хватает некоторых команд LVM, поэтому я запустил программу, sudo apt-get install lvm2которая, похоже, устранила проблему.

Если, как и я, вы считаете, что причиной проблемы является раздел LVM, я выполнил полный набор команд:

sudo lvmdiskscan
sudo apt-get install lvm2
sudo lvmdiskscan
sudo lvdisplay
sudo vi /etc/fstab
sudo vgchange -a y
sudo mount -a

Не уверен, что все это необходимо - я подозреваю, что это apt-get install lvm2было ключом к загрузке моей системы снова.

У меня была такая же проблема, после запуска команды fsck он восстанавливался, но через некоторое время мой компьютер снова перешел в аварийный режим, поэтому я удалил все данные с жесткого диска и установил новую ОС. Это решило мою проблему. Я думаю, что проблема была с яркой версией Ubuntu 15.0, поэтому я установил версию 14.0. Все еще нет проблем.

Я была такая же проблема. Прокомментированные вручную разделы ntfs из / etc / fstab Система запустилась нормально. Использовал команду ntfsfix для исправления проблемы журналирования, вызванной этими разделами ntfs. Например: Sudo ntfsfix / Dev / ntfs раздел, снова смонтированный в / etc / fstab Reboot

Поэтому здесь есть много хороших ответов - просто чтобы добавить информацию, моя проблема заключалась в том, что я записал tmpfs как tempfs, что неверно в строке, которую я добавил в / etc / fstab для защиты сервера.

У меня просто была та же проблема, и в моем случае я только что воссоздал свой раздел grub, и поэтому у него был другой UUID, чем в последнем разделе grub, который у меня был. Когда я загрузил Ubuntu, система не смогла бы проверить UUID. Чтобы исправить эту проблему я сделал:

sudo nano /etc/fstab

Затем закомментируйте строку, содержащую UUID из раздела, который я только что изменил.

затем rebootприменить изменения.

Все приведенные выше ответы мне не помогли, так как у меня не было файла восстановления для fstab.
Что сделал трюк (в аварийном режиме)

cat /proc/mounts > /etc/fstab