Достигнута целевая базовая система Centos 7 зависает

Обновлено: 04.07.2024

К сожалению, я отформатировал диск /dev/sda2. Таким образом, всех /root , /home , swap LVM больше не существует. Из-за этого мой сервер не может работать должным образом.

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

У меня возникла такая же проблема при использовании Centos на виртуальной машине. и я исправил это, изменив функции Windows Hyper-V. потом запустилось нормально

4 ответа 4

В аварийной оболочке dracut:

Dracut предлагает оболочку для интерактивной отладки в случае, если dracut не может найти вашу корневую файловую систему. Чтобы включить оболочку:

Добавьте параметр загрузки ''rd.shell'' в файл конфигурации загрузчика (например, /etc/grub.conf)

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

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

rd.shell=Это представит оболочку, если dracut не сможет найти ваше корневое устройство

Удалите аргументы загрузки ''rhgb'' и ''quiet''. Пример файла конфигурации загрузчика /etc/grub.conf указан ниже.

серийный номер --unit=0 --speed=9600

терминал --timeout=5 последовательная консоль

заголовок Fedora (2.6.29.5-191.fc11.x86_64)

ядро /vmlinuz-2.6.29.5-191.fc11.x86_64 ro root=/dev/mapper/vg_uc1-lv_root console=tty0 rd.shell

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

Корневое устройство не найдено. Переход к оболочке отладки. sh: нет доступа к tty; управление заданиями отключено

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

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

• Блочное устройство (например, /dev/sda7)

• Логический том LVM (например, /dev/VolGroup00/LogVol00)

• Зашифрованное устройство (например, /dev/mapper/luks-4d5972ea-901c-4584-bd75-1da802417d83)

6.Точный метод обнаружения и подготовки может различаться. Однако, чтобы продолжить успешную загрузку, цель состоит в том, чтобы найти корневой том и создать символическую ссылку /dev/root, указывающую на файловую систему. Например, в следующем примере демонстрируется доступ и загрузка корневого тома, который является зашифрованным логическим томом LVM.

Вы помните, что ваш корневой том был логическим томом LVM. Сканировать и активировать любые логические тома

Вы должны увидеть все логические тома с помощью команды blkid:

/dev/sda1: UUID="3de247f3-5de4-4a44-afc5-1fe179750cf7" TYPE="ext4"

/dev/mapper/linux-root: UUID="def0269e-424b-4752-acf3-1077bf96ad2c" TYPE="crypto_LUKS"

/dev/mapper/linux-home: UUID="c69127c1-f153-4ea2-b58e-4cbfa9257c5e" TYPE="ext3"

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

"найдите свой корневой том и создайте символическую ссылку /dev/root, которая указывает на файловую систему" Я сделал символическую ссылку (на самом деле у меня была проблема с /dev/mapper/live-rw), но работает для (этого устройства)» по-прежнему отображается и не загружается.

Шаг 1. Введите journalctl

Шаг 2. Найдите ошибку

Виртуальные машины EL7, импортированные из виртуального устройства VirtualBox, могут не запускаться на Oracle VM или Xen с той же ошибкой.

Виртуальные машины под управлением EL7, экспортированные из Oracle VirtualBox в качестве виртуального устройства, а затем импортированные в виртуальную машину Oracle, могут загружаться неправильно и могут выйти в аварийную оболочку. Это вызвано отсутствием драйвера xen-blkfront в образе initramfs. Обычно вывод во время загрузки для уязвимых систем выглядит следующим образом:

Обходной путь. Есть два обходных пути решения этой проблемы. Первый включает добавление отсутствующих драйверов перед экспортом виртуальной машины Oracle Linux 7 из Oracle VirtualBox. Для этого выполните следующую команду от имени пользователя root перед выполнением экспорта:

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

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

Перезагрузите виртуальную машину после добавления драйверов в initramfs.

Привет,
Я работаю над сервером на платформе Greenlow. Теперь столкнулся с проблемой: зависание системы после вывода «Достигнута целевая базовая система."
Мой вопрос: какая функция ядра выдаст это сообщение? Я могу продолжить отслеживать эту проблему, если найду имя функции.

