После установки 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 не грузится

Сегодня сделал «pacman -Syu», но после reboot система не грузится (lilo я выполнить не забыл). Причём даже не могу определить, где загрузка застопорилась. Значит так: lilo грузится, я выбираю «linux», потом

Что это может быть?

Мигает? Может паника у него?

Ничего не мигает. Та надпись, потом черный экран, ну и Numlock горит. Всё. Диск не шуршут, комп в ауте, ответных реакций от тыкания по клавишам нет.

После обновления arch не грузится

chroot, и обнови еще раз.
И логи почитать стоит внимательнее.

А старое ядро осталось? из лило доступно?
Если нет, то грузись с лайвсиди, чруться, откатывай ядро назад.

Попробуй в chroot linux переустановить.

Ты вовремя не сделал майнтейнерам арча пожертвование 🙂

И логи почитать стоит внимательнее.

Пролистал весь /var/log. Последние записи относятся к ещё работающей системе.

Тогда советую штудировать арче-форум, может кто-то уже столкнулся с проблемой.

А как же логи иксов и все остальное?

У меня такое было при обновлении linux-pf. Перезагрузился в «обычное» ядро (тормозящее, т.к. не pf, и без иксов, т.к. в него почему-то «вцементирован» дурацкий nouveau), потом перезагрузился в linux-pf. Почему-то все заработало. Что за хрень — не понимаю.

До иксов как до китая. Я же третий раз пишу, что загрузка ломается в самом начале. Loading Linux, BIOS data check. хана.

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

ещё, как вариант, поставь (с того же лайв-сиди примонтируй флешку, там) linux-lts и попробуй им загрузиться.

Добавьте параметры ядра loglevel=9 debug и повторите попытку. Ещё можно nomodeset, vga=6 и vga=791.

Закомментировал свою строку vga= и попробовал так. Это не помогло, но хотя бы что-то ядро написало там: фото.

Ну так добавьте vga=791, чтобы появился фреймбуффер 1024*768, и в него влез бы весь текст, а не только хвост бектрейса.

С initramfs всё в порядке? root=. указан правильно?

когда задаю vga=791, то вообще ничего не пишется, как я писал. в конфиге лило все прописано верно. я ничего не трогал. только обновился через пакмен.

Источник

Обновление сломало мне Arch Linux

Сегодня обновление убило мой Arch Linux на старом ноутбуке, чему я очень сильно удивился. Никогда такого не было и вот опять. Но ситуация довольно интересная, поэтому я оставлю описание этой проблемы и её решение на всякий случай на этом форуме. Вдруг кто придёт из поисковика, а у него такая же хрень окажется. Может помогу кому. Итак, фотография ошибки:

Вечером я просто обновился привычной всем командой yaourt -Syua и перегрузился в Windows (стоит в дуалбуте рядом с Fedora и Arch Linux) по делам. Ладно, вру, перегрузился чтобы поиграть в Half-Life и Unreal Tournament ’99. Поиграл на славу, снова решил загрузиться обратно в Arch Linux — получил ситуацию, которая запечатлена на фотографии выше.

Сначала я подумал, что каким-то неведомым образом слетел Fedora’вский grub , так как именно он обеспечивает мне, так сказать, «дуалбут» в три операционные системы: Windows 10, Arch Linux и Fedora 29. Загрузился в Fedora, выполнил привычные команды для восстановления grub ’а и обновления его конфигурации:

Перегрузился снова, в меню grub ’а выбрал Arch Linux — ситуация нисколько не изменилась. Тогда я решил, что при последнем обновлении слетели какие-то модули в ядре и из-за этого оно валится в панику. Снова загрузился в Fedora. Отмечу, что как же хорошо, что я её установил рядом и теперь не мучаюсь со всякими LiveUSB-флешками в подобных ситуациях, примонтировал rootfs от Arch Linux’а и с помощью скрипта arch-croot чрутнулся в него:

Из лога пакетного менеджера /var/log/pacman.log я вычленил список пакетов последнего обновления, которые могли испортить мне ядро и initramfs:

При установке VirtualBox с помощью DKMS незаметно для пользователя собираются и устанавливаются некоторые модули ядра, на которые я и грешил, а потому переустановил эти пакеты заново:

На всякий случай само ядро, пакет linux , я тоже переустановил. Перезагрузился — ситуация нихрена не изменилась. Подумал, раз ядро паникует от init ’а, может проблема в systemd ? Его же всегда и все винят во всех бедах! В третий раз загрузился в Fedora, переустановил пакет systemd и перегенерировал initramfs:

Перегрузился, постучался в Arch Linux — проблема не ушла. Очень странно! Пришлось в четвёртый раз грузиться в Fedora и начать гуглить инфу по этой ошибке. Поисковый запрос «kernel panic not syncing no init found arch linux» сразу же привёл меня в тему на форуме Arch Linux, благодаря которой я и решил эту проблему: [SOLVED] Kernel Panic — not syncing. No working init found. Человек на том форуме столкнулся с похожей ситуацией.

Итак, восстановление работы поломанного Arch Linux’а и расследование почему так случилось, ибо проблемка-то и не очень уж тривиальная. Из темы на форуме Arch Linux, по ссылке выше тот человек перепробовал все действия, которые попробовал я и у него тоже не получилось сначала восстановить работоспособность системы. Потом знатоки на том форуме посоветовали ему выполнить команду:

Для определения различных ошибок в структуре файловой системы. Я тоже её выполнил и так же как и в той теме наткнулся на странную проблему со сущностью /usr/lib64 , которая в нормальных условиях ожидаемо должна быть симлинком на /usr/lib . У меня же этот файл вообще отсутствовал, а у того человека на форуме вместо симлинка был пустой каталог.

Механизм возникновения проблемы

Итак, судя по сообщению пользователя Scimmia:

There’s been a number of people without /usr/lib64/. I’m guessing it’s because of a updated that was —force ’d. Don’t do that.

В pacman ’е имеется какой-то странный баг или поведение, когда при опции —force или —overwrite нарушается структура файловой системы, в частности, имеется вероятность неведомым образом снести симлинк /usr/lib64 или вместо него создаётся пустая директория, как у того человека с форума. Судя по логу, я действительно обновлял какой-то пакет из AUR’а с этой опцией из-за того, что установка ругалась на какие-то существующие файлы и не придал этому значение после. Но самый цимес в том, что обновлял я этот пакет целых три месяца назад и этот —force и вылетел у меня из головы.

Что интересно, само отсутствие /usr/lib64 похоже никоим образом не влияет на работоспособность системы. Если бы что-то отвалилось и перестало работать сразу после обновления и перезагрузки, то было бы легче догадаться в чём же именно дело. Но этот симлинк /usr/lib64 в rootfs каким-то странным и неведомым способом влияет на построение образа initramfs, а поэтому Arch Linux рассыпался только спустя три месяца (sic!), когда прилетело обновление VirtualBox, которое обновило свои модули ядра и потребовало перегенерировать initramfs, генератор которого видя отсутствие симлинка /usr/lib64 тупо взял и сгенерировал мне кривой образ, из-за которого ядро посыпалось в панику.

Решение проблемы

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

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

Вердикт

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

Источник

Не загружается Linux, чиним загрузчик GRUB

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

Что такое Grub

Grub (или GRand Unified Bootloader) — загрузчик операционных систем с открытым исходным кодом. Распространяется он под лицензией GNU GPL, в полностью свободном виде. С помощью этого замечательного лоадера можно сделать много всего — основная же функция не ограничивается загрузкой лишь одной операционной системы. Вы можете иметь куда больше операционных систем на своем ПК, загружая любую из них с помощью Grub. На скриншоте выше вы можете видеть как примерно Grub выглядит. Кстати говоря, если вы захотите установить Ubuntu 18.04 рядом с Windows, вам определенно понадобится помощь Grub.

Grub используется в большинстве дистрибутивов Linux в качестве загрузчика по-умолчанию. Разумеется и с ним иногда возникают проблемы. Этим самые проблемы чреваты полным отказом операционной системы. Поэтому для починки Grub нам понадобятся дополнительные инструменты. Какие именно — узнаете далее.

От чего могут возникнуть проблемы

Одна из самых распространенных причин — это неправильный порядок установки двух операционных систем (Linux и Windows). Допустим, если вы захотите установить две этих операционных системы на свой ПК — вам непременно стоит знать правильную последовательность:

• Сначала устанавливаем Windows
• И только потом уже Linux

Если, например, сделать наоборот, то как раз-таки Grub будет поврежден; система будет грузиться напрямую в Windows, а дистрибутив Linux останется недоступным.

Grub может сломаться и по другим причинам. Например, из-за попыток ручного изменения параметров запуска (при недостатке опыта), в таком случае нужно будет либо вручную убирать лишнее, либо полностью переустанавливать Grub.

Восстановление Grub с помощью LiveCD/USB

Для этого способа нам понадобится флешка с дистрибутивом Linux на борту. Подойдет любой: от Ubuntu, Arch или даже Linux Mint. Здесь нужен только терминал, поэтому подойдет даже версия без графической оболочки.

Как создать LiveCD/USB

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

Идем на официальную страницу загрузки. Загружаем любую понравившуюся версию (лучше взять новейшую для десктопа), после чего записываем ее на USB/CD.

С помощью Rufus:

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

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

Находим загруженный образ через менеджер, после чего жмем «Старт».

С помощью Etcher:

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

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

Открываем таблицу разделов с помощью команды:

Примерно такая таблица будет выведена на экран:

По этой таблице мы видим, что Linux, в нашем случае, расположен на разделе /dev/sda1.

С помощью следующей команды мы смонтируем этот раздел в /mnt:

Теперь, для записи grub в MBR, нужно ввести следующую команду:

Если нужно только восстановить MBR диска (после переустановки Windows, к примеру), то этих действий будет вполне достаточно.

Если же необходимо обновить и меню grub (после установки Windows), то нужно выполнить еще и эту команду:

Вот и все, восстановление закончено!

Восстановление с помощью chroot

Помимо вышеописанного способа, при восстановлении Grub с помощью LiveCD можно использовать и этот. Тут мы будем использовать утилиту chroot.

Здесь нам, опять же, понадобится таблица разделов. Вводим уже известную команду:

В выводе снова будет эта таблица. Теперь нам надо присмотреться к ней еще внимательнее.

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

Обратите внимание, что если если разделы /boot или /var находятся отдельно, то Вам нужно будет примонтировать их в /mnt/boot и /mnt/var.

Далее мы переходим в окружающую среду chroot с помощью команды:

И теперь, наконец-таки переустанавливаем Grub с помощью следующей команды:

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

Если все прошло успешно, выходим из chroot, используя команду:

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

В случае, если вы монтировали раздел /boot введите команду:

Теперь перезагружаем систему с помощью:

Можно также обновить меню Grub, используя команду:

Восстановление Grub в rescue mode

Если по каким-то причинам у вас нет доступа к LiveCD/USB-носителю, а также к компьютеру, с помощью которого этот самый носитель можно было бы сделать, то этот способ для вас.

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

Одна из этих частей (первая) записана в MBR диска. В ней присутствует базовый функционал и ничего больше (консоль в rescue mode).

Стало быть, нам нужно определить, в каком разделе находится вторая часть Grub (находится в каталоге /boot/grub), и после чего подгрузить все недостающие модули. А вот уже после этого мы сможем запустить загрузчик с нужного раздела. В rescue mode есть всего четыре команды:

Для начала вводим следующую команду:

В выводе будет что-то подобное:

В некоторых случаях Grub неправильно опеределяет файловые системы находящиеся на разделах дисков. В данном примере загрузчик показывает их как msdos. Мы должны попытаться угадать диски, которые видим. В примере доступно два диска. Диск с индексом 0 содержащий три раздела, и диск с индексом 1 содержащий два раздела. Если вы знаете структуру своих дисков, определить нужный труда не составит.

В загрузчике Grub разделы нумеруются в обратном исчислении. Не очень ясно какой именно из разделов назван, к примеру (hd0,msdos3). Чтобы было более понятно, можно использовать вид (hd0,1). Если в грабе отсчет дисков идет с 0, а разделов с 1, то можно определить, что операционная система установлена в первый раздел первого раздела — (hd0,1). Используем следующую команду:

С помощью этих команд мы приказываем системе использовать какой-то конкретный диск, для выполнения всех остальных операций (в нашем случае, это диск (hd0,1)). Чтобы проверить есть ли на данном диске загрузчик, введем эту команду:

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

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

Чтобы закрепить результат (и не проделывать все то же самое после перезапуска ПК), нужно зайти в терминал своего дистрибутива Linux, где с root правами выполнить следующую команду:

sdX — диск, на который должен быть установлен Grub.

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

И подгрузить модули:

Ну и теперь запустить GRUB:

Восстановление Grub с помощью утилиты Boot repair

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

Чтобы установить boot repair, вы можете воспользоваться одним из приведенных способов:

• Запись и установка специального образа диска Boot Repair (и дальнейшая загрузка с него)
• Установка Boot repair из PPA-репозитория в LiveCD/USB дистрибутиве.

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

В утилите будет доступно два варианта на выбор:

Recommended repair исправляет большую часть известных ошибок, которые могли бы возникнуть при запуске. С его помощью вы сможете пофиксить и загрузчик Grub.

Create a BootInfo summary создает Boot-Info-Script – скрипт, который позволяет диагностировать большинство проблем при загрузке.

Здесь же есть и Advanced options. Он включает в себя варианты для восстановления и настройки загрузчика Grub2 (загрузка по-умолчанию, опции загрузки ядра, отображение или скрытие GRUB при загрузке, удаление GRUB). С помощью этих же инструментов, вы можете восстановить MBR и т.д.

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

Выводы

Вот мы и рассмотрели несколько вариантов исправления загрузчика Grub. Стоит сказать, что некоторые из них могут показаться сложными или даже невыполнимыми. Это не так, каждый из рассмотренных способов нашел подтверждение в виде сотен и тысяч актов исправления загрузчика Grub в опенсорсном сообществе. Кстати говоря, какой из способов выбрать — решать только вам, любой из них достаточно эффективен, чтобы попасть в этот материал.

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

Источник