Диск по UUID не обнаружен (initramfs), сбой загрузки

У меня была та же проблема как начинающий потока, и я решил ее без переустановки.

Моя проблема произошла при манипулировании виртуальной установкой на основе скопированного образа диска. Это привело к измененному uuid, и копия не запустится. Это - грубый эскиз того, что я сделал.

Первая начальная загрузка с помощью спасательной системы (та же версия) и выполненный оболочка на диске неначальной загрузки. Взгляните на /etc/fstab и подтвердите uuids там путем издания blkid команда для каждого устройства. Зафиксируйте эти записи, поскольку они важны.

Затем мы фиксируем личинку с:

• grub-mkconfig
• update-grub

Затем выполненный:

• update-initramfs -u /boot/initrd.img-2.6.YOURVERSION-HERE

Это создаст новый initramdisk для Вашей версии. Если Вы не знаете точной версии, Вы работали, взглянули на файлы в/boot/. Выбор числа последней версии должен быть безопасным.

После выхода из спасательной оболочки человечность, живой CD предложит Вам последнее меню от того, где Вы ввели оболочку. Выберите "install Grub" (или подобный) там и введите устройство, куда поместить Ваш загрузочный сектор.

В большинстве систем (стандартная установка) /dev/sda безопасная ставка. Знайте: Windows - или другие системы мультиначальной загрузки, возможно, понадобились бы другие записи здесь!

Наконец необходимо смочь загрузиться от восстановленного диска.

Я только что перешел в режим восстановления. И выбрать что-то указываете обновление grub в меню. затем исправьте проблему.

Помимо всех остальных ответов, попробуйте перейти в меню grub (нажмите SHIFT во время загрузки, чтобы перейти в расширенные настройки Ubuntu) и выбрать старое рабочее ядро. Конфигурация grub должна быть обновлена ​​после установки более новой версии ядра.

Это также может произойти, если вы клонировали раздел или, особенно, весь жесткий диск и таблицу разделов с помощью dd. Если это произошло, обычно fsck всех рассматриваемых разделов решит это.

Источник: http://realtechtalk.com/UbuntuDebianLinux_wont_boot_and_drops_to_Busybox_shell_after_cloning_HDD_with_dd-1978-articles

У меня возникла та же проблема в Ubuntu после нескольких часов поисков. Я только что понял, что grub пытается загрузить sdb5, и мой kali находится на sda5, поэтому загрузитесь с live cd и попробуйте смонтировать ur linux os с помощью команды mkdir и, если она существует, попробуйте исправить grub, удерживая shift в нагрузке и нажав e и изменив root dev и, если он работает, сделает его постоянным

Перепробовал все ответы, но не смог решить, так что, наконец, пришлось переустановить Ubuntu :(.

Эта же ошибка появилась и в моем компе друзей, но ему тоже не повезло.

В моем случае:

ОС устанавливаются в ext4 с Ubuntu 14.04

, но я обнаружил, когда устанавливаю другое издание Ubuntu, например 10.04 после Ubuntu 10.04

Также скомпилируйте ядро ​​Ubuntu 10.04 и используйте dpkg для его установки.

ошибка появляется.

Наконец, проблема в grub.cfg.

Поскольку в Ubuntu 10.04 по умолчанию используется ext2 для ОС, поэтому initramfs будет загружать драйвер ext2, а не использовать драйвер ext4 ...

Поэтому замените ext2 на ext4 в grub.cfg, чтобы исправить это.

Я сам исправил это, отредактировав файл / etc / default / grub

GRUB_CMDLINE_LINUX=" rootdelay=3 "
GRUB_DISABLE_LINUX_UUID=true

Только с первым этого было недостаточно. Я даже попробовал 130, как указано ранее. Затем я отключил UUID второй командой. В любом случае это был корневой раздел LVM, поэтому данные UUID были бессмысленными.

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

UUID в /proc/cmdline правильный, однако система не может его распознать.

Я понятия не имею, что может вызвать это, но в качестве решения вы можете попробовать переустановить только Grub. Я думаю, что это решит вашу проблему.

Я видел ту же проблему - с дополнительной информацией, которую я использовал , использовал blkid (и tune2fs) для проверки UUID, и это точное совпадение. В листинге / dev / disk / by-uuid также показан ожидаемый UUID. Привод отлично монтируется и в busybox. Все нормальные файлы, ожидаемые в [/ mnt] / boot /, присутствуют (для ядра 3.13.0-36).

Я получил компьютер для загрузки (изнутри busybox), изменив ссылку UUID / etc / fstab для корневого раздела на / dev / sda1 (измените в соответствии с вашими настройками). Однако я не уверен, что этот шаг важен, поскольку сам по себе он не имеет значения. То, что сделал , было при следующей перезагрузке: он сидел в grub, нажимал «e», чтобы редактировать загрузку Ubuntu по умолчанию, удаляя всю конструкцию «if ... fi» и заменяя строку «linux» UUID = с / dev / sda1. Такой подход позволил компьютеру полностью загрузиться.

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

У вас есть старое ядро? Это работает? Проверьте / etc / fstab, как loevborg сказал о возможных «устаревших» записях (у меня была такая же проблема при установке lvm и grub2 - была старая запись для раздела / boot, которая вызвала ошибку)

Когда я увидел это в моей системе, это был вопрос неправильного UUID, установленного в качестве корневого параметра загрузки в /boot/grub/menu.lst.

cat /proc/cmdline фактически показывает параметры загрузки, переданные в initramfs - если вы видите, что initramfs сказано смонтировать несуществующий корневой раздел, он, очевидно, потерпит неудачу.

update-grub не обновил эти параметры для меня, а просто сделал ручную замену старого UUID в menu.lst, исправил это для меня.

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

• Загрузите компьютер с живого носителя;
• fdisk -l /dev/sda, чтобы найти нужный раздел; или используйте cfdisk; or use gparted (replace sda` на вашем жестком диске).
• blkid /dev/sda1 (замените sda1 на найденный вами раздел); альтернативно используйте vol_id;
• посмотрите, можете ли вы смонтировать раздел (используя файл устройства /dev/sda1);
• проверьте, совпадает ли отображаемый UUID с UUID в корневом разделе /etc/fstab;
• сгенерируйте новый UUID с помощью uuidgen и примените его к разделу с помощью tune2fs -U;
• измените запись fstab соответственно.

Может показаться маловероятным, что что-то столь же важное, как UUID, изменяется без видимой причины, но это происходит, вероятно, из-за ошибки. Посмотрите, поможет ли изменение UUID на новое значение.

Проблема заключается в том, что ваш жесткий диск или контроллер не реагируют достаточно быстро.

Попробуйте сделать следующее:

• Когда появится меню загрузки, выделив верхнюю часть списка, нажмите e (для изменить [ 111]).

• Вы должны увидеть длинный список параметров. Добавьте это к этому: rootdelay=130

• Нажмите Enter , а затем b ( boot ). Попробуйте проверить, загружается ли ваша система сейчас. Вы можете увеличить значение, если это не помогает в первый раз (но не намного, 130 уже более чем достаточно для любого оборудования, которое не сломано).