Arch linux не грузится

Arch не загружается после установки

Итак, спустя 2 дня после использования арча, он просто перестал загружаться. При загрузке ОС я попадаю в консоль, в которой ничего кроме «Starting version 245.6-4-arch root: recovering journal root: clean, 228763/1638400 files, 2765734/6553600 blocks» Не выдает. Консольный курсор просто мигает, как бы символизируя, что ОС не может загрузиться.

Гуглинг не помог, единственное, что я понял так это то, что boot каталог куда-то пропал. Когда я загрузился с установочного образа арча и попытался примонтировать dev/sda1 к каталогу /mnt/boot мне выдало, что mnt/boot directory doesn’t exist. Потом я попробовал создать каталог /boot через mkdir и примонтировать таки удалось. То есть,boot исчез из раздела и это является причиной моей проблемы.

В связи с чем у меня назревает два вопроса: Как решить эту проблему без полной переустановки арча? Как избежать повторения подобных необьяснимых случаев?

Когда я загрузился с установочного образа арча и попытался примонтировать dev/sda1 к каталогу /mnt/boot мне выдало, что mnt/boot directory doesn’t exist. Потом я попробовал создать каталог /boot через mkdir и примонтировать таки удалось. То есть,boot исчез из раздела и это является причиной моей проблемы.

Бредовые действия и бредовые же выводы.

Давай нормальную диагностику. Загрузись снова с нуля с установочного образа Arch или лучше с любого Linux с GUI и выполни команды

Как вариант, задействуй https://www.system-rescue-cd.org/ — как раз на базе Arch и имеет GUI.

Когда я загрузился с установочного образа арча и попытался примонтировать dev/sda1 к каталогу /mnt/boot мне выдало, что mnt/boot directory doesn’t exist. Потом я попробовал создать каталог /boot через mkdir и примонтировать таки удалось. То есть,boot исчез из раздела и это является причиной моей проблемы.

Неверный вывод. Это всего лишь значит, что в установочном образе по умолчанию не создан каталог /mnt/boot.

Каждый раз такое? Это странно.

попытался примонтировать dev/sda1 к каталогу /mnt/boot мне выдало, что mnt/boot directory doesn’t exist

Естественно. Ты монтируешь в файловой системе live системы, а не той что у тебя установлена. Конечно там не будет /mnt/boot.

То есть,boot исчез из раздела и это является причиной моей проблемы.

Не пойму, с чего ты так решил. Если ты сделал

mount /dev/sda1 /mnt/boot

то теперь сделай

и посмотри есть ли там нужные файлы.

Вообще, если бы у тебя исчез boot, то исчезло бы и ядро которое в нем как раз лежит. А ядро у тебя же как-то запускается. То есть причина явно не в этом.

Источник

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

Если ваш Arch Linux не загружается или загружается в чёрный экран, то начните с переключения на другой терминал сочетаниями клавиш Ctrl+Alt+F1, Ctrl+Alt+F2, Ctrl+Alt+F3 и так далее. Если вам это удалось и вы увидели приглашение ввести учётные данные для входа в систему, то дальше всё элементарно — выполните вход и откатите изменения, из-за которых система не запускается.

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

Ещё один пример трудной ситуации — полное удаление загрузочного диска (у меня такое случалось).

Manjaro и другие дистрибутивы на основе Arch Linux предлагают инсталяторы с графическим интерфейсом для установки операционной системы. Но если вы устанавливали Arch Linux вручную (как описано в Инструкции по установке Arch Linux), то могли обратить внимание, что мы устанавливаем пакеты и настраиваем систему загрузившись с Live образа. Этот же самый приём можно использовать для исправления проблем любой сложности — даже если ваша система абсолютно неработоспособна и не загружается, её всё равно можно исправить!

Загрузитесь в другую операционную систему — для этого можно установить Linux на флешку и держать эту флешку для подобных случаев. Кстати, вы можете использовать старую флешку, размером меньше 1 гигабайта, чтобы всегда держать на ней Live образ Arch Linux — специально на случай такой проблемы.

Начните с загрузки образа Arch Linux с официального сайта: https://www.archlinux.org/download/