Спасибо
[ 0.000000] tsc: Ошибка быстрой калибровки TSC
ÿ[ 2.279076] i8042: Контроллер не найден
[[32m OK [0m] Started Show Plymouth Boot Screen.

[[32 минуты OK [0 минут] Достигнуты целевые пути.

[[32 минуты OK [0 минут] Достигнута целевая базовая система.

Ответы

Можно ли переключиться на другой терминал, например, нажав Alt+F2 ? Если да, попробуйте запустить

Должны отображаться сообщения журнала текущей загрузки.

Сообщение, о котором вы спрашиваете (Достигнута целевая базовая система) выводится systemd при загрузке базовой системы — за этим может последовать запуск графического интерфейса и различных системных служб. См. справочную страницу bootup(7) для получения дополнительной информации о последовательности загрузки.

Я также сталкиваюсь с той же проблемой, за которой следует тайм-аут dracut

У меня та же проблема, я не могу получить доступ к терминалу, нажав ALT+2

"Достигнута целевая базовая система" не является сообщением ядра: оно исходит от initramfs. Вы можете получить диагностическую оболочку, используя параметр rd.break=
boot.

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

предоставит вам диагностическую оболочку перед сообщением "Достигнута целевая базовая система" (= сразу после сообщения "Запущен диспетчер устройств ядра udev") и параметром загрузки

вызовет диагностическую оболочку сразу после сообщения "Достигнута целевая базовая система".

Другие виртуальные консоли в этот момент использовать нельзя, так как шаг "Запущена служба входа" еще не достигнут. Вот почему Alt+F2 не работает.

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

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

Это очень странно. В последнее время я даже не обновлял 'dom0', и система закрылась начисто. Но это просто не начнется сегодня.

Если я не могу восстановить систему Qubes-OS в целом, пожалуйста, помогите мне восстановить данные/файлы, которые у меня есть в моих томах AppVM. Как это может быть сделано.

Это чрезвычайная ситуация для меня, и я был бы безмерно благодарен за чью-либо помощь, чтобы либо исправить загрузку системы, чтобы она могла начаться снова, либо помочь подключить мой системный диск к другой ОС и получить данные.

Джейен Десаи

Вы пробовали использовать режим восстановления с помощью установочного носителя? Вы можете попробовать это, и я считаю, что это должно помочь. Я использовал режим восстановления для редактирования моего файла xen.cfg, который помог мне снова загрузить систему, если я передал какие-то неправильные параметры в xen.cfg. Вы можете войти в режим спасения, нажав ctl+alt+f5. Может быть, это поможет вам.

Спасибо за ваше предложение. Я попробовал, но, к сожалению, система еще не восстановлена. (Я предполагаю, что вы ссылались на следующие команды для входа в режим восстановления: pkill -9 anaconda; anaconda --rescue; )

Это позволило мне увидеть логическую структуру томов qubes_dom0, представляющих AppVM, но мне не удалось смонтировать эти тома, чтобы получить доступ к данным.

Команда «lvscan» показывает статус LV рядом с каждым томом, и только «swap» помечен как активный. Все остальное было «НЕ активным», включая тома «root», «pool00» и AppVM.

Есть ли у вас или у кого-либо еще какие-либо идеи, как действовать дальше? Я должен восстановить данные. Надеюсь, они не испортились, только точка доступа пропала.

необходим

> Спасибо за ваше предложение. Я попробовал, но, к сожалению, система еще не восстановлена. (Я предполагаю, что вы ссылались на следующие команды для входа в режим восстановления: pkill -9 anaconda; anaconda --rescue; )
>
> Я также пытался смонтировать свой диск Qubes в LinuxMint, используя команды:
> cryptsetup luksOpen /dev/sda2 qubes-disk;
> затем pvscan, pvdisplay, vgscan, vgdisplay, lvscan, lvdisplay.
>
> Это позволило мне увидеть логическую структуру моих томов qubes_dom0, томов, представляющих AppVM, но мне не удалось смонтировать эти тома, чтобы получить доступ к данным.
> Команда «lvscan» показывает статус LV рядом с каждым томом, и только «swap» был помечен как активный. Все остальное было «НЕ активным», включая тома «root», «pool00» и AppVM.
>
> Есть ли у вас или у кого-либо еще какие-либо идеи, как действовать дальше? Я должен восстановить данные. Надеюсь, они не испортились, только точка доступа пропала.
>

Вы находитесь в нужном месте, но я не вижу "vgchange -ay" в вашем списке
команд?

Это позволило мне увидеть логическую структуру моих томов qubes_dom0, представляющих AppVM, но мне не удалось смонтировать эти тома, чтобы получить доступ к данным.

Команда «lvscan» показывает статус LV рядом с каждым томом, и только «swap» помечен как активный. Все остальное было «НЕ активным», включая «root», «pool00» и тома AppVM.

У всех остальных lv'sn (которых у меня 86) "Статус LV" установлен на "НЕДОСТУПНО", и я не могу сделать их активными. Также vgchange не смог их активировать.

Существуют ли специальные инструменты восстановления LUKS/LVM2 (кто-то упомянул "скальпель", но я еще не пробовал)?

Я был бы признателен за любые подсказки в правильном направлении извлечения данных с моего зашифрованного диска luks qubes.

необходим

> Привет,
> Да, я попробовал команду "vgchange -ay", и она выдает сообщение об ошибке:
> "Проверка пула qubes_dom0/pool00 не удалась (статус: 1). Требуется ручное восстановление!
> 1 логический том (тома) в группе томов "qubes_dom0" теперь активен. "
>
> Этот единственный активный том называется "swap".
> У всех остальных lv'sn (которых у меня 86) "Статус LV" установлен на "НЕДОСТУПНО", и я не могу сделать их активными. Также vgchange не смог их активировать.
>
> Есть ли другой способ получить доступ к lv'ам зашифрованного диска LUKS?
>
> Существуют ли специальные инструменты для восстановления LUKS/LVM2 (кто-то упомянул «скальпель», но я еще не пробовал)?
> Буду признателен за любые подсказки в правильном направлении извлечения данных с моего зашифрованного диска luks qubes.

необходим

Этот меня тоже только что укусил. В последний раз, когда я проверял месяц назад или около того, я
думал, что у меня все еще есть около 250 ГБ свободного места в моем основном пуле lvm.
Возможно, я смотрел не на ту строку. Я помню уведомление Qubes
неожиданно появилось около недели назад, но оно исчезло прежде, чем я
смог его прочитать. Не заметил, изменился ли значок
в трее
после этого, но, возможно, он должен начать мигать или иметь большой красный крестик
над ним каждый раз, когда пул, содержащий root, остается почти полным. Я надеюсь,
этот режим сбоя LVM улучшен в версии 4.1. Восстановление болезненно.

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

Райан Тейт

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

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

Некоторые простые инструкции о том, как сделать все необходимое, чтобы этого не произошло, например, изменить размер dom0 или других Qubes в целях безопасности? очистить временные файлы из определенного каталога, используемого процессом резервного копирования? ковыряться в каких-то настройках? -- было бы невероятно успокаивающим. У меня есть диск на 1 ТБ, поэтому кажется ненужным, что моя машина умирает из-за некоторой перетасовки проблем с изменением размера виртуальной машины. Разве я не могу просто выделить кучу места для этого процесса lvm?

ядро 4.1.6-200 завершается с ошибкой "Достигнута целевая базовая система"

Здравствуйте,
Я установил самое последнее ядро на fc22, и оно перестает загружаться в том месте, где написано "Достигнута целевая базовая система".

Как мне устранить эту проблему, чтобы узнать больше о том, почему и как она умерла?

Загрузка одного из старых ядер работает нормально.

Существует ли "стабильное" ядро, которое можно использовать в наши дни, или все они одинаково хорошо протестированы?

"Оболочки" (подмирья)

Дата регистрации: май 2011 г. Местонахождение: Confoederatio Helvetica (Swissh) Возраст: 42 Сообщения: 4 528 Упоминаний: 0 сообщений. Помечено: 0 тем.

Зарегистрированный пользователь

Первоначальное сообщение от моря

Предполагается, что это обеспечит больше отладочной информации при следующей загрузке?

"Оболочки" (подмирья)

Этот (изолированный) должен загружаться в графическом интерфейсе, а не в консоли.
Написал это, потому что предположил, что вы случайно загружаете только консоль, а не нужный графический интерфейс.

Дополнительную информацию об отладке вы можете найти:

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

Зарегистрированный пользователь

Проверьте от CTRL+ALT+F1 до F12, чтобы узнать, доступен ли виртуальный терминал. Затем вы можете использовать «journalctl» и «systemctl» для проверки системы.

покажет, где в процессе загрузки находится целевая «Базовая система».

Вы должны иметь возможность получить оболочку, либо добавив «1» к строке cmd ядра в меню загрузки Grub:

"Чтобы загрузиться непосредственно в цель восстановления, добавьте systemd.unit =rescue.target или просто 1 в командной строке ядра.Эта цель полезна, если проблема возникает где-то после запуска базовой системы, во время запуска «обычных» служб.В этом случае вы должны иметь возможность отключите плохую службу отсюда. Если цель восстановления также не загрузится, это может сделать более минимальная аварийная цель."

Я предполагаю, что rootfs и т. д. смонтировали RW, чтобы журнал работал. Если нет, используйте «аварийный режим».

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

Еще одна возможность — отлаживать проблемы с помощью initramfs (называемого Dracut в Fedora). Он содержит и systemd, и journald (а также journalctl и другие инструменты). Не думаю, что вам это нужно, но в любом случае:

Вставьте, например. в командной строке ядра в меню загрузки Grub:

Чтобы вставить точку останова загрузки, которая даст вам оболочку до монтирования rootfs.
С F22 должны работать следующие точки останова:

(см. страницу отладки systemd). Но имейте в виду, что это приведет к созданию большого количества сообщений в журнале.

Я без проблем использую ту же версию ядра на F22.

Зарегистрированный пользователь

Первоначальное сообщение от Peter H.S.

Проверьте от "CTRL+ALT+F1" до F12, чтобы узнать, доступен ли виртуальный терминал. Затем вы можете использовать «journalctl» и «systemctl» для проверки системы.

покажет, где в процессе загрузки находится целевая «Базовая система».

Я предполагаю, что rootfs и т. д. смонтировали RW, чтобы журнал работал. Если нет, используйте «аварийный режим».

Вставьте, например. в командной строке ядра в меню загрузки Grub:

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