Error disk mduuid not found grub rescue что делать
Booting from Hard Disk error, Entering rescue mode
Пример решения проблемы, от которой холодок пробегает по коже, когда ее видишь на рабочем сервере в продакшене. После плановой перезагрузки виртуальная машина не загрузилась, показав ошибку и перейдя в grub rescue. Я уже не первый раз сталкиваюсь с подобным и примерный план восстановления в голове присутствует. Делюсь информацией с вами.
Введение
Есть сильно нагруженная виртуальная машина, для которой нужно было добавить ядер и оперативной памяти. Аптайм у нее был примерно пол года. Ничего не предвещало беды. Я предупредил, что простой будет секунд 30 и ребутнул машину. Как только увидел консоль виртуалки, понял, что дальше начинается веселье с непредсказуемым результатом. Адреналина добавила информация от разработчиков, что бэкапов у них нет 🙂
Для тех, кто еще не знаком с подобным, поясню. Начальный загрузчик не смог найти /boot раздел для продолжения загрузки. Вместо этого он сообщил, что раздел с указанным lvmid, где располагается boot, он не видит и дальше загрузиться не может. Машина находится в режиме grub rescue. Причин появления этого режима может быть много. Мне всегда приходится с чем-то новым сталкиваться, но методика решения проблемы примерно одна, и я дальше о ней расскажу. А потом поясню, что было с этой конкретной виртуалкой.
grub rescue
В grub rescue mode доступно всего четыре команды:
Для начала воспользуемся командой ls и посмотрим, какие разделы видит grub.
В моем случае несколько отдельных разделов диска и lvm том. К слову сказать, в моем случае раздел /boot расположен на lvm разделе, но по какой-то причине загрузчик не смог с него загрузиться. У вас может вообще не быть lvm, а проблема в чем-то другом. Например, если у вас в grub.cfg указан UUID раздела, с которого надо грузиться (это может быть массив mdadm), а раздел этот по какой-то причине исчез, или изменил свой uuid, вы как раз получите эту ошибку.
Сейчас нам нужно найти раздел, на котором расположен загрузчик. Первая часть загрузчика, которая записана в MBR диска очень примитивная и почти ничего не умеет. Она даже разделы диска толком не определила, решив почему-то, что там файловая система msdos, хотя это не она. Нам нужно проверить все разделы диска hd0 и найти реальный загрузчик. Проверяем это командами:
Я нашел на msdos1 искомый раздел /boot. Понял это по содержимому. В разделе есть директория /grub, где располагается вторая часть загрузчика. Искомая директория может называться /grub2 или /boot/grub. Указываем загрузчику использовать этот раздел при выполнении дальнейших команд.
Далее загружаем необходимые модули. Какие будут нужны, зависит от конкретной ситуации. На всякий случай показываю самые популярные:
Начать стоит вообще без модулей, а потом добавлять, в зависимости от вашей ситуации. В завершении загружаем модуль normal и вводим одноименную команду:
После этого вы должны увидеть стандартное меню загрузчика grub. Дальше вы загрузитесь в операционную систему.
Обновление загрузчика
Дальнейшее решение проблемы с загрузкой будет зависеть от того, что у вас сломалось. Возможно будет достаточно просто переустановить загрузчик:
Эта команда переустановит в MBR код загрузчика, который будет подхватывать тот раздел /boot, с которого вы в данный момент загрузились. Если это не поможет, то внесите необходимые изменения в в конфиг grub и пересоздайте его командой:
А после этого установите на диск:
Конфиг груба находится в разных дистрибутивах в разных местах. Какие туда вносить изменения, заранее тоже не могу сказать, будет зависеть от проблем. Скорее всего все это придется вам гуглить, если не получится сходу починиться по моим рекомендациям.
Почему система не загрузилась
Теперь рассказываю, что было в моем случае. Корень системы / располагался на lvm разделе вместе с /boot разделом. В какой-то момент корневой раздел был увеличен в размере за счет расширения тома lvm еще одним диском. Все это было сделано на лету, без перезагрузки системы. Причем сделано было мной давно, и с тех пор сервер ни разу не перезагружался до настоящего времени. Я не знаю почему, но данная операция привела к тому, что grub перестал загружаться с этого lvm раздела.
UUID физического тома и логического раздела не поменялись. То есть там информация, в начале загрузки, с ошибкой загрузки диска с lvmid, верная. Уиды правильные. Я понял, что причина в изменении размера диска только по аналогичным сообщениям в интернете. Наткнулся на несколько человек, которые обращались с похожей проблемой, где перед этим они тоже изменяли корневой раздел. Похоже это какой-то системный баг, возможно даже конкретной системы.
В моем случае на диске почему-то оказался отдельный раздел на 500 мб с файловой системой ext2. На нем как раз и был загрузчик, с которого я загрузился в rescue boot. Откуда взялся этот раздел, я не знаю. По идее, если он был создан автоматически во время установки системы, на нем бы и должен быть актуальный раздел /boot. Но нет, его не было в fstab и он не использовался. Я не стал долго разбираться, почему так получилось, а просто подмонтировал этот раздел в систему, обновил на нем grub и записал обновленный grub в MBR. После этого система благополучно загрузилась с этого раздела.
Если кто-то знает, почему мой загрузчик не смог загрузиться с lvm раздела, при том, что uuid указан правильно, прошу подсказки. Самому очень интересно, так как ситуация получилась неприятная и совершенно мне не понятная. Я часто расширяю корневой lvm раздел на ходу, но первый раз сталкиваюсь с тем, что это приводит к поломке загрузчика. Grub уже давно умеет грузиться с lvm раздела и каких-то дополнительных действий для этого делать не надо.
Что еще предпринять, чтобы починить загрузку
Если ничего из описанного не помогает, то дальше могут быть такие варианты:
Если ничего не помогло и вы не понимаете, что нужно сделать, то посмотрите вот это руководство по grub. Здесь очень хорошо и подробно все описано.
Еще совет. Если у вас живы сами данные, то зачастую бывает проще настроить новую виртуалку, подключить к ней диск от старой и перенести все данные. Так вы точно сможете спрогнозировать время восстановления системы. Обычно за час на все про все можно уложиться. Когда вы начинаете чинить упавшую систему, никогда точно не знаете, сколько времени уйдет на восстановление. В моем случае я загрузку за 30 минут и запустил машину. Потом еще 2 часа разбирался на копии виртуальной машины, что случилось и пытался найти решение проблемы без переустановки виртулаки. Получил некоторый опыт, но если бы я сразу все перенес на новую виртуальную машину, то потратил бы меньше времени.
grub rescue – что делать?
Содержание
В случае возникновения проблем с загрузчиком появляется надпись grub rescue. Чаще всего проблема появляется, когда на компьютере установлено сразу две операционные системы: Linux и Windows. Обычно установка производится в такой последовательности.
Сначала на жёсткий диск устанавливается Windows после чего на отдельный раздел производится установка Linux. При такой схеме в загрузочную область диска добавится загрузчик grub2 что позволяет выбирать в какую из систем производить запуск.
grub rescue – что делать?
Итак, мы находимся консоли загрузчика. Она имеет небольшой командный интерпретатор наподобие bash. Список всех доступных команд можно получить, набрав:
Введите команду для просмотра существующих разделов:
В данном примере всего один раздел msdos1 на жёстком диске hd0.
Убедимся, что это нужный раздел. Для этого выводим список файлов загрузчика:
Находим файл grub.cfg значит всё в порядке, продолжаем. Если каталог не обнаружен, то перебираем остальные разделы дисков пока не найдём.
Следующая команда создаёт префикс для каталога загрузчика:
Установим раздел в качестве корневого:
Затем необходимо подключить ещё пару модулей и стартовать загрузку системы:
После успешной загрузки в Linux не забудьте переустановить загрузчик командой:
(вместо «_» введите букву загрузочного жёсткого диска).
Далее выполните команду обновления конфигурации файла grub.cfg:
Обычно grub2 автоматически определяет установленные системы, в том числе Windows, и добавляет их в список загрузки.
Восстановление ubuntu с флешки
Если все проделанные выше действия не помогли, то придётся раздобыть загрузочную флешку.
Лучше подготовить USB или CD носитель с Ubuntu той же версии и разрядности что и восстанавливаемая система. Я покажу на примере системы Ubuntu 18.04 LTS x64. Загрузитесь в Live режиме и откройте терминал комбинацией Ctrl+Alt+T.
Для удобства сразу активируйте права суперпользователя root. Знак минус в конце команды означает перемещение в домашний каталог:
Теперь нужно посмотреть список дисков и разделов программой fdisk:
Обнаруживаем раздел с установленной системой Linux. В этом примере раздел /dev/sda1 единственный, он же корневой и загрузочный.
Выбирайте раздел аккуратно, буква диска может отличаться от моих примеров. Не потеряйте свои данные!
Смонтируем его в каталог /mnt/ :
Убедитесь, что каталог /boot/ находится на этом же разделе диска выполнив команду:
В случае отсутствия каталога, монтируйте его отдельно. Для этого нужно найти раздел в результате вывода утилиты fdisk (на скриншоте выше) и смонтировать командой:
Сейчас необходимо произвести логин в ту систему, которую будем чинить. Но перед этим смонтируем из Live системы несколько служебных разделов:
Двойной амперсанд && между командами означает проверку выполнения предыдущей команды. Выполнение последующей команды происходит только при условии, что предыдущая завершена успешно.
Всё, мы в системе. Можно устанавливать загрузчик и обновлять его конфигурацию. Будьте внимательны, используется именно корневой раздел диска /dev/sda без цифры:
На всякий случай размонтируем корректно разделы и перезагружаемся:
Процедура восстановления загрузчика grub2 на этом завершена.
Видео
Пробовал установить груб повторно на дисках, для этого делал
Затирал диск перед установкой в массив с удалением суперблока, и нулями забивал, массив синкается успешно, но не могу загрузиться с одного диска.
Что еще можно глянуть? Спасибо.
тут все ок. бывает иногда, что на одном из дисков mrb, а на другом gpt..
в /etc/mdadm.conf правильно прописано всё? не забыл пересобрать initramfs на всякий случай?
Загуглю, вроде зацепка. Отпишу позднее, спасибо.
в /etc/mdadm.conf правильно прописано всё?
Смущает что в mdadm.conf:
По советам из гугла грузанулся в liveCD, примонтировал / к /dev/md127, запустил переконфигурацию конфига груба, после его установил на каждый из дисков в массиве.
При загрузке с одного диска проблема сохранена. Опять что-то или упустил, или подводный камень какой-то неочевидный..
Ну судя по выхлопу, всё ок. А в диалоге выбора диск выбран второй?
По команде ls вижу
ругаются на Unknown command
Хотя insmod что-то готов принять, но потом ругается: error: disk ‘mduuid/63babd6180a15939e186260e5eebae53’ not found
Как проверить, тот или не тот initrd не разобрался, но старое ядро удалил, повторил процедуры, результат прежний.
А сколько у тебя всего дисков?
Всего 2 диска, оба в raid-1.
ПОсле установки сразу проверил работоспособность загрузки системы с каждого диска, убедился, все ок.
Можно попробовать ещё запустить принудительно ресинк массива.
Но ведь уже собирал пару раз массив.
Тоже подумал об этом, запустил пока форматирование винта, потом попробую создать таблицу разделов вручную, а не копируя с рабочего винта, ну и потом поставлю на синхронизацию.
Отпишусь наверное в понедельник
Потом загрузился с двумя дисками в rescue, собрал массив (он начал называться md0, как в системе и был, а не md127 в предыдущих итерациях по восстановлению) с одним «исправным» диском, добавил первый «проблемный» диск, массив синхронизировался, потом запустил dpkg-reconfigure grub-pc
Ошибок не выдал, и в итоге я успешно загрузился с «проблемного» диска!
Raid Grub mduuid not found #312
Comments
BoarderEB commented Nov 24, 2019 •
The sytem starts in the grub rescue mode. With the error: disk`mduuid/TheUuidOfTheDisk,1´ not found.
With this in the rescue mode the system boots*¹:
And grub has to be rewritten:
The text was updated successfully, but these errors were encountered:
stormi commented Nov 25, 2019
Can you give us more information about what was done before the system failed to boot?
BoarderEB commented Nov 25, 2019 •
Nothing special. Normal installation, packages via net-install.
/dev/sda + /dev/sdb via installer as md-raid 1
Grub rescue mode on the first startup.
stormi commented Nov 25, 2019
Are you booting in UEFI mode or MBR mode?
There may be interesting logs in /var/log/installer/install-log
BoarderEB commented Nov 26, 2019 •
MBR, and I do not see anything really interesting in the log. The raid is successfully created.
That is the work around to install grub on a md raid, but it don’t works on my system, without a Devicemap.
I don’t find a CentOS Devicemap-Creater script. And I think that’s the problem.
‘chroot’, ‘/tmp/root’, ‘/usr/sbin/grub-install’, ‘—target=i386-pc’, ‘/dev/sda’] —grub-mkdevicemap=thescript.sh
Maybe you can do a look on this.
stormi commented Nov 26, 2019
Of course, it was not installed with a devicemap, but usually this just works. Why is it necessary to use a device map in your situation according to you?
BoarderEB commented Nov 26, 2019 •
Yes, if i do by hand the grub-install on sda + sdb, i get also a «Installation finished. No error reported.» But the startup end in the grub rescue mode.
I have no idea why this is necessary at my system. But I suspect that this is not just for me necessary. I found the same problem on different websites with a md-raid as boot device in different Linux versions. And I think the easyst way to exclude this for XCP-NG is always to create a devicemap. For me it is enough by hand.
I report only the bug and show the way of the solution.. It’s your choice.
stormi commented Nov 26, 2019
We’ll leave this bug report open to gather more feedback about this. This is the first time that I see it become necessary, while many have used our installer to install on a software RAID, so I’m interested in feedback from others too.
Thanks for your report, it may prove useful in due time.
hydromike commented Dec 6, 2019
I am having this same problem with a raid fresh install of 8.0, on first boot I am stuck with just “GRUB” at the top left corner of my screen, till tonight I thought that it was just me. I do not have the experience to troubleshoot. Where can I find the failed boot logs, mount the raid. On my old non raid boot drive?
stormi commented Dec 6, 2019
Hmm, the symptoms are different from those of the original reporter, because their grub enters rescue mode (which means grub could start but not boot the system) when yours can’t even start. To my knowledge, there won’t be any boot logs with a failure so early in the boot stage. I suggest to create a thread on the forum first so that experienced users can help you debug the issue.
karstenmtr commented Dec 28, 2020 •
I encountered the same problem like in the first post. After a clean install from a USB stick (made with rufus and the provided 8.2 iso) the installation finished without error, but the reboot ended in grub rescue mode.
The mentioned steps in the first post got the system to work.
There was nothing fancy about the setup I would think. I used an ASUS Z9DA-P8 mainboard with latest BIOS. I entered the BIOS and changed the SATA Mode to RAID instead of AHCI. After the reboot I started the RAID configuration utility and created a RAID1 with two disks.
Right after this I used the usb stick as boot device and installed XCP-ng without a problem. I didn’t create a local storage repository as this is not needed and there was a previous installation of xenserver 6.5 on the disks, but those were not used for a RAID in the old setup. Don’t know if this is relevant.
After the installation the boot ended with the grub rescue mode as mentioned above.
The same procedure and result I got on a second system with identical setup and the same installation steps.
@BoarderEB : Thanks for sharing the workaround or solution.
error: disk mduuid not found
Столкнулся со следующей проблемой.
Имеет 2 массива RAID5 на mdadm c 3-мя накопителями. в первом расположен «/grub» во втором LVM с «/» и файлом подкачки.
Так же присутствует еще один диск для бэкапов вне массива.
При попытке загрузки системы выдается следующая ошибка:
Я так полагаю, изменилось имя у массива, по этом груб не может его собрать.
Причем могу просмотреть содержимое, когда он не ругается на файловую систему лишь на (hd0,msdos1) (hd2,msdos1) и (hd3,msdos1). Но показывает как пустой раздел.
Можно как нибудь решить данную проблему? Есть предположение, что нужно переписать содержимое grub.cfg с новым наименованием массива, но верно ли оно? И как его можно зафиксировать с livecd на дисках?
Если grub.cfg где-то внутри RAID, то помимо правки нужно ещё grub-install.
т.е. ядро и конфиг груба лежат на софтовом рейде? WTF? биос уже научился в линуксовый софт-рейд?
Добро пожаловать в GRUB2.
биос уже научился в линуксовый софт-рейд?
Ему не нужно ничего этого уметь.
Загрузить машину с livecd/liveusb с поддержкой lvm и raid, посмотреть uuid и partuuid и поправить конфиг.
можно в двух словах?
А кроме grub-install еще нужен какой нибудь параметр?
GRUB2 умеет любой софтрейд, в т.ч. страйп. Драйвер для RAID запихивается в какой-то stage (не в самый первый), туда же данные для сборки массива. Аналогично работает с LVM и dm-crypt.
Параметр чего? Команды? Да, нужно указать, на какой диск ставить (т.е. поочерёдно на все диски, нужные для загрузки). Проще всего через dpkg-reconfigure grub-pc (если у тебя Debian и не-EFI).
Grub грузится с MBR сектора диска. Это и позволяет помещать его внутрь рейда, но есть нюанс. В случае предупреждения выхода из строя RAID, я его распространяю на MBR всех дисков RAID. Это позволяет грузится системе, какой бы диск массива не был бы удален.
Именно так. Debian и должен быть не EFI
да, anonymous (20.02.2017 13:29:09), спасибо
Grub грузится с MBR сектора диска.
помню эту эпопею лет десять назад, когда в ограниченный объем кода пытались впихнуть драйвера разных файловых систем, чтобы потом найти на соответствующем разделе конфиг груба, ядро, initramfs, и уже грузить последнюю стадию
но теперь под файловой системой лежит еще один слой — soft-raid/LVM, и код с их поддержкой нужно разместить рядом с кодом, отвечающим за fs; неужели умудрились все это запихнуть в один MBR-сектор?
В GRUB2 данная функция реализована. Но положа руку на сердце, мне не удалось корректно ее реализовать. При вынимании 2-х из 3-х дисков RAID5 рушился.
Что бы исключить данную возможность я boot вывел за LVM раздел отдельным массивом.
Нет. На дисках с DOS-разметкой давно действует стандарт на отступ в 2048 секторов до первого раздела. Туда и ставится следующий стейдж загрузчика. На GPT такие хаки не приняты, там создаётся раздел с типом ef02 (обычно 2 Мб), куда и помещается жирная часть GRUB. Ну а на GPT с загрузкой через EFI таких проблем и вовсе нет, потому что загрузчик всегда является EFI-приложением, лежащим в ESP.
При вынимании 2-х из 3-х дисков RAID5 рушился.
На дисках с DOS-разметкой давно действует стандарт на отступ в 2048 секторов до первого раздела. Туда и ставится следующий стейдж загрузчика.
т.е. в MBR-секторе лежит код, который читает вот эти 2048 секторов (а это 2048*512=1M достаточно много для кучи разного кода)? наверно это как раз и называется 1.5 stage?
На GPT такие хаки не приняты, там создаётся раздел с типом ef02 (обычно 2 Мб), куда и помещается жирная часть GRUB.
ну, тут, я так понимаю, нужно заранее руками позаботиться об этом разделе на каждом диске, который потом в рейде участвовать будет? а при инсталляции груба нужно явно указать раздел для этой жирной части? а если не указать, то груб попытается найти подходящий по типу?
Ну а на GPT с загрузкой через EFI таких проблем и вовсе нет, потому что загрузчик всегда является EFI-приложением, лежащим в ESP.
про это знаю мало (погуглю при необходимости), но вроде бы под EFI тоже отдельный раздел создается, а значит там тоже места должно хватить под много кода
ну, вроде, пазл сложился в общих чертах, спасибо, народ!
наверно это как раз и называется 1.5 stage?
ну, тут, я так понимаю, нужно заранее руками позаботиться об этом разделе на каждом диске, который потом в рейде участвовать будет?
а при инсталляции груба нужно явно указать раздел для этой жирной части?
Вроде нет, но точно уже не помню.
но вроде бы под EFI тоже отдельный раздел создается, а значит там тоже места должно хватить под много кода