Не включается сервер линукс

Обновлено: 08.07.2024

Этичный хакинг и тестирование на проникновение, информационная безопасность

Не загружается Linux Live при записи на флешку
Linux не загружается сразу после установки операционной системы
Linux не загружается после обновления или установки программ (ядра Linux, драйверов)
Linux не загружается из-за аппаратных изменений компьютера (новая видеокарта, новый диск или отключение диска)

1. Не загружается Linux Live при записи на флешку

1.1 Включены опции Quick boot и (или) Secure boot

Причина может быть в том, что в вашем BIOS (UEFI) включены опции Quick boot и (или) Secure boot. Зайдите в БИОС и отключите их.

1.2 Не пользуйтесь Rufus

Не надо пользоваться Rufus для записи образов Linux. Сейчас большинство ISO LIVE образов Linux это гибридные образы: в них имеется поддержка BIOS и UEFI, т. е. они прекрасно работают на старом и новом железе, а Rufus вносит какие-то изменения и просто портит их.

Для записи используйте портативную кроссплатформенную программу Etcher.

1.3 Обновите БИОС вашего компьютера

Если ничего вышеперечисленное не помогло, то обновите BIOS, особенно это относится к владельцам старого железа.

1.4 A start job is running for live-config contains the components that configure a live system during the boot process (late userspace)

2. Linux не загружается сразу после установки операционной системы

2.1 error: attempt to read or write outside of disk “hd0″

3. Linux не загружается после обновления или установки программ

Среди вероятных причин проблем с загрузкой Linux после обновления или установки программ могут быть:

обновление ядра Linux
установка или обновление драйверов для графической карты

3.1 Невозможно загрузиться после установки драйверов видеокарты

Загрузка доходит до меню, но замирает на экране консоли или после ввода логина и пароля

Если вы видите загрузочное меню Linux с разными вариантами загрузки и после него продолжается загрузка системы, но она не завершается успехом, значит флешка записана правильно, но присутствуют проблемы в самой системе – чаще всего это несовместимость модулей ядра и самого ядра, отсутствие или дублирование драйверов.

В некоторых случаях может появиться графический интерфейс (менеджер отображения) с приглашением ввести логин и пароль, но после ввода учётных данных вся система зависает.

Аналогичная проблема может возникнуть и с Live образом – следующий рецепт подходит и для установленной системы и для Live системы.

Чтобы избежать эту проблему, когда появится меню загрузки GRUB нажмите букву e.

Теперь отредактируйте опции загрузки, добавив nomodeset. Для этого найдите строку, начинающуюся со слова linux и в её конец допишите через пробел слово nomodeset. Для продолжения загрузки нажмите F10.

Эта настройка действует только для текущей загрузки и при последующих перезагрузках системы это нужно делать снова.

Можно сделать опцию nomodeset постоянной для GRUB, но лучше найти проблемный модуль и отключить его.

В данный момент на эту проблему жалуются владельцы компьютеров с видеокартами NVidia. Причина, судя по всему, в конфликте последних версий ядра Linux с проприетарными драйверами NVidia и свободными драйверами nouveau. Одним из подтверждений этого является строка

в консоли загрузки.

Для отключения nouveau создайте файл /etc/modprobe.d/blacklist-nouveau.conf и скопируйте в него:

Если вы не можете загрузиться в графический интерфейс, то попробуйте с помощью сочетаний клавиш Ctrl+Alt+F1, Ctrl+Alt+F2, Ctrl+Alt+F3 и так далее перейти в консоль. Залогинтесь там и с помощью консольного редактора создайте в папке /etc/modprobe.d/ файл blacklist-nouveau.conf со следующим содержимым:

Для создания файла с помощью текстового редактора nano:

Или с помощью vim:

3.2 Невозможно загрузиться после обновления ядра

В производных Debian после установки нового ядра могут появляться новые опции в меню загрузки с вариантами загрузки компьютера с предыдущей версией ядра.

На равне с прочими опциями загрузки, также можно явно указать версию ядра Linux для загрузки, в Kali Linux файлы называются, например:

/boot/initrd.img-5.4.0-kali2-amd64
/boot/initrd.img-5.4.0-kali3-amd64

В Arch Linux и производных текущее ядро имеет имя /boot/initramfs-linux.img, а предыдущее ядро имеет имя /boot/initramfs-linux-fallback.img.

4. Linux не загружается из-за аппаратных изменений компьютера

4.1 Не загружается после добавления/удаления диска

4.2 Новая видеокарта

Как откатить изменения в Linux, если система не загружается

