Dracut centos 7 система не загружается
Обновлено: 04.07.2024
"Вскрытие" показало, что механизм загрузки не увидел диск, что выглядело, мягко говоря, странно.
Что оказалось в итоге: в некоторых случаях при перегенерации initrd (делается при установке и обновлении ядра или проприетарных драйверов, например) система не добавляет в initrd драйверы, необходимые для работы с диском. Соответственно, при следующей загрузке диск не виден - всё висит.
Почему механизм создания initrd так себя ведёт - пока не знаю.
После этого нужно перегенерировать initrd для того ядра, с которым хотите загружать систему. Если это то же ядро, которое сейчас загружено, достаточно вызвать "dracut -f". Если нужно для другого ядра, то сначала найдите в /boot нужный initrd-файл - файл initrd-<полная_версия_ядра>.img. Затем выполнитеЗатем выполните "sync" на всякий случай и можно перезагружать систему. В моём случае перезагрузка теперь прошла нормально.
Посмотрите, если на ваших машинах похожие проблемы возникнут, такое решение может помочь.
Из минусов - такие inird, не оптимизированные под данную машину, требуют больше места (55-60Мб вместо 12-15Мб) и создаются несколько дольше. Обычно это не проблема.
С подобным поведением легко столкнуться, если собрать ядро, где часть драйверов слинкованы статически, запустить на нём систему, после чего установить другое из репозитория. dracut посчитает, что драйвера не загружены, значит не нужны и для нового ядра. В каких ещё случаях может такое произойти, тоже не знаю.
Может имеет смысл дописать в add_drivers перечень жизненно важных драйверов в /usr/lib/dracut/dracut.conf.d/01-rosa.conf, как это сделано для ряда модулей. Или включить их в ядро.
Кстати, без драйверов hid_generic и usbhid ничего нельзя сделать в консоли dracut в случае ошибки (на планшете). И вот ещё кандидаты, что бы можно было логи на внешний носитель сохранить: usb-storage, sdhci_acpi и mmc_block.
trs писал(а): С подобным поведением легко столкнуться, если собрать ядро, где часть драйверов слинкованы статически, запустить на нём систему, после чего установить другое из репозитория. dracut посчитает, что драйвера не загружены, значит не нужны и для нового ядра. В каких ещё случаях может такое произойти, тоже не знаю. Я провёл эксперимент на одном и том же ядре. Создал initrd для него - посмотрел состав. Установил nvidia375, создал initrd для того же ядра - посмотрел состав и увидел, что в initrd не стало драйвера ata_generic + ещё нескольких. На другой машине, с другим ядром так "исчез" драйвер ahci и т.д.trs писал(а): Может имеет смысл дописать в add_drivers перечень жизненно важных драйверов в /usr/lib/dracut/dracut.conf.d/01-rosa.conf, как это сделано для ряда модулей.
Можно, но поддерживать это будет тяжело. Особенно, если в новых версиях ядра эти драйверы переименуют, раздробят/объединят и т.п. Проходили это только недавно с ext3, чуть раньше - с xhci_hcd и ещё чем-то. Без обновления dracut нельзя было обновить ядро в итоге, а если обновить - всё отваливалось у пользователей со старым ядром, сборка образов валилась и т.п.
В общем, после той катавасии я пришёл к тому, что такие вещи надо чинить в dracut непосредственно. И в upstream патчи слать. Тяжелее сейчас, но дешевле в перспективе.
Кстати, если заметили, в 01-rosa.conf сейчас нет явного добавления драйверов в initrd. Именно поэтому и нет.
add_drivers - это всё-таки для обхода конкретных багов на отдельных машинах, как временное решение до тех пор, пока не будет починен сам dracut. Как-то так.
Проще перейти на generic (не host-only) initrd. Они жирнее, но надёжнее.
А в перспективе, в качестве бредовой идеи, - вообще поставлять initrd в виде бинарников, а не перегенерировать по поводу и без на машинах пользователей. Пересоздавать initrd у пользователей теперь придётся гораздо реже, уйдёт целый класс багов от неудачных перегенераций и пр.
Всем привет!
Подключил ветку wheezy-backports и решил поставить новые ядра.
Установил linux-image-3.12-0.bpo.1-amd64 и linux-image-3.13-0.bpo.1-amd64+linux-image-3.12-0.bpo.1-rt-amd64.
Вместе с ядрами по зависимостям пакетов установился dracut и mdadm, удалив initramfs-tools.
С помощью dracut были созданы новые initram диски и обновлена конфигурация grub2 (grub-pc).
OC находится на зашифрованном диске с помощью cryptsetup luks+LVM+раздел /boot вынесен отдельно на флешку.
После перезагрузки предлагается ввести ключевую фразу /dev/sda1, но после ввода ничего не происходит.
Пришлось грузится с clonezilla-live и восстанавливать систему с помощью chroot (поставил снова initramfs-tools, удалив новые ядра и dracut).
Как правильно сгнерировать initramfs с помощью dracut?
C установленным mdadm:
Без mdadm структура примерно одинаковая.
Решил, но без использования dracut (использую по прежнему initramfs-tools):
Сначала ядра ставил из псевдо-гуй aptitude.
Позже руками aptitude install -t wheezy-backports linux-image-3.13-0.bpo.1-amd64
aptitude install -t wheezy-backports linux-image-3.12-0.bpo.1-amd64
aptitude install -t wheezy-backports linux-image-3.12-0.bpo.1-rt-amd64
+ linux-headers для соответствующих ядер.
Перезагрузился и все ок.
Единственное но! не собираются модули для virtualbox.
В бэкпортах нет virtualbox и virtulbox-dkms.
Придется ставить из testing или sid.
Да и не из бекпортов должны собраться. Вы linux-headers соответствующей ядру версии не забыли поставить?
| в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Да и не из бекпортов должны собраться. Вы linux-headers соответствующей ядру версии не забыли поставить?
Да все поставил.
А если вручную попробовать собрать dkms build virtualbox (от root)?| в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Никак не собираются модули virtualbox для новых ядер.
Вот логи (если делать dpkg-reconfigure virtualbox-dkms):
------------------------------
Deleting module version: 4.1.18
completely from the DKMS tree.
------------------------------
Done.
Loading new virtualbox-4.1.18 DKMS files.
Building for 3.12-0.bpo.1-amd64 and 3.13-0.bpo.1-amd64
Building initial module for 3.12-0.bpo.1-amd64
Error! Bad return status for module build on kernel: 3.12-0.bpo.1-amd64 (x86_64)
Consult /var/lib/dkms/virtualbox/4.1.18/build/make.log for more information.
[ ok ] Stopping VirtualBox kernel modules.
[FAIL] Starting VirtualBox kernel modules[. ] No suitable module for running kernel found . failed!
failed!
invoke-rc.d: initscript virtualbox, action "restart" failed.
root@myhdebian0:
bpo70+1_amd64.deb) ■
Выбор ранее не выбранного пакета linux-kbuild-3.13.
Распаковывается пакет linux-kbuild-3.13 (из файла ■/linux-kbuild-3.13_3.13.4-1
bpo70+1_amd64.deb) ■
Выбор ранее не выбранного пакета linux-headers-3.13-0.bpo.1-amd64.
Распаковывается пакет linux-headers-3.13-0.bpo.1-amd64 (из файла ■/linux-headers-3.13-0.bpo.1-amd64_3.13.10-1
bpo70+1_amd64.deb) ■
Настраивается пакет linux-headers-3.13-0.bpo.1-common (3.13.10-1
bpo70+1) ■
Настраивается пакет linux-kbuild-3.13 (3.13.4-1
bpo70+1) ■
Настраивается пакет linux-headers-3.13-0.bpo.1-amd64 (3.13.10-1
bpo70+1) ■
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 3.13-0.bpo.1-amd64
Error! Bad return status for module build on kernel: 3.13-0.bpo.1-amd64 (x86_64)
Consult /var/lib/dkms/virtualbox-guest/4.1.18/build/make.log for more information.
Error! Bad return status for module build on kernel: 3.13-0.bpo.1-amd64 (x86_64)
Consult /var/lib/dkms/virtualbox/4.1.18/build/make.log for more information.
Error! Bad return status for module build on kernel: 3.13-0.bpo.1-amd64 (x86_64)
Consult /var/lib/dkms/nvidia/304.88/build/make.log for more information.
/var/lib/dkms/virtualbox/4.1.18/build/make.log:
DKMS make.log for virtualbox-4.1.18 for kernel 3.13-0.bpo.1-amd64 (x86_64)
Сбт Апр 26 02:58:35 MSK 2014
make: Entering directory `/usr/src/linux-headers-3.13-0.bpo.1-amd64'
LD /var/lib/dkms/virtualbox/4.1.18/build/built-in.o
LD /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/built-in.o
CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.o
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.c: В функции «vboxdrvLinuxUid»:
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.c:226:5: ошибка: incompatible types when returning type «kuid_t» but «RTUID» was expected
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.c: В функции «vboxdrvLinuxGid»:
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.c:235:5: ошибка: incompatible types when returning type «kgid_t» but «RTGID» was expected
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.c: В функции «vboxdrvLinuxEuid»:
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.c:244:5: ошибка: incompatible types when returning type «kuid_t» but «RTUID» was expected
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.c:248:1: предупреждение: control reaches end of non-void function [-Wreturn-type]
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.c: В функции «vboxdrvLinuxUid»:
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.c:230:1: предупреждение: control reaches end of non-void function [-Wreturn-type]
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.c: В функции «vboxdrvLinuxGid»:
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.c:239:1: предупреждение: control reaches end of non-void function [-Wreturn-type]
make[4]: *** [/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.o] Ошибка 1
make[3]: *** [/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv] Ошибка 2
make[2]: *** [_module_/var/lib/dkms/virtualbox/4.1.18/build] Ошибка 2
make[1]: *** [sub-make] Ошибка 2
make: *** [all] Ошибка 2
make: Leaving directory `/usr/src/linux-headers-3.13-0.bpo.1-amd64'
Если делать dkms build virtualbox (как для текущего ядра, так и для новых):
root@myhdebian0:
USB старт / установка CentOS 7 Dracut-initqueue решения проблемы тайм-аута
Причина Dracut Тайм-аут, с моей проблемой, потому что при перемещении по USB от SATA порта, загрузки ОС файл initranfs не хватает USB-драйвера устройства, в результате чего доступ к USB HDD при запуске системы, так что доступ не Врет . это процесс Dracut Тайм - аут.
После того, как горение успешно, он вставляется на U диск компьютера, чтобы начать При нормальных обстоятельствах, вы должны увидеть следующий интерфейс.:
Выберите первый пункт, а затем нажмите кнопку Tab, то вы увидите следующее:
Текст будет изменен на:> vmlinuz Initrd = initrd.img linux dd Тихий изменяются, то вы будете слушать в свой список устройств, в этом списке, я не понимаю, Linux, я могу четко определить, что мой U диск. Мой USB флэш-накопитель SDC4.
Нажмите R, чтобы почистить диск U, установите его на загрузочном диске
Затем снова запустить компьютер с помощью диска U, выберите первый пункт , чтобы нажать на кнопку Tab, а затем изменить текст под днищем:> vmlinuz Initrd = initd.img inst.stage2 = HD: / DEV / SDC4 тихо Enter нормально УСТАНОВЛЕНО
Когда капуста делает загрузочный диск, он будет изменять плату. Если компьютер не может найти положение пусковой установки при запуске
Когда UltraISO делает загрузочный диск, обжима следующим образом:
(2) Зеркало Краткое описание продукции: UltraISO делает CentOS6 и 7 загрузочных дисков, запуск диска прокрутки, могут быть идентифицированы. Китайская капуста делает зеркало, объем изменяется на «китайской капусты U диск», который не может быть идентифицирован. Centos6 версия, руководство не зависит от объема. CentOS7 версия, изменение изменение линии, Dracut-initqueue [831] ошибка возникает, когда запуск
Интеллектуальная рекомендация
[Makefile от более мелких к более глубоким полная запись обучения 4] Переменные и различные методы присвоения
Давайте сегодня узнаем о различных методах присваивания переменных в Makefile! Смысл тяжелой работы, чтобы бедность больше не ограничивать свое воображение! Добавьте QQ, чтобы вместе учиться и обменив.
[Luogu P3147] [BZOJ 4576] [USACO16OPEN]262144
Портал Луогу БЗОЙ Портал Описание заголовка Bessie likes downloading games to play on her cell phone, even though she doesfind the small touch screen rather cumbersome to use with her large hooves. Sh.
Я, к сожалению, отформатировал диск / dev / sda2. Так что все /root , /home , swap LVM больше не существует. Из-за этого мой сервер не может нормально работать.
это показывает только
- я не понимаю. вы говорите, что отформатировали диск, который уже использовался? и перезаписали таблицу разделов, уничтожив существующие данные?
- Я пытаюсь отформатировать этот диск / dev / sda2 с помощью fdisk
- добро пожаловать в U&L! Есть ли у вас резервная копия?
- нет .. Я новичок в платформе Linux. не могли бы вы объяснить мне несколько ясно
- У меня такая же проблема при использовании centos в виртуальном ящике. и я исправил это, изменив окна Hyper-V особенности. потом началось нормально
В аварийной оболочке дракута:
Dracut предлагает оболочку для интерактивной отладки в случае, если dracut не может найти вашу корневую файловую систему. Чтобы включить оболочку:
rhgb = redhat графическая загрузка - это экран загрузки в режиме графического интерфейса пользователя, на котором большая часть информации скрыта, а пользователь видит вращающийся значок активности и краткую информацию о том, что делает компьютер.
rd.shell = Это представит оболочку, если dracut не сможет найти ваше корневое устройство
- Удалите аргументы загрузки "rhgb" и "quiet". Ниже приведен пример файла конфигурации загрузчика /etc/grub.conf.
по умолчанию = 0
серийный --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.
Шаг 1: введите journalctl
Шаг 2. Найдите ошибку
Шаг 3: запустить
Шаг 4: запустить
- Он будет работать под аварийной оболочкой dracut?
- Может быть? Вам лучше загружаться с LiveCD с инструментами LVM.
- 1 Я просто использовал эти две команды ниже: lvm vgscan и lvm vgchange -ay
- 1 теперь он работает нормально. Спасибо за помощь :)
Виртуальные машины EL7, импортированные из виртуального устройства VirtualBox, могут не запускаться на Oracle VM или Xen с той же ошибкой.
Виртуальные машины под управлением EL7, экспортированные из Oracle VirtualBox в качестве виртуального устройства, а затем импортированные в Oracle VM, могут не загружаться правильно и могут выйти в аварийную оболочку. Это вызвано отсутствием драйвера xen-blkfront в образе initramfs. Обычно вывод во время загрузки для уязвимых систем выглядит следующим образом:
Обходной путь. Есть два пути решения этой проблемы. Первый включает добавление недостающих драйверов перед экспортом виртуальной машины Oracle Linux 7 из Oracle VirtualBox. Для этого перед выполнением экспорта выполните следующую команду от имени пользователя root:
Если вы не можете выполнить этот шаг перед экспортом, вы можете временно загрузить виртуальную машину как HVM и добавить следующую опцию загрузки в GRUB перед загрузкой:
После загрузки виртуальной машины вы можете добавить недостающие драйверы, выполнив следующую команду от имени пользователя root:
Перезагрузите виртуальную машину после того, как драйверы будут добавлены в initramfs.
Читайте также: