Ошибки при загрузке linux mint
На сегодня мой комп выглядит так
https://linux-hardware.org/index.php?pr . 3eeefe8f69
По совету в предыдущем своем вопросе делал
symon2014 писал(а): StarMAUGLI, тогда создай директорию для журналирования загрузки — sudo mkdir -p /var/log/journal , и после ребута можно будет смотреть, что происходит при загрузке системы — journalctl -b — это вся последняя загрузка , journalctl -b -p err — это ошибки последней загрузки.
starmaugli@starmaugli-P35 ~ $ journalctl -b -p err -- Logs begin at Сб 2017-09-23 16:43:07 MSK, end at Ср 2017-09-27 10:41:24 MSK. -- сен 27 10:18:26 starmaugli-P35 systemd-udevd[668]: failed to execute '/usr/bin/nvidia-smi' '/usr/bin/nvidia-smi': No such file or directory сен 27 10:18:26 starmaugli-P35 systemd-udevd[684]: failed to execute '/usr/bin/nvidia-smi' '/usr/bin/nvidia-smi': No such file or directory сен 27 10:18:32 starmaugli-P35 ntpdate[1014]: name server cannot be used: Temporary failure in name resolution (-3) сен 27 10:18:33 starmaugli-P35 NetworkManager[881]: nm_device_get_device_type: assertion 'NM_IS_DEVICE (self)' failed сен 27 10:18:39 starmaugli-P35 colord-sane[1089]: io/hpmud/pp.c 627: unable to read device-id ret=-1 сен 27 10:18:43 starmaugli-P35 systemd[1]: Failed to start VirtualBox Linux kernel module. сен 27 10:18:46 starmaugli-P35 mdm[1381]: GLib-CRITICAL: g_key_file_get_string: assertion 'key_file != NULL' failed сен 27 10:18:46 starmaugli-P35 mdm[1381]: GLib-CRITICAL: g_key_file_free: assertion 'key_file != NULL' failed сен 27 10:18:57 starmaugli-P35 pulseaudio[1874]: [pulseaudio] pid.c: Daemon already running. сен 27 10:19:21 starmaugli-P35 pulseaudio[1791]: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did no
Вот первые две строки: вроде бы понятно No such file or directory — нет такого файла. Значит где-то надо подчистить, что бы не запрашивало. Но где? Где искать этот systemd-udevd (systemd и udevd я нашел, но почему-то пораздельности в каталоге etc и строк в конфигурационных файлах там везде штук по 20-50, ну никак не 684, да и закоменчены они все, значит не выполняются)?
Третью строчку вообще не понял, что от меня хотят. Почему имя сервера не может быть использовано, и почему это ошибка? Ну и где ее править тоже?
Четвертую и пятую строчку тоже не понял.
С шестой более-менее понятно. Я экспериментировал с виртуал-боксом года два назад. В настоящий момент, на данной машине я его использовать не планирую. Вопрос, как его убить, что бы не отсвечивал. Я же уже несколько версий минта сменил, и ядро. А он все лезет откуда-то. Откуда?
В седьмой и восьмой строках вообще какие-то критические ошибки. Как их можно исправить?
В последних двух, очевидно проблемы с аудио. Но какого рода эти ошибки, я тоже не понял.
Последний раз редактировалось пользователем 1 Dja; всего редактировалось раз: 17
Причина: подправил название
Не загружается Ubuntu/Mint/Kali с initramfs в BusyBox
22.11.2019
VyacheslavK
Ubuntu
комментариев 13
В данной статье мы рассмотрим варианты решения проблем, когда виртуальный или физический серверы на базе Ubuntu/Mint/Kali не загружаются и отваливается в busybox в момент инициализации initramfs. При этом Linux не загружается, и пользователю доступна только командная строка initramfs.
Initramfs – это начальная файловая система в ОЗУ, основанная на tmpfs, которая не использует отдельное блочное устройство. Как и initrd, она содержит утилиты и скрипты, требуемые для монтирования файловых систем перед вызовом init, который располагается на корневой файловой системе.
Проблема с суперблоком
Если Ubuntu свалилась в busybox при инициализации initramfs, возможно на диске оказался испорченный суперблок. Linux хранит несколько копий суперблоков.
Для восстановления в случае такой проблемы, нам нужно загрузиться с образа/диска и запустить Terminal. После загрузки, в терминале вводим команду:
# sudo fdisk -l|grep Linux|grep -Ev ‘swap’
Команда вернет информацию о нашем разделе:
/dev/vda2 4096 83884031 83879936 40G Linux filesystem
Запомните имя раздела и укажите его в следующей команде:
# sudo dumpe2fs /dev/vda2 | grep superblock
Команда вернет список запасных суперблоков:
Мы будем использовать второй резервный суперблок для замены поврежденного (можно выбрать любой, кроме Primary). Выполним проверку диска с использованием резевного суберблока для восстановления:
# sudo fsck -b 98304 /dev/vda2 -y
fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) /dev/vda2 is mounted. e2fsck: Cannot continue, aborting
Нужно отмонтировать раздел:
# umount /dev/vda2
После успешного выполнения замены суперблока, вы должны получить такое сообщение:
fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) /dev/vda2 was not cleanly unmounted, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Free blocks count wrong for group #231 (32254, counted=32253). Fix? yes Free blocks count wrong for group #352 (32254, counted=32248). Fix? yes Free blocks count wrong for group #358 (32254, counted=27774). Fix? yes . /dev/vda2: ***** FILE SYSTEM WAS MODIFIED ***** /dev/vda2: 85986/905464576 files (0.2% non-contiguous), 3904682/905464576 blocks
Теперь перезагрузите компьютеры, отключив диск с дистрибутивом и все должно быть в порядке.
Ошибка диска fsck
Второй вариант ошибки, наличие следующей строки в окне терминала:
/dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY The root filesystem on /dev/sda1 requires a manual fsck.
Если вы не видите такой ошибки, попробуйте ввести (initramfs) exit в окне терминала. Ошибка может появиться после этого..
В ошибке будет указан том, который требует запуска ручной проверки диска. В командной строке initramfs выполните:
После полной проверки, нужно перезапустить сервер и проверить все ли в порядке.
Ошибка диска: /dev/sda1 does not exist
Проблема с fstab
Если при загрузке сервера вы видите ошибку:
ALERT! /dev/sda1 does not exist. Dropping to a shell.
Скорее всего вы только что установили Linux или то на вашем сервере есть проблемы в fstab. Чаще всего проблема возникает при установке системы с usb-накопителя. Раздел на который ругается система, может быть какой угодно. Как и в первом случае, нам нужно загрузиться с образа системы и выполнить некоторые действия. Проверьте UUID диска командой:
Система выдаст что-то подобное:
/dev/sda2: UUID="36cce3d5-cbdb-46f4-adbf-3f9aaa01d729" TYPE="ext4" PARTUUID="fea4dab1-4e12-4327-85c6-76ade18f64e1"
Отсюда уже видно, что система должна загружаться с sda2, а по факту загружается с sda1.
Монтируем наш раздел в любую директорию, например:
Получаем в директории /mnt весь наш раздел /dev/sda2, находим там файл /etc/fstab и изменяем строку, содержащую /dev/sda1 на:
UUID=36cce3d5-cbdb-46f4-adbf-3f9aaa01d729 / ext4 errors=remount-rw 0 1
Сохраняем файл. Отмонтируем раздел от /mnt и перезагрузимся, если проблема была связана с не неправильным адресом разделе, сервер загрузится.
Так же данный вариант можно решить, загрузившись в emergency. Перемонтируйте корень для записи:
После чего измените fstab и перезапустите сервер.
Проблема с железом
На некоторых материнских платах порты SATA могут получать произвольные номера. Это также может вызвать описанную в предыдущем пункте ошибку. Для исправления ошибки нужно изменить загрузчик grub.
Загрузитесь в режиме emergency или с live-cd и измените файл /boot/grub/grub.cfg
В строке где происходит загрузка раздела, например:
Linux /boot/vmlinuz-4.15.0-70-generic root=/dev/sda1 rw quiet elevator=noop fsck.repair=yes
Измените путь до диска на UUID:
Linux /boot/vmlinuz-4.15.0-70-generic root=UUID=36cce3d5-cbdb-46f4-adbf-3f9aaa01d729 ro quiet elevator=noop fsck.repair=yes
Предыдущая статья Следующая статья
Установка и настройка GLPI и FusionInventory, инвентаризация ИТ инфраструктуры
Установка и использование подсистемы Linux (WSL 2) в Windows 10
Zabbix: установка и базовая настройка системы мониторинга
Zabbix: проверка доступности запросом ICMP Ping