1) После попадания в чёрный экран. Попробуйте нажать Ctrl+Alt+F1. Если ничего не произойдёт, то нажимайте дальше Ctrl+Alt+F2, Ctrl+Alt+F3 и т. д. Ctrl+Alt+F* пока не появится приглашение авторизации.

2) Введите логин и пароль вашего пользователя

3) С помощью менеджера пакета (apt, pacman) удалить пакеты, которые вызвали проблемы. С помощью текстовых редакторов с интерфейсом командой строки (vim, nano) откатите изменения в конфигурационных файлах, которые препятствуют загрузке.

Как увидеть, из-за каких ошибок не загружается Linux

Увидеть ошибки, которые препятствуют загрузке системы, можно двумя способами:

1) на экране во время загрузки

2) с помощью команды journalctl

Иногда система намертво зависает и невозможно воспользоваться командой journalctl, тогда в этом случае остаётся только первый вариант. Но другая проблема в том, что многие дистрибутивы Linux во время запуска компьютера убирают вывод журнала загрузки на экран и/или закрывают его заставкой.

1) Чтобы вернуть показ журнала загрузки системы выполните следующую последовательность действий:

1.1 В меню загрузки нажмите е (или TAB). Откроется окно опций загрузки. Если в нём несколько строк, то передвиньте курсор на строку, которая начинается с

1.2 Посмотрите, встречаются ли в этой строке «quiet» и «splash»?

1.3 Уберите обе эти строки и начните загрузку (кнопку F10). Посмотрите, какие именно ошибки не дают загрузиться системе.

2) Как просмотреть журнал последней загрузки

Если вам удалось войти в систему, пусть даже только с интерфейсом командной строки, то используйте команду journalctl для вывода журнала загрузки:

Либо используйте следующую команду для сохранения информации о последней загрузки в файл:

Использование однопользовательского режима для восстановления системы

В крайнем случае, если не удаётся войти даже в интерфейс командной строки из-за зависания системы, воспользуйтесь однопользовательским режимом. Подробности об этом режиме, а также какие опции нужно указать смотрите в статье «Как в Linux сбросить забытый пароль входа». В этой статье также даются подсказки о подключении диска для записи и о том, как отредактировать опции загрузки Linux в различных дистрибутивах.

Вангую что у тебя иксы просто вообще не настроены.

Fatal server error:
[ 3145.817] (EE) no screens found(EE)

Xorg -configure && Xorg -config /root/xorg.conf.new

Или вообще без xorg.conf попробуй.

Ну и как по твоему оно должно работать если оно даже не знает каким модулем у тебя рисуется графика?

Современным иксам этого же ж не нужно?

давай вывод lspci -kv , lsmod , dmesg

daemonpnz ★★★★★ ( 13.10.13 15:22:54 )
Последнее исправление: daemonpnz 13.10.13 15:23:01 (всего исправлений: 1)

Не нужен конфиг. Последние иксы прекрасно умеют autoconfig.

Не нужен конфиг. Последние иксы прекрасно умеют autoconfig.

lspci -kv, lsmod, dmesg - не получается записать выхлоп в файл

Иксам на Intel действительно сейчас не нужен конфиг.

Иксам на Intel действительно сейчас не нужен конфиг.

Видимо именно как то так оно и запланировано однако, как и всегда, в реальности все иначе.

ничего себе lsmod. впечатлен.

а xorg0.log смотрели?

[drm:drm_pci_agp_init] *ERROR* Cannot initialize the agpgart module.

может vesafb в blacklist добавить? консоль то c драйвером vesa грузится

Работают прекрасно иксы без конфига, не перди.

Работают прекрасно иксы без конфига, не перди.

Ааа. Ну да. Оно и видно собственно.

Твои приходы видны только тебе.

У ТС проблема с ядерной частью и как тут поможет конфиг иксов не совсем понятно. Так что прекращай засорять информационный эфир.

Давай ещё конфиг ядрышка и его версию.

может vesafb в blacklist добавить?

так . в /etc/modprobe.d/blacklist.conf добавил
blacklist vesafb

Давай ещё конфиг ядрышка и его версию.

Иксы заработали =) Спасибо ребят!!

Этот параметр передавать ядру не нужно, у вас в ядре была выключена опция CONFIG_DRM_I915_KMS, просто включите её и пересоберите ядро, хотя вы уже и так её включили. Передавать ядру указанный параметр не нужно, KMS и так будет активирован.

Не то чтобы не нужно, просто твоя альтернатива более подходящая под современные чипы от интела.

Отметь тему как решённую.

Какая альтернатива ? Если в ядре включена опция поддержки kms для драйвера i915 (CONFIG_DRM_I915_KMS), то передавать ядру параметр для активации kms не нужно, kms и так будет активирована.

По крайней мере я не сталкивался с тем, что бы при включённой опции CONFIG_DRM_I915_KMS нужно было дополнительно активировать kms, иногда наоборот добавляют параметр i915.modeset=0 для выключения kms.

Мне доводилось видеть множество Linux-серверов, которые, без единой перезагрузки, работали годами, в режиме 24x7. Но ни один компьютер не застрахован от неожиданностей, к которым могут вести «железные», программные и сетевые сбои. Даже самый надёжный сервер может однажды отказать. Что делать? Сегодня вы узнаете о том, что стоит предпринять в первую очередь для того, чтобы выяснить причину проблемы и вернуть машину в строй.

И, кстати, в самом начале, сразу после сбоя, стоит ответить на весьма важный вопрос: «А сервер ли виноват в том, что случилось?». Вполне возможно, что источник проблемы совсем не в нём. Но, не будем забегать вперёд.

Поиск и устранение неполадок: раньше и теперь

Когда, в 1980-х, я начал работать системным администратором Unix — задолго до того, как Линус Торвальдс загорелся идеей Linux — если с сервером было что-то не так, это была реальная засада. Тогда было сравнительно мало инструментов для поиска проблем, поэтому для того, чтобы сбойный сервер снова заработал, могло понадобиться много времени.

Теперь всё совсем не так, как раньше. Как-то один системный администратор вполне серьёзно сказал мне, говоря о проблемном сервере: «Я его уничтожил и поднял новый».

В былые времена такое звучало бы дико, но сегодня, когда ИТ-инфраструктуры строят на основе виртуальных машин и контейнеров… В конце концов, развёртывание новых серверов по мере необходимости — это обычное дело в любой облачной среде.

Сюда надо добавить инструменты DevOps, такие, как Chef и Puppet, используя которые легче создать новый сервер, чем диагностировать и «чинить» старый. А если говорить о таких высокоуровневых средствах, как Docker Swarm, Mesosphere и Kubernetes, то благодаря им работоспособность отказавшего сервера будет автоматически восстановлена до того, как администратор узнает о проблеме.

Данная концепция стала настолько распространённой, что ей дали название — бессерверные вычисления. Среди платформ, которые предоставляют подобные возможности — AWS Lambda, Iron.io, Google Cloud Functions.

Благодаря такому подходу облачный сервис отвечает за администрирование серверов, решает вопросы масштабирования и массу других задач для того, чтобы предоставить клиенту вычислительные мощности, необходимые для запуска его приложений.

Бессерверные вычисления, виртуальные машины, контейнеры — все эти уровни абстракции скрывают реальные серверы от пользователей, и, в некоторой степени, от системных администраторов. Однако, в основе всего этого — физическое аппаратное обеспечение и операционные системы. И, если что-то на данном уровне вдруг разладится, кто-то должен привести всё в порядок. Именно поэтому то, о чём мы сегодня говорим, никогда не потеряет актуальности.

Помню разговор с одним системным оператором. Вот что он говорил о том, как надо поступать после сбоя: «Переустановка сервера — это путь вникуда. Так не понять — что стало с машиной, и как не допустить такого в будущем. Ни один сносный администратор так не поступает». Я с этим согласен. До тех пор, пока не обнаружен первоисточник проблемы, её нельзя считать решённой.

Итак, перед нами сервер, который дал сбой, или мы, по крайней мере, подозреваем, что источник неприятностей именно в нём. Предлагаю вместе пройти пять шагов, с которых стоит начинать поиск и решение проблем.

Шаг первый. Проверка аппаратного обеспечения

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

Я и сосчитать не смогу, сколько раз поиски причины проблемы приводили к кабельным соединениям. Один взгляд на светодиоды — и становится ясно, что Ethernet-кабель выдернут, или питание сервера отключено.

Конечно, если всё выглядит более-менее прилично, можно обойтись без визита к серверу и проверить состояние Ethernet-соединения такой командой:

Если её ответ можно трактовать, как «да», это значит, что исследуемый интерфейс способен обмениваться данными по сети.

Однако, не пренебрегайте возможностью лично осмотреть устройство. Это поможет, например, узнать, что кто-то выдернул какой-нибудь важный кабель и обесточил таким образом сервер или всю стойку. Да, это до смешного просто, но удивительно — как часто причина отказа системы именно в этом.

Ещё одну распространённую аппаратную проблему невооружённым взглядом не распознать. Так, сбойная память является причиной всевозможных проблем.

Виртуальные машины и контейнеры могут скрывать эти проблемы, но если вы столкнулись с закономерным появлением отказов, связанных с конкретным физическим выделенным сервером, проверьте его память.

Для того, чтобы увидеть, что BIOS/UEFI сообщают об аппаратном обеспечении компьютера, включая память, используйте команду dmidecode:

Даже если всё тут выглядит нормально, на самом деле это может быть и не так. Дело в том, что данные SMBIOS не всегда точны. Поэтому, если после dmidecode память всё ещё остаётся под подозрением — пришло время воспользоваться Memtest86. Это отличная программа для проверки памяти, но работает она медленно. Если вы запустите её на сервере, не рассчитывайте на возможность использовать эту машину для чего-нибудь другого до завершения проверки.

Если вы сталкиваетесь со множеством проблем с памятью — я видел такое в местах, отличающихся нестабильным электропитанием — нужно загрузить модуль ядра Linux edac_core. Этот модуль постоянно проверяет память в поиске сбойных участков. Для того, чтобы загрузить этот модуль, воспользуйтесь такой командой:

Подождите какое-то время и посмотрите, удастся ли что-нибудь увидеть, выполнив такую команду:

Эта команда даст вам сводку о числе ошибок, разбитых по модулям памяти (показатели, название которых начинается с csrow ). Эти сведения, если сопоставить их с с данными dmidecode о каналах памяти, слотах и заводских номерах компонентов, помогут выявить сбойную планку памяти.

Шаг второй. Поиск истинного источника проблемы

Итак, сервер стал странно себя вести, но дым из него ещё пока не идёт. В сервере ли дело? Прежде чем вы попытаетесь решить возникшую проблему, сначала нужно точно определить её источник. Скажем, если пользователи жалуются на странности с серверным приложением, сначала проверьте, что причина проблемы — не в сбоях на клиенте.

Например, друг однажды рассказал мне, как его пользователи сообщили о том, что не могут работать с IBM Tivoli Storage Manager. Сначала, конечно, казалось, что виновен во всём сервер. Но в итоге администратор выяснил, что проблема вообще не была связана с серверной частью. Причиной был неудачный патч Windows-клиента 3076895. Но то, как сбоило это обновление безопасности, делало происходящее похожим на проблему серверной стороны.

Кроме того, нужно понять, является ли причиной проблемы сам сервер, или серверное приложение. Например, серверная программа может работать кое как, а железо оказывается в полном порядке.

Для начала — самое очевидное. Работает ли приложение? Есть множество способов проверить это. Вот два моих любимых:

Если оказалось, что, например, веб-сервер Apache не работает, запустить его можно такой командой:

Если в двух словах, то прежде чем диагностировать сервер и искать причину проблему, узнайте — сервер ли виноват, или что-то другое. Только тогда, когда вы поймёте, где именно находится источник сбоя, вы сможете задавать правильные вопросы и переходить к дальнейшему анализу того, что произошло.

Это можно сравнить с неожиданной остановкой автомобиля. Вы знаете, что машина дальше не едет, но, прежде чем тащить её в сервис, хорошо бы проверить, есть ли бензин в баке.

Шаг третий. Использование команды top

Итак, если оказалось, что все пути ведут к серверу, то вот ещё один важный инструмент для проверки системы — команда top . Она позволяет узнать среднюю нагрузку на сервер, использование файла подкачки, выяснить, какие ресурсы системы используют процессы. Эта утилита показывает общие сведения о системе и выводит данные по всем выполняющимся процессам на Linux-сервере. Вот подробное описание данных, которые выводит эта команда. Тут можно найти массу информации, которая способна помочь в поиске проблем с сервером. Вот несколько полезных способов работы с top , позволяющих найти проблемные места.

Для того, чтобы обнаружить процесс, потребляющий больше всего памяти, список процессов надо отсортировать в интерактивном режиме, введя с клавиатуры M . Для того, чтобы выяснить приложение, потребляющее больше всего ресурсов процессора, отсортируйте список, введя P . Для сортировки процессов по времени активности, введите с клавиатуры T . Для того, чтобы лучше видеть колонку, по которой производится сортировка, нажмите клавишу b .

Кроме того, данные по процессам, выводимые командой в интерактивном режиме, можно отфильтровать, введя O или o . Появится следующее приглашение, где предлагается добавить фильтр:

Затем можно ввести шаблон, скажем, для фильтрации по конкретному процессу. Например, благодаря фильтру COMMAND=apache , программа будет выводить только сведения о процессах Apache.

Ещё одна полезная возможность top заключается в выводе полного пути процесса и аргументов запуска. Для того, чтобы просмотреть эти данные, воспользуйтесь клавишей c .

Ещё одна похожая возможность top активируется вводом символа V . Она позволяет переключиться в режим иерархического вывода сведений о процессах.

Кроме того, можно просматривать процессы конкретного пользователя с помощью клавиш u или U , или скрыть процессы, не потребляющих ресурсы процессора, нажав клавишу i .

Хотя top долго была самой популярной интерактивной утилитой Linux для просмотра текущей ситуации в системе, у неё есть и альтернативы. Например, существует программа htop обладает расширенным набором возможностей, которая отличается более простым и удобным графическим интерфейсом Ncurses. Работая с htop , можно пользоваться мышью и прокручивать список процессов по вертикали и по горизонтали для того, чтобы просмотреть их полный список и полные командные строки.

Я не жду, что top сообщит мне — в чём проблема. Скорее, я использую этот инструмент для того, чтобы найти нечто, что заставит подумать: «А это уже интересно», и вдохновит меня на дальнейшие исследования. Основываясь на данных от top , я знаю, например, на какие логи стоит взглянуть в первую очередь. Логи я просматриваю, используя комбинации команд less , grep и tail -f .

Шаг четвёртый. Проверка дискового пространства

Даже сегодня, когда в кармане можно носить терабайты информации, на сервере, совершенно незаметно, может кончиться дисковое пространство. Когда такое происходит — можно увидеть весьма странные вещи.

Разобраться с дисковым пространством нам поможет старая добрая команда df, имя которой является сокращением от «disk filesystem». С её помощью можно получить сводку по свободному и использованному месту на диске.

Обычно df используют двумя способами.

Если что-то кажется вам странным, можно копнуть глубже, воспользовавшись командой Iostat. Она является частью sysstat — продвинутого набора инструментов для мониторинга системы. Она выводит сведения о процессоре, а также данные о подсистеме ввода-вывода для блочных устройств хранения данных, для разделов и сетевых файловых систем.

Вероятно, самый полезный способ вызова этой команды выглядит так:

Такая команда выводит сведения об объёме прочитанных и записанных данных для устройства. Кроме того, она покажет среднее время операций ввода-вывода в миллисекундах. Чем больше это значение — тем вероятнее то, что накопитель перегружен запросами, или перед нами — аппаратная проблема. Что именно? Тут можно воспользоваться утилитой top для того, чтобы выяснить, нагружает ли сервер MySQL (или какая-нибудь ещё работающая на нём СУБД). Если подобных приложений найти не удалось, значит есть вероятность, что с диском что-то не так.

Ещё один важный показатель можно найти в разделе %util , где выводятся сведения об использовании устройства. Этот показатель указывает на то, как напряжённо работает устройство. Значения, превышающие 60% указывают на низкую производительность дисковой подсистемы. Если значение близко к 100%, это означает, что диск работает на пределе возможностей.

Работая с утилитами для проверки дисков, обращайте внимание, что именно вы анализируете.

Например, нагрузка в 100% на логический диск, который представляет собой несколько физических дисков, может означать лишь то, что система постоянно обрабатывает какие-то операции ввода-вывода. Значение имеет то, что именно происходит на физических дисках. Поэтому, если вы анализируете логический диск, помните, что дисковые утилиты не дадут полезной информации.

Шаг пятый. Проверка логов

Последнее в нашем списке, но лишь по порядку, а не по важности — проверка логов. Обычно их можно найти по адресу /var/log , в отдельных папках для различных сервисов.

Данные в файлах журналов обычно выглядят довольно таинственно, но вам всё равно придётся с ними разобраться. Вот, например, хорошее введение в эту тему от Digital Ocean.

Хотите следить за происходящим в реальном времени? Мне, определённо, это нужно, когда я занимаюсь поиском проблем. Для того, чтобы этого добиться, используйте команду tail с ключом -f . Выглядит это так:

Вышеприведённая команда наблюдает за файлом syslog , и когда в него попадают сведения о новых событиях, выводит их на экран.

Вот ещё один удобный сценарий командной строки:

Он сканирует логи и показывает возможные проблемы.

Если в вашей системе применяется systemd то, вам нужно будет использовать встроенное средство для работы с журналами — Journalctl. Systemd централизует управление логированием с помощью демона journald . В отличие от других логов Linux, journald хранит данные в двоичном, а не в текстовом формате.

Бывает полезно настроить journald так, чтобы он сохранял логи после перезагрузки системы. Сделать это можно, воспользовавшись такой командой:

Для включения постоянного хранения записей понадобится отредактировать файл /etc/systemd/journald.conf , включив в него следующее:

Самый распространённый способ работать с этими журналами — такая команда:

Она покажет все записи журналов после последней перезагрузки. Если система была перезагружена, посмотреть, что было до этого, можно с помощью такой команды:

Это позволит просмотреть записи журналов, сделанные в предыдущую сессию сервера.
Вот полезный материал о том, как пользоваться journalctl .

Логи бывают очень большими, с ними сложно работать. Поэтому, хотя разобраться с ними можно с помощью средств командной строки, таких, как grep , awk , и других, полезно бывает задействовать специальные программы для просмотра логов.

Мне, например, нравится система для управления логами с открытым кодом Graylog. Она собирает, индексирует и анализирует самые разные сведения. В её основе лежат MongoDB для работы с данными и Elasticsearch для поиска по лог-файлам. Graylog упрощает отслеживание состояния сервера. Graylog, если сравнить её со встроенными средствами Linux, проще и удобнее. Кроме того, среди её полезных возможностей можно отметить возможность работы с многими DevOps-системами, такими, как Chef, Puppet и Ansible.

Итоги

Как бы вы ни относились к вашему серверу, возможно, он не попадёт в Книгу Рекордов Гиннеса как тот, который проработал дольше всех. Но стремление сделать сервер как можно более стабильным, добираясь до сути неполадок и исправляя их — достойная цель. Надеемся, то, о чём мы сегодня рассказали, поможет вам достичь этой цели.

Системы Linux загружаются очень быстро, поэтому большая часть данных, выводимых во время загрузки, быстро прокручивается и мы не успеваем прочитать текст. Тем не менее, во время загрузки, могут возникнуть различные ошибки, вплоть до того, что вы столкнетесь с проблемой не загружается Linux.

Ошибка может возникнуть в любом месте загрузки и любом компоненте системы инициализации. Обычно, systemd выводит подробную информацию об ошибках загрузки Linux на экран, но не всегда можно успеть их все прочитать. В этой статье мы рассмотрим что делать если не загружается Linux после установки, а также как посмотреть логи загрузки в этой операционной системе.

Почему Linux не загружается?

Причин проблем с загрузкой Linux может быть большое количество, в этой статье мы рассмотрим самые частые из них, которые можно достаточно просто решить. Сначала кратко пройдемся по самим причинам:

Linux после обновления не загружается, вы обновляли дистрибутив и что-то пошло не так, и теперь вы не можете попасть в вашу рабочую оболочку;
Linux перестал загружаться в результате повреждения файловой системы;
Linux не может примонтировать один из важных разделов диска из-за неверных настроек fstab;
Система не загружается из-за несовместимости графического драйвера и ядра;
Диск переполнен и системе попросту негде создать временные файлы.

Все это может возникать не так редко, если вы очень любите экспериментировать с системой и при этом не очень аккуратны. Мы не будем рассматривать проблемы с загрузкой из за Grub. Я буду надеяться, что там у вас все в порядке. Самое главное, что нужно сделать при проблемах с загрузкой - это посмотреть внимательно логи последней загрузки. Только так вы сможете понять в чем причина проблем и не гадать. Как это сделать? Есть несколько способов, вы можете использовать LiveCD или загрузиться в режим восстановления.

Проверка журналов загрузки

Итак, вы загрузились с LiveUSB системы и подключили разделы с основной системой или же вошли в режим восстановления с помощью загрузчика Grub. Для этого есть специальная опция в большинстве дистрибутивов. Она загружает однопользовательский режим Systemd с поддержкой сети и минимальными возможностями. С помощью него вы можете вернуть систему к нормальной работе.

Для работы в этом режиме нужно ввести пароль суперпользователя.

Если такого пункта нет можно загрузить режим восстановления Bash. Для этого нужно нажать клавишу "E" на пункте меню Grub и дописать в строку параметров ядра "init=/bin/bash":

С этим параметром ядро запустит интерпретатор Bash вместо того, чтобы загружать систему инициализации. Самый первый способ посмотреть логи в systemd - это использовать утилиту journalctl. Система нам сама подсказывает какую команду нужно запустить, чтобы посмотреть логи:

В режиме восстановления можно посмотреть содержимое лога ядра с помощью dmesg, в LiveUSB это бесполезно:

Все дальнейшие действия по восстановлению загрузки Linux нужно выполнять опираясь на информацию, полученную из лог файлов, только так вы сможете решить проблему.

Что делать если Linux не грузится?

1. Проблема с местом на диске

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

Если доступно 0% места, то вы знаете в чем проблема. Чтобы ее решить просто удалите ненужные файлы из папок /var/log, /var/cache/ и так далее. Для того чтобы вы смогли редактировать и удалять файлы, корневую систему, возможно, придется перемонтировать для чтения и записи:

mount -o remount,rw /

2. Целостность пакетов и системы

dpkg --configure -a

Также можно выполнить:

Но это сработает только в chroot окружении LiveUSB системы, поскольку в режиме восстановления интернета нет. Вы можете попытаться настроить проводной интернет с помощью команды:

3. Проблема с /etc/fstab

Следующая причина проблем с загрузкой может быть неверная запись в /etc/fstab для одного из разделов, если лог сообщает что-то в роде "Dependency failed for /dev/disk/by-uuid/f4d5ddc4-584c-11e7-8a55-970a85f49bc5" то это означает, что система не может примонтировать один из разделов в /etc/fstab.

Если это будет корневой раздел, система не загрузится. Systemd может выдавать много ошибок, но важно найти первую. Все остальные могут оказаться только ее следствием.

Поэтому если есть такая ошибка в логе проверьте файл /etc/fstab. Правильно ли там указан адрес корневого раздела? Если не уверены, лучше заменить на привычную запись Linux без UUID.

4. Повреждение файловой системы

Обычно файловая система проверяется автоматически, но это обычно. Если вы отключили эту функцию, а потом произошло неожиданное отключение компьютера, файловая система будет повреждена, а восстановить ее будет некому. Поэтому при ошибках монтирования еще можно попытаться проверить файловые системы на ошибки:

Здесь нужно указать адрес файла нужного раздела в файловой системе.

5. Проблема видеодрайвера

Если вы обновляли систему или устанавливали проприетарный драйвер, а потом в логах загрузки увидели ошибку запуска драйвера, то проблема в нем. Такое происходит потому что проприетарные драйвера не всегда совместимы с самыми новыми версиями ядер. Для решения проблемы достаточно удалить драйвер из системы в режиме восстановления. Например, для Nvidia:

apt purge nvidia*

Для видеокарт AMD команда будет выглядеть так:

apt purge fglrx*

С новым драйвером AMDGPU проблем быть не должно, так как он имеет открытый исходный код и встроен в ядро.

Во всяком случае, после удаления драйвера черный экран Linux должен перестать появляться.

6. Другое

Если у вас все же проблемы с загрузчиком Grub, вы можете использовать инструмент BootRepair для восстановления или просмотрите статью как восстановить Grub2 вручную. Также, возможно, вас заинтересует статья: ускорение загрузки Linux.

Выводы

В этой статье мы рассмотрели что делать когда не загружается Linux. Как видите, может возникнуть достаточно различных проблем. Но преимущество Linux в том, что вы можете решить все это благодаря прямому доступу к файловой системе. Также, если домашняя папка вынесена в отдельный раздел, то если ничего не сработает - можно переустановить систему с минимальными потерями. Надеюсь, эта информация была полезной.

Нет похожих записей

Оцените статью:

(17 оценок, среднее: 4,94 из 5)

Об авторе

10 комментариев

Спасибо Сережа! С уважением А И

Линупс уже давно потерял свою привлекательность. Ещё 6-8 лет назад он был ничего. Отлично пахал на стареньких машинах, можно было и файлопомойку организовать и торрентокачалку, почта там, микросервер, etc. И все работало как winxp на 64-128 Мб оперативки за глаза (есессно не везде), да и вцелом какая-то лёгкость была. Но были и "детские проблемы" ввиде плохой организованности в работе с медиа, кривости драйверов, отсутствию нормальной поддержки образов нового поколения, софт опять же скудный и жалкий был. А сейчас жрет искаропки до 1 Гб, гигабайта, Карл! При этом детские проблемы не излечились, Южноафриканский Линукс стал каким то диким, в остальном какое то все глупое, рассчитанное на поиграться по типу арча, дженты и иже с ними, что там? Рюшечки, шрифтики, тайловые de, а как насчет автомонтирования без костылей? То то же. Те же детские проблемы. И не удивительно, что система падает, но как принято говорить, это не баг, это фича и rolling release, а во всех проблемах винить криворуких и хромых пользователей и ветку testing. Очень жаль, что все стало таким плачевным.

А, ты с чем сравниваешь? Если с семейством windows, то linux на порядок лучше. Уродство Гейтса слетает чаще и проблем больше, и еще к тому же за каждую мелочь денег просит, про вирусы вообще отдельный разговор. Не нравится южно-африканский используй какой нравится, сборок полно. Ну, а если хочешь под себя, берёшь ядро и делай правильный Linux с твоей точки зрения.

Дружок-пирожок, как там в 2017-м со взглядами из 2007-го?

У меня десятка три года стоит на одном компе, четыре на втором, рядом с убунтой. Где у меня было больше проблем? Невероятно, наверное для тебя, но в убунту

спосибо. Был бы еще хорош обзор, если линукс "завис".

Линупс не виснет! (с) Штульман

это конечно чудесные советы, но чтобы ими воспользоваться, нужно всё-таки, чтобы Линукс загрузился

Уважаемый Админ, прошу помощи.
Каюсь в своей криворукости заранее, дайте совет в каком направлении копать.
В общем суть проблемы, Linux Lite 3.8 ubuntu 16.04, заведена в домен средствами PBIS open (likewise-open), но пользователи доменные в терминале не работали с автозаполнением команд и при перемещении стрелками по клавиатуре терминал вместо запомненных команд выдавал символы нажатых клавиш.
Поставил пакеты apt-get install krb5-user, samba, winbind, libnss-winbind, libpam-winbind, терминал ругнулся что likewise несовместим с winbind, продолжить? Жамкнул - Да, заменил файлы, после перезагрузки убунта в режиме восстановления грузится (emergency mode) только по root.
Удалял эти пакеты, которые поставил, удалял их зависимости apt-get autoremove, не помогает, не знаю куда копать, рядом винда стоит по соседству, комп рабочий.
При загрузке стала пробегать строка
Spectre V2: Spectre mitigation:LFENCE not serializing, switching to generic retpoline

Можно как-то восстановить убунту или сносить и по новой ставить?
И еще - какой раздел лучше выбирать при установке, основной или логический или в принципе разницы никакой нет?

В меню загрузчика, в пункте дополнительные опции можно войти в режим восстановления. Здесь можно попытаться выполнить обновление системы, чтобы пакетный менеджер установил всё чего ему не хватает. Не знаю на что влияет домен, но могу предположить, что там монтировались какие-либо диски. Если система не может их смонтировать - это будет мешать загрузке. А вообще, чтобы что-то сказать надо видеть лог загрузки. Для этого надо в загрузчике (там можно редактировать пункт меню, если нажать F10) заменить опцию загрузки ядра quiet на verbose.

2021 год на дворе. Как выражаются опытные линукзятники, я решил уйти со своей гавно-лицензионной Windows 10 на которой проблем не знал вообще никогда и ни с чем, на мною уважаемый Debian Cinnamon. Скачал образ, залил на флешку, начал устанавливать. Устанавливал на SSD Kingston 250гб. Разбил диски, установил. Дебиан не загрузился. Как в пункте 1 посвился целый список, все было ОК, но потом было одно Failed. Я устанавливал вручную, подумал что накосячил. Снова установка. На этот раз выбрал опцию, чтобы при разбивке диска Дебиан сам все сделал. Он разбил. Я установил. Failed. Спасибо Дебиан.
Сейчас по всем правилам мне должны рассказать, что у меня руки кривые, железо кривое, видеокарта кривая, я кривой, и еще раз я кривой. Но тогда вопрос к вам - почему тот же Mint Mate поставился до этого на это же железо норм, а Великий Debian Cinnamon не смог? Минт я кстати снова поменял на Винду из-за ошибок, которые не лечатся годами:
1) невозможно поменять время на нужное;
2) Мате не поддерживает монитор 4к, а когда нашел как поддержать, то и тут всплыли дохренища багов с отображением.
3) Тот же YouTube выглядит как будто под слоем неведомой пыли со странным отображением цветов и контраста, хотя на Винде с этим проблем не было ни разу.
4) Звук шо то был тише, чем на Винде. Даже на Максимуме.
А мне обидно. Мне нравится Дебиан, и я хотел "Корицу". Но она меня не хочет. Уверен, если поставлю тот же Минт Корица, проблем не будет. Соглашусь с одним из комментариев выше - Линукс скатился. Раньше подавал признаки процветания, то сегодня возможно только окружение "Гном" и дистрибутивы "Манжаро" где-то дотягивают, хотя бы на 50% до возвожностей Виндовс 10.

Читайте также: