При загрузке выдает ошибку
Автор alexwale, 24 февраля 2019, 12:54:09
« назад — далее »
0 Пользователи и 1 гость просматривают эту тему.
Доброго времени суток!
Случилось нехорошее и непонятное. Debian 9 Stable стоит на внешнем HDD. Перед ошибкой тестировал один Live CD с Windows и использовал chkdsk для проверки на битые сектора и ошибки. После перезагрузки выходит вот это (см. фото):
fsck exited with status code 8.
В Linux я новичок и что могло привести к этой ошибке не понимаю, помогите пожалуйста.
Ошибка на жестком диске.
1) возможно некорректное последнее выключение питания ПК
2) возможно помирает hdd
Загрузиться с live-образа и проверить диск.
Тест на битые сектора должно быть удался? К сожалению это ошибка чтения записи диска, на время лечится низкоуровневым форматированием но не на долго….
Из личных наблюдений выносные диски ходят очень мало, вангую что китайцы пихают в контейнеры самый брак плюс хз как там паркуются головки при выключении.
Русские дебианщики против цифрового слабоумия !
Цитата: alexwale от 24 февраля 2019, 12:54:09что могло привести к этой ошибке не понимаю
Не пугайся, бывает. Просто контрольная сумма суперблока не совпала, а в нем информация о разделе хранится, система не грузится чтобы не затереть твои данные. Тебе надо запустить проверку файловой системы, восстановить суперблок из резервной копии (их 2 или 3 копии на диске обычно), и загрузить систему. У меня такое и на hdd и на ssd бывало после обновления. Когда загрузится система, надо будет обновить конфиги grub и initramfs. Как это сделать напишу чуть позже.
А можешь сказать как именно это сделать?
ЦитироватьТебе надо запустить проверку файловой системы, восстановить суперблок из резервной копии (их 2 или 3 копии на диске обычно), и загрузить систему.
Или где почитать инструкции о том как это делается. А то я не знаю)
alexwale, так на ваших скринах написано как.
Цитата: alexwale от 24 февраля 2019, 22:37:13А можешь сказать как именно это сделать?
Тебе уже ответили)
Цитата: qupl от 25 февраля 2019, 10:59:44так на ваших скринах написано как.
e2fsck -y /dev/sdb
или
e2fsck -b 8193 /dev/sdb
Потом надо будет нажать Enter и система должна загрузиться.
Уже в загруженной системе обнови пакеты и систему:
sudo apt update && sudo apt upgrade && sudo apt install -f
sudo update-initramfs -u && sudo update-grub
Ну и попробуй перезагрузиться когда все операции завершатся.
Если что — пиши)
Сделал все по инструкции… Но почему-то не хочет.
Цитата: alexwale от 27 февраля 2019, 21:14:10Сделал все по инструкции… Но почему-то не хочет
По какой инструкции, что не хочет?
У путных людей как правило linux устанавливается на двух разделах / и /home , дополнительно swop
При проблеме с корневой файловой системой хрен вы восстановитесь даже с безопасного режима так как утилита e2fsck работает только с отмонтированным разделом, по сему берём живой диск или загрузочную флешку с Debian/ubuntu или что то из этой оперы, загружаемся, открываем терминал и смотрим вывод
sudo fdisk -l
По выхлопу у вас винт висит на втором sata и скорее всего ( сами увидите) корень будет /dev/sdb2 а хомяк /dev/sda6
По сему сначала отсортируете корень
sudo umount /dev/sdb2
sudo e2fsck -b /dev/sdb2
потом то же делаете с хомяком и пробуете грузиться с винта.
Русские дебианщики против цифрового слабоумия !
То ли я дурак, то ли лыжи не едут (скорее первое).
Загрузился с Linux Mint (был диск под рукой)
sudo fdisck -l вот что показал
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcebf0ba6
Device Boot Start End Sectors Size Id Type
/dev/sdb1 978942 1953523711 1952544770 931G 5 Extended
/dev/sdb2 * 2048 976895 974848 476M 83 Linux
/dev/sdb5 303321088 1953523711 1650202624 786.9G b W95 FAT32
/dev/sdb6 978944 59570175 58591232 28G 83 Linux
/dev/sdb7 59572224 67383295 7811072 3.7G 82 Linux swap / Solaris
/dev/sdb8 67385344 165040127 97654784 46.6G 83 Linux
Partition table entries are not in disk order.
Попытался отмонтировать сначала корень и проделать указанные выше оперции.
mint@mint ~ $ sudo umount /dev/sdb6
umount: /dev/sdb6: not mounted
mint@mint ~ $ sudo e2fsck -b /dev/sdb6
Invalid non-numeric argument to -b ("/dev/sdb6")
mint@mint ~ $ sudo e2fsck -y /dev/sdb6
e2fsck 1.42.13 (17-May-2015)
/dev/sdb6 has unsupported feature(s): metadata_csum
e2fsck: Get a newer version of e2fsck!
Попоробовал с boot.
mint@mint ~ $ sudo umount /dev/sdb2
mint@mint ~ $ sudo e2fsck -y /dev/sdb2
e2fsck 1.42.13 (17-May-2015)
boot: clean, 338/121920 files, 67117/487424 blocks
Если открывать эти разделы через файловый менеджер вот что пишет:
Ну раз загрузился с лайва, то для начала покажи данные смарт:
sudo apt install smartmontools
sudo smartctl -a /dev/sdb
Русские дебианщики против цифрового слабоумия !
Первое (смарт):
mint@mint ~ $ sudo smartctl -a /dev/sdb
smartctl 6.5 2016-01-24 r4214 [i686-linux-4.8.0-53-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
/dev/sdb: Unknown USB bridge [0x0480:0xb206 (0x000)]
Please specify device type with the -d option.
Use smartctl -h to get a usage summary
mint@mint ~ $ sudo smartctl -a /dev/sdb6
smartctl 6.5 2016-01-24 r4214 [i686-linux-4.8.0-53-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Vendor: TOSHIBA
Product: External USB 3.0
Revision: 0
Compliance: SPC-4
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Logical block size: 512 bytes
Logical Unit id: 0x41736d6564696120
Serial number: F19361092507102
Device type: disk
Local Time is: Thu Feb 28 17:51:06 2019 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Temperature Warning: Disabled or Not Supported
=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Error Counter logging not supported
Device does not support Self Test logging
Второе:
sudo nautilus
Ничего нет. При отключении и подключении диска выдает такую же ошибку, как и в прошлый раз. Показывает только мой раздел с документами и раздел boot.
«Если достаточно долго сидеть возле реки — мимо проплывет труп твоего врага»
В своей работе мне приходилось неоднократно сталкиваться с проблемой загрузки Linux в аварийном режиме с ошибкой Welcome to emergency mode. Чаще всего проблема возникает при аварийном отключении питания на сервере, при краше системы или других подобных воздействиях. В 90% случаев это ошибка связана с повреждением файловой системы Linux, которую можно решить.
В данной статье мы рассмотрим варианты решения подобной проблемы, их может быть несколько.
Содержание:
- Исправляем ошибки файловой системы с помощью LiveCD
- Проблема с монтирование в fstab
- Linux установлен с USB флешки
- Dualboot конфигурация Windows и Linux
Исправляем ошибки файловой системы с помощью LiveCD
Рассмотрим пример, когда у вас был какой-то сбой на сервере, например, аварийное отключение питания и при загрузке Linux сервера в remote console или vnc, вы видите следующую картину:
Welcome to emergency mode! After logging in, type “journalctl -xb” to view system logs, “systemctl reboot” to reboot, “systemctl default” or ^D to try again boot into default mode. Give root password for maintained (or press Control-D to continue).
Аварийный режим emergency mode обеспечивает минимально возможную среду Linux для восстановления система, если ОС не может войти в режим восстановления (Rescue mode). В аварийном режиме система монтирует корневую файловую систему на для чтение. Другие локальные файловые системы не монтируются, сетевые интерфейсы не поднимаются.
Если нажать сочетание клавиш Control + D, то начинается загрузка системы, но в конечном итоге все возвращается к тому же Emergency mode:
Чтобы решить данную проблему, вам нужно загрузиться на сервере с LiveCD или LiveUSB и использовать утилиту SystemRescueCd. Я загрузил образ с утилитой systemrescuecd:
Теперь запустите проверку файловой системы сервера с исправлением всех найденных ошибок с помощью команды:
# fsck -y /dev/sda1
— где sda1 ваш раздел диска.
Проверку нужно выполнить со всеми разделами, после чего выполнить рестарт системы и в большинстве случаев, это решает вашу проблему.
Проблема с монтирование в fstab
Второй вариант, который может случиться, это повреждение или некорректная конфигурация файла fstab. В моем случае, при загрузке с systemrescuecd и проверки системы, проблем не было обнаружено и это не помогло. Но при открытии fstab я увидел, в конфигурации нет разделов диска для монтирования, а есть только запись о загрузочном диске:
Чтобы решить вопрос, нужно получить UUID ваших дисков через утилиту blkid:
После этого нужно все данные в fstab, сохранить и перезапустить сервер, если все сделали правильно, то сервер запуститься в обычном режиме.
Linux установлен с USB флешки
Так же в работе были моменты, когда установкуLinux производили с установочного флеш-накопителя и после рестарта сервера, ОС загружалась с ошибкой “Welcome to emergency mode!“. При проверке fstab было обнаружено, что этот флеш-накопитель был прописан в fstab как рабочий раздел. В таком случае помогает удаление строки с монтированием и перезапуск системы. Как и в первом случае, вам нужно загрузиться с systemrescuecd и открыть fstab. Скорее всего вы сразу увидите, что там есть подобный раздел — /mnt/usb1:
Просто удалите данную строку, если вы теперь не используете флеш-накопитель.
Dualboot конфигурация Windows и Linux
Еще один из вариантов проблемы, замеченный пользователями — это параллельное использование Windows и СentOS на одном компьютере. При загрузке часто возникает ошибка emergency mode при монтировании разделов Windows. Обычное решение проблемы заключается в отключении быстрого запуска Windows.
Чтобы отключить быстрый запуск, перейдите в меню Электропитание -> Системные параметры и выбрать пункт «Изменение параметров, которые сейчас недоступн».
Снимите галочку в блоке «Включить быстрый запуск».
Сохраните изменения и перезапустите ваш сервер. После выполненных рекомендаций, CentOS должен запуститься.
Если вы используете LVM разделы, данная ошибка так же может появиться, в целом решение проблемы схоже с обычным разделом, нужно проверить fstab и исправить ошибки, допущенные в нем.
Ответ на:
комментарий
от usi_svobodi 06.12.22 14:27:08 MSK
Он же кнопкой перезагрузился, банальная битая ФС, Linux же к такому очень плохо относится. Нужно с LiveCD грузится и чекать. Если она не зашифрована, конечно, тогда всё очень плохо.
- Ссылка
Короче, смотри как нужно поступить:
- Сначала ставишь на свою Windows Fedora Media Writer, он гарантированно запишет образ .iso на флешку без проблем: https://getfedora.org/fmw/FedoraMediaWriter-win32-latest.exe
- Потом качаешь Live образ SystemRescue: https://sourceforge.net/projects/systemrescuecd/files/sysresccd-x86/9.05/systemrescue-9.05-amd64.iso/download
- Записываешь .iso на флешку и грузишься с неё, после загрузки
startx
- После делаешь в терминале
lsblk -f
и смотришь, какие там у тебя разделы на диске, нужно найти те, что с Debian - После этого нужно прочекать ФС на них на ошибки. Для ext4 это будет команда
e2fsck -fvy /dev/путь/до/раздела
, если XFS, тоmount -o ro /dev/путь/до/раздела /mnt && umount /mnt && xfs_repair /dev/путь/до/раздела
, для иных ФС не помню, надо искать - Если будут проблемы с определением точных команд, можешь сюда выложить
lsblk -f
, помогу, только разметку не забудь: Как правильно копировать вывод терминала
Vsevolod-linuxoid ★★★★★
(06.12.22 14:43:43 MSK)
Последнее исправление: Vsevolod-linuxoid 06.12.22 14:53:31 MSK
(всего
исправлений: 5)
- Показать ответ
- Ссылка
Ответ на:
комментарий
от usi_svobodi 06.12.22 14:27:08 MSK
идея хорошая, но /bin/bash and /bin/sh — нет таких папок — как в конце последнего скриншота.
- Показать ответ
- Ссылка
Ответ на:
комментарий
от Vsevolod-linuxoid 06.12.22 14:43:43 MSK
п.1-5 выполнил.
после
$ e2fsck -fvy /dev/sdb5
..
***block bitmap differences: Group 703 block bitmap does not match checksum***
..
Запустил:
и пофиксил эту проблему.
Бэдов нету. Инод использовано 24%, блоков использованно 90%.
Дебиан не запустился всё тоже самое.
- Показать ответ
- Ссылка
Ответ на:
комментарий
от DmitriyS 06.12.22 17:26:00 MSK
Ответ на:
комментарий
от DmitriyS 06.12.22 16:07:16 MSK
Ничего себе… мда… ладно, все равно жду от тебя ответа на мое последнее сообщение… потом придется ещё ряд команд выполнить…
Vsevolod-linuxoid ★★★★★
(06.12.22 18:09:53 MSK)
Последнее исправление: Vsevolod-linuxoid 06.12.22 18:10:11 MSK
(всего
исправлений: 1)
- Показать ответ
- Ссылка
Ответ на:
комментарий
от Vsevolod-linuxoid 06.12.22 17:37:48 MSK
Ответ на:
комментарий
от DmitriyS 06.12.22 18:20:22 MSK
Ответ на:
комментарий
от Vsevolod-linuxoid 06.12.22 18:09:53 MSK
Для информации: при установке debian указывал свободное место на диске. Внутри он разбил его на разные папки, примерно:
/
/boot
/home
/dev
..
./swap
но из винды видно только 2 диска
- Показать ответ
- Ссылка
Ответ на:
комментарий
от DmitriyS 06.12.22 18:27:36 MSK
У тебя путаница с директориями, разделами дисков и дисками в твоей голове. То, что ты сейчас описал как раз нормально, проблема в другом.
Просто покажи выводы, что прошу. Попробую решить проблему, используя тебя как «удаленные руки», проводить с тобой двухнедельный курс по Linux у меня нет времени.
- Показать ответ
- Ссылка
У тебя ругань на vfat раздел (EC05-07С7) и swap (9c41c2c0-)
А то, что нет /bin/sh и /bin/bash, косвенно показывает, что часть файлов с линуксового раздела, возможно, теперь сидят в /lost+found
Покажи smartctl -a /dev/sdb
Dimez ★★★★★
(06.12.22 18:31:09 MSK)
Последнее исправление: Dimez 06.12.22 18:34:57 MSK
(всего
исправлений: 1)
- Показать ответы
- Ссылка
Ответ на:
комментарий
от Dimez 06.12.22 18:31:09 MSK
Уже чекали и восстанавливали ФС, не помогло. Сейчас пробую узнать, был ли /dev/sdb5 едиственным разделом. Но да, SMART имеет смысл глянуть.
- Показать ответ
- Ссылка
Ответ на:
комментарий
от Vsevolod-linuxoid 06.12.22 18:37:38 MSK
Ответ на:
комментарий
от Dimez 06.12.22 18:43:13 MSK
Хм… ну на FAT разделе лежит только GRUB2-EFI, если бы он был поврежден, то до systemd дело бы вообще не дошло.
Можно пересоздать swap на разделе с ним, раз проблема с этим, хотя я не понимаю, как он мешает обнаружить /bin/sh и /bin/bash, что на разделе с ext4.
- Ссылка
Ответ на:
комментарий
от Vsevolod-linuxoid 06.12.22 18:24:12 MSK
Ответ на:
комментарий
от DmitriyS 06.12.22 18:53:19 MSK
Не тот скриншот. И покажи ещё smartctl -a /dev/sdb
, как писал Dimez выше.
- Ссылка
Ответ на:
комментарий
от Dimez 06.12.22 18:31:09 MSK
Ответ на:
комментарий
от Vsevolod-linuxoid 06.12.22 18:24:12 MSK
Ответ на:
комментарий
от DmitriyS 06.12.22 19:03:44 MSK
Хм… у тебя часть симлинков из корня куда-то пропали… и я глянул SMART, проблемы есть, но на мой взгляд не особо ужасно… хотя может Dimez скажет лучше.
- Показать ответ
- Ссылка
Ответ на:
комментарий
от DmitriyS 06.12.22 19:00:52 MSK
Вроде так то всё в порядке, но стоит в винду установить обновлялку фирмвари от кингстона и обновить, собственно, её.
Dimez ★★★★★
(06.12.22 19:11:26 MSK)
- Ссылка
Ответ на:
комментарий
от DmitriyS 06.12.22 19:03:44 MSK
Dimez, я думаю вот так это попробовать починить, что скажешь?
mount -o remount,rw /mnt
cd /mnt
ln -s usr/bin bin
ln -s boot/initrd.img-4.19.0-17-amd64 initrd.img.old
cd
umount /mnt
reboot # должно загрузится после этого с диска
Вообще крайне странная поломка…
- Показать ответ
- Ссылка
Ответ на:
комментарий
от Vsevolod-linuxoid 06.12.22 18:30:22 MSK
Ответ на:
комментарий
от DmitriyS 06.12.22 19:14:46 MSK
Это не директории, а как раз разделы диска. И явно не твои, судя по fstab.
Vsevolod-linuxoid ★★★★★
(06.12.22 19:15:36 MSK)
Последнее исправление: Vsevolod-linuxoid 06.12.22 19:15:56 MSK
(всего
исправлений: 1)
- Ссылка
Ответ на:
комментарий
от Vsevolod-linuxoid 06.12.22 19:08:12 MSK
Ответ на:
комментарий
от DmitriyS 06.12.22 19:20:49 MSK
Да, я заметил. И у нас это симлинк называется.
- Ссылка
Ответ на:
комментарий
от Vsevolod-linuxoid 06.12.22 19:14:16 MSK
Вместо
ln -s boot/initrd.img-4.19.0-17-amd64 initrd.img.old
запустил
ln -s boot/initrd.img-5.10.0-18-amd64 initrd.img
В итоге: debian загрузилась!!!
- Показать ответы
- Ссылка
Ответ на:
комментарий
от DmitriyS 06.12.22 19:36:51 MSK
Эм… так initrd.img у тебя и так был. У тебя симлинк только на старую версию пропал, я его и восстанавливал.
Можешь
cd /
ln -s boot/initrd.img-4.19.0-17-amd64 initrd.img.old
выполнить, чтобы починить загрузку на старом ядре.
Vsevolod-linuxoid ★★★★★
(06.12.22 19:38:17 MSK)
Последнее исправление: Vsevolod-linuxoid 06.12.22 19:41:43 MSK
(всего
исправлений: 2)
- Показать ответы
- Ссылка
Ответ на:
комментарий
от DmitriyS 06.12.22 19:36:51 MSK
Ответ на:
комментарий
от Vsevolod-linuxoid 06.12.22 19:38:17 MSK
Я на этом Debian все ядра из /boot удалил. Потом пришлось восстанавлить:
sudo dpkg i img-5.10.0-18-amd64.dep
- Показать ответ
- Ссылка
Ответ на:
комментарий
от DmitriyS 06.12.22 19:47:38 MSK
Ответ на:
комментарий
от Vsevolod-linuxoid 06.12.22 19:40:44 MSK
debian:/$ sudo debsums -cs
debian:/$ sudo debsums -l
Просто отрабатывают и ничего не выводят.
- Показать ответ
- Ссылка
Ответ на:
комментарий
от Vsevolod-linuxoid 06.12.22 19:48:12 MSK
Освобождал место /home и вместе со старыми ядрами удалил нужные.
- Ссылка
Ответ на:
комментарий
от Vsevolod-linuxoid 06.12.22 19:38:17 MSK
Ответ на:
комментарий
от DmitriyS 06.12.22 20:37:12 MSK
Ответ на:
комментарий
от DmitriyS 06.12.22 20:43:25 MSK
Учитывая, что оно от Debian 10 (вероятно после обновления осталось), может это нормально.
- Ссылка
- articlesdebian/problemsolving.txt
- Последнее изменение: 2023/05/24 15:38
- — 127.0.0.1
У вас система работает с включенным EFI. Есть два способа решения этой проблемы: отключить EFI, после чего переустановить систему, и правильный. Поскольку у меня видеокарта NVidia RTX 2070, я пишу решение под неё. Версия ядра при написании руководства была 4.18.0-8, у вас может быть другой. При необходимости внесите изменения в команды:
Обновите список пакетов и поставьте необходимый софт:
apt-get update
apt-get install nvidia-driver nvidia-xconfig linux-headers-amd64 mokutil build-essential
Сгенерируйте ключи, которые будут использованы для импорта в EFI в качестве доверенных. Ими же подпишите модули ядра с графическими драйверами:
# Генерация ключей и импорт в EFI
cd /root
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=NVidia RTX 2070 key/"
mokutil --import MOK.der
# Подписывание драйверов Nvidia
cd /lib/modules/4.19.0-8-amd64/updates/dkms/ # Используйте актуальную версию ядра
/usr/lib/linux-kbuild-4.19/scripts/sign-file sha256 /root/MOK.priv /root/MOK.der nvidia-current-drm.ko
/usr/lib/linux-kbuild-4.19/scripts/sign-file sha256 /root/MOK.priv /root/MOK.der nvidia-current.ko
/usr/lib/linux-kbuild-4.19/scripts/sign-file sha256 /root/MOK.priv /root/MOK.der nvidia-current-modeset.ko
/usr/lib/linux-kbuild-4.19/scripts/sign-file sha256 /root/MOK.priv /root/MOK.der nvidia-current-uvm.ko
# Перенастройка Xorg под nvidia
cd /etc/X11
rm xorg.conf
nvidia-xconfig
Перезагрузите компьютер. При этом будет запущена специальная утилита EFI, которая позволит выполнить импорт сгенерированного ранее ключа в качестве доверенного. Буквально несколько раз подряд нажать Next.
Пересоберите ядро:
update-initramfs -u -k all
Перезагрузитесь ещё раз.
На основе официального руководства Debian. Недостаток решения в том, что при обновлении драйверов видеокарты или ядра модули нужно будет подписывать заново. Но можно использовать простой скрипт:
#!/bin/sh
SIGN=/usr/lib/linux-kbuild-4.19/scripts/sign-file
MOK=/root/MOK.priv
DER=/root/MOK.der
cd /lib/modules/$(uname -r)/updates/dkms/
$SIGN sha256 $MOK $DER nvidia-current-drm.ko
$SIGN sha256 $MOK $DER nvidia-current.ko
$SIGN sha256 $MOK $DER nvidia-current-modeset.ko
$SIGN sha256 $MOK $DER nvidia-current-uvm.ko
update-initramfs -u -k all