Для записи используйте программу Etcher (сайт https://www.balena.io/etcher/), которая прекрасно работает в любой операционной системе. Подробности об этой программе смотрите в статье «Etcher: запись образов ОС на флешки и USB диски».

Как восстановить загрузочный диск Arch Linux

Если у вас повреждён или удалён загрузочный раздел, то загрузите Live образ Arch Linux с флешки и выполните следующие команды.

Обратите внимание, что вместо nvme0n1p1 вам нужно указать имя вашего загрузочного раздела, это может быть, например, /dev/sdb1. Чтобы посмотреть список всех дисков, выполните команду:

Форматируем разгрузочный раздел в FAT32:

Меняем значение корневой директории на новую:

Выполняем установку загрузчика

Редактируем содержимое файла:

Удалите то, что там есть и впишите туда:

Создайте конфигурационный файл для добавления пункта Arch Linux в менеджер systemd-boot:

Содержимое файла должно быть следующим:

Обратите внимание на /dev/nvme0n1p2 — это путь до моего диска с системой, замените на свой.

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

Можно вынимать установочный диск.

Как удалить программу, из-за которой не загружается Arch Linux

Иногда загрузка не выполняется из-за установленной программы или наоборот, из-за удаления необходимого пакета.

Загрузите Live образ Arch Linux с флешки и выполните следующие команды. Обратите внимание, что вместо nvme0n1p1 и nvme0n1p2 вам нужно указать имена разделов вашего диска, это может быть, например, /dev/sdb1 и /dev/sdb2. Чтобы посмотреть список всех дисков, выполните команду:

Меняем значение корневой директории на новую:

По умолчанию вы являетесь пользователем root, но вы можете сменить пользователя существующего в системе, которую мы восстанавливаем. Это может быть полезно, так как нам будет доступна история команд этого пользователя и мы без труда вспомним, какие конфигурационные файлы мы редактировали и какие пакеты устанавливали/удаляли как раз перед невозможностью загрузиться.

Например, на нерабочей системе последние команды выполнялись от пользователя mial, выполним вход как этот пользователь:

Теперь для установки пакетов используйте команду вида:

А для удаления пакетов используйте команду вида:

Источник

General troubleshooting (Русский)

General troubleshooting — Устранение общих неполадок в системе. Эта статья дает советы по устранению общих проблем. Для решения проблем, связанных с конкретной программой, посетите соответствующую страницу Wiki.

Contents

Общие процедуры

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

1. Запустите приложение в терминале, чтобы можно было просмотреть, что оно выводит в stdout/stderr.
   1. Включите более подробный вывод информации (обычно для этого у приложения есть параметр вроде —verbose / -v / -V или —debug / -d ), если информации всё ещё недостаточно для отладки.
   2. Иногда такого параметра нет, и нужно включать подробный вывод в файле настроек приложения.
   3. Приложение также может записывать информацию в файл журнала. Обычно журналы располагаются в /var/log , $HOME/.cache или $HOME/.local .
   4. Если в приложении нет возможности включить подробный вывод, всегда можно запустить strace и другие подобные программы.
2. Проверьте журнал systemd. Возможно, ошибка оставила следы и в этом журнале, особенно если она влияет на другие приложения.
   1. dmesg показывает сообщения из кольцевого буфера ядра. Это полезно, если диск по какой-то причине недоступен, но этот журнал может быть неполным, так как размер буфера ограничен. По возможности используйте journalctl .
   2. journalctl имеет больше опций по поиску и фильтрации сообщений, чем dmesg , и по умолчанию использует человекочитаемые временные метки.
3. Всегда рекомендуется проверять соответствующие баг-трекеры, чтобы узнать, известна ли ваша проблема и есть ли её решение.
   1. В зависимости от того, что предпочитают разработчики, обычно есть баг-трекер, а иногда и форум или даже, например, IRC-канал.
   2. Существует баг-трекер Arch Linux, который следует использовать в первую очередь для ошибок в создаваемых пакетах.

Дополнительная поддержка

Если вам нужна дополнительная поддержка, вы можете спросить об этом на форуме] или в IRC.

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

• Полный вывод всех задействованных команд — не выбирайте только то, что считаете нужным.
• журнал systemd.
  • Для более подробного вывода используйте параметр загрузки systemd.log_level=debug . Логов станет очень много, поэтому включайте его только при необходимости.
  • Не используйте параметр -x , поскольку он загромождает вывод и затрудняет его чтение.
  • Используйте параметр -b , если не требуются журналы предыдущих загрузок. Отсутствие этого параметра может вывести очень много старых логов, которые могут даже оказаться слишком большими для pastebin-сервисов.
• Релевантные файлы конфигурации
• Задействованные драйверы
• Версии связанных с проблемой пакетов
• Журнал ядра: journalctl -k или dmesg (для запуска обоих нужны права root).
• Xorg: в зависимости от установки, используемый экранный менеджер тоже может иметь значение.
  • Xorg.log может быть расположен в одном из нескольких мест: системный журнал, /var/log/ или $HOME/.local/share/xorg/ .
  • Некоторые экранные менеджеры, например LightDM, также могут помещать Xorg.log в свой собственный каталог журналов.
• Pacman: Если недавнее обновление что-то сломало, посмотрите в /var/log/pacman.log .
  • Может быть полезно использовать параметр —debug .

Один из лучших способов опубликовать эту информацию — использовать pastebin.

Pastebin-сервис выдаст вам ссылку, которую можно будет отправить на форум или в IRC.

Проблемы загрузки

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

1. Прошивка (UEFI или BIOS)
   1. Обычно имеет только базовые инструменты для отладки.
   2. Убедитесь, что Secure Boot отключен.
2. Загрузчик
   1. Одна из самых распространённых операций здесь — изменение параметров ядра.
3. initramfs
   1. Обычно предоставляет аварийную оболочку (emergency shell).
   2. В зависимости от выбранных хуков, в ней доступен либо dmesg, либо журнал.
4. Собственно система
   1. В зависимости от того, насколько сильно она повреждена, здесь может быть достаточно простого вызова оболочки восстановления.

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

Сообщения консоли

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

Обратите внимание, что, независимо от выбранного варианта, сообщения ядра можно посмотреть после загрузки с помощью journalctl -k или dmesg . Для отображения всех журналов текущей загрузки используйте journalctl -b .

Управление потоком

Это базовое управление, которое применимо к большинству эмуляторов терминала, включая виртуальные консоли (VC):

• Нажмите Ctrl+s , чтобы приостановить вывод.
• И Ctrl+q , чтобы возобновить его.

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

Чтобы увидеть сообщения об ошибках, которые уже были выведены на экран, смотрите getty (Русский)#Отображение загрузочных сообщений на tty1.

Отладочный вывод

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

• debug включает отладочные сообщения как для ядра, так и для systemd
• ignore_loglevel заставляет печатать все сообщения ядра.

Можно добавить и другие параметры, которые могут быть полезны в определённых ситуациях:

• earlyprintk=vga,keep печатает сообщения ядра в самом начале процесса загрузки, в случае, если ядро аварийно завершает работу до появления вывода. Вы должны изменить vga на efi для систем EFI.
• log_buf_len=16M выделяет больший (16 МиБ) буфер сообщений ядра, чтобы гарантировать, что отладочный вывод не будет перезаписан.

Существуют также параметры для включения отладки определённых подсистем, например bootmem_debug , sched_debug . Кроме того, initcall_debug может быть полезен для исследования зависаний загрузки. (Ищите вызовы, которые не завершились.) Более подробная информация есть в документации по параметрам ядра.

netconsole

netconsole — это модуль ядра, который отправляет все сообщения журнала ядра (например, dmesg) по сети на другой компьютер, не задействуя userspace (например, syslogd). Название «netconsole» не очень корректное, так как на самом деле это не консоль, а скорее служба удалённого логирования.

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

Оболочки восстановления

Попадание в оболочку восстановления (recovery shell) в процессе загрузки может помочь вам точно определить, где и почему что-то не работает. Есть несколько связанных с этим параметров ядра, но все они запускают обычную оболочку, из которой можно выйти, чтобы ядро продолжило свою работу:

• rescue запускает оболочку вскоре после перемонтирования корневой файловой системы чтение/запись
• emergency запускает оболочку ещё раньше, до того, как большинство файловых систем будут смонтированы
• init=/bin/sh (в крайнем случае) изменяет программу init на командную оболочку, которая запустится от имени root. И rescue , и emergency полагаются на systemd, а подмена init будет работать, даже если systemd сломан.

Другим вариантом является debug-shell от systemd, который добавляет root shell на tty9 (переключиться туда можно с помощью Ctrl+Alt+F9 ). Его можно включить, либо добавив systemd.debug_shell в параметры ядра, либо включив debug-shell.service .

Отладка модулей ядра

Отладка оборудования

• Можно вывести дополнительную отладочную информацию об оборудовании, как описано в статье udev (Русский)#Отладочная печать.
• Убедитесь, что обновления микрокода применяются в вашей системе.
• Для тестирования оперативной памяти смотрите Stress testing#Stressing memory [ссылка недействительна: раздел не найден] .

Отладка зависаний

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

• Продолжает ли играть звук? Если да — видимо, просто завис экран. Это могут быть проблемы с видеодрайвером.
• Отвечает ли компьютер на запросы? Попробуйте подключиться по SSH, если переключение в консоль не работает.
• Индикатор HDD (если есть) показывает высокую нагрузку на диск? Вероятно, используется слишком много памяти и система начала активно использовать файл подкачки. Смотрите ответ на StackExchange для получения информации о зависании при большой записи.

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

Удалённое чтение журнала может помочь, если зависание не позволяет записать что-либо на диск. Самое простое и примитивное решение для базовой отладки может быть таким:

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

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

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

Отладка регрессий

Если обновление вызывает проблему, но понижение версии конкретного пакета устраняет её — скорее всего, это регрессия. Наиболее важной частью отладки регрессий является проверка того, была ли проблема уже исправлена, поскольку это может сэкономить много времени. Для этого сначала убедитесь, что приложение полностью обновлено (например, убедитесь, что приложение имеет ту же версию, что и в официальных репозиториях). Если оно уже обновлено или если обновление не устраняет проблему, попробуйте использовать актуальную последнюю версию, обычно версию -git, которая может быть доступна в AUR. Если это устранит проблему, а версии с исправлениями ещё нет в официальных репозиториях, подождите, пока новая версия не появится в них, а затем перейдите на неё.

Если проблема не исчезла, отладьте её и/или проведите bisect и отправьте сообщение об ошибке в баг-трекер программы, чтобы разработчики узнали о ней и смогли её исправить.

Не получается использовать подключаемые устройства после обновления ядра

Чаще всего (но не только) это проявляется как:

• только что подключенные USB-накопители отображаются в dmesg, но отсутствуют в /dev/ ,
• не получается использовать проводное/беспроводное соединение на ноутбуке, если оно ещё не использовалось перед обновлением ядра,
• modprobe выдаёт ошибку FATAL: Module модуль not found in directory /lib/module/версияядра при попытке загрузить модуль, который ещё не использовался перед обновлением ядра.

Как частично описано в разделе Обслуживание системы#Перезагружайтесь после обновлений, ядро будет обновлено не в момент обновления пакета, а только после перезагрузки. При этом модули ядра, расположенные в каталоге /usr/lib/module/версияядра/ , удаляются pacman’ом при установке нового пакета ядра. Как объясняется в FS#16702, такой подход позволяет не оставлять в системе файлы, не обрабатываемые менеджером пакетов, но приводит к вышеупомянутым симптомам. Чтобы устранить их, перезагружайтесь после обновления ядра. Более хорошим решением, которое ещё не реализовано, будет использование разных пакетов для разных версий ядра: основная проблема заключается в том, как обрабатывать удаление предыдущих версий ядра, когда они больше не нужны.

Другое решение доступно в виде kernel-modules-hook , где два хука pacman используют rsync для сохранения модулей ядра в файловой системе после обновления ядра, а служба systemd удаляет старые модули через четыре недели после этого.

Менеджер пакетов

Исправление сломанной системы

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

Если вы обычно загружались в графический интерфейс, а сейчас он не работает, можно попробовать попасть в консоль с помощью Ctrl+Alt+F1 — Ctrl+Alt+F6 и в ней запустить pacman.

Если система сломана настолько, что вы не можете запустить pacman, загрузите Arch ISO с USB-накопителя, компакт-диска или по сети через PXE. (Выполнять остальные шаги по установке системы не нужно.)

Загрузившись в Arch ISO, примонтируйте корневую файловую систему:

Примонтируйте внутри /mnt другие нужные разделы, если вы их создавали, например:

Затем попробуйте зайти в chroot и запустить pacman в нём:

Если это не работает, выйдите из chroot и попробуйте:

Если и это тоже не работает, попробуйте:

Совместная отладка в IRC

fuser

fuser это утилита командной строки для определения процессов использующих ресурсы, таких как файлы, файловые системы и порты TCP / UDP.

fuser содержится в пакете psmisc , который должен быть уже установлен как часть мета-пакета base . Подробности есть в fuser(1) .

Разрешения сессии

Во-первых, убедитесь, что у вас есть действующий локальный сеанс X:

Должны получить на выходе Remote=no и Active=yes . Если это не так, убедитесь, что X работает на томже tty, где и произошел вход. Это нужно чтобы сохранить сеанс logind. Который обрабатывается по умолчанию /etc/X11/xinit/xserverrc .

Основные polkit действия не требуют дальнейшей настройки. Некоторые действия polkit требуют дальнейшей проверки подлинности, даже при местной сессии. Для этой работы агент аутентификации polkit должен быть запущен. Смотрите больше информации по polkit#Authentication agents.

Ошибка при загрузке разделяемых библиотек

Если при использовании программы, вы получите сообщение об ошибке подобное:

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

В этом случае должен быть установлен пакет libusb-compat . Также может оказаться, что зависимую программу нужно пересобрать после обновления библиотеки до новой версии (soname bump).

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

Источник