2012-03-31 Ежедневная сборка Debian Wheezy в VirtualBox 4.1.2, 6 дисковых устройств.
Мои шаги для воспроизведения до сих пор:
Оба / и / boot будут в этом стеке. Я выбрал EXT4 в качестве файловой системы для этой установки.
Я могу добраться до консоли спасения GRUB2, которая может видеть на ней mdraid, группу томов и логические тома LVM (все названы соответствующим образом на всех уровнях), но я не могу сохранить содержимое файловой системы любого из них и не могу загрузиться от них.
Насколько я могу судить из документации, поставляемая версия GRUB2 должна корректно обрабатывать все это.
http://packages.debian.org/wheezy/grub-pc (1.99-17 на момент написания.)
Он загружает модули ext2, raid, raid6rec, dosmbr (он входит в список модулей один раз на диск) и lvm-модули в соответствии с сгенерированным файлом grub.cfg. Также он определяет список модулей, которые должны быть загружены дважды в сгенерированном файле grub.cfg, и, согласно быстрому поиску в Google, это кажется нормой и подходит для GRUB2.
Как продвинуться дальше, заставив GRUB2 действительно читать содержимое файловых систем и загружать систему?
В чем я ошибаюсь в своих предположениях о функциональности здесь?
ИЗМЕНИТЬ (2012-04-01) Мой сгенерированный grub.cfg:
Кажется, сначала он делает мой логический том / usr корнем, и это может быть источником сбоя? Ошибка grub-mkconfig? Или он должен получить доступ к материалам из / usr до / и / boot? / boot is on / для меня - отдельного загрузочного логического тома нет.
В конце концов, это был Ошибка / проблема Grub2 с поврежденным программным рейдовым массивом.
Grub2 1.9x имеет проблемы с загрузкой из деградированного массива. Загрузка системы в режиме восстановления и разрешение на восстановление рейда устранили проблему исходной конфигурации.
Между прочим, установка работает (на данный момент: 2012-06-26) прямо из коробки на Fedora 17, Arch (стабильный) и Gentoo (стабильный + последний grub2 bzr через Portage): Grub2 2.0+ устранил проблему. Поскольку скоро произойдет зависание Wheezy, я очень надеюсь, что проблема будет решена либо путем перехода на версию 2.0, либо путем обратного переноса исправления.
Для меня это все еще влияет на Debian 6, 7; Ubuntu 8.04, 10.04, 12.04.
Разрешение синхронизации рейда в однопользовательском режиме восстановления является приемлемым обходным путем для домашней системы, но наличие потенциальной дополнительной заминки для перезагрузки рабочего сервера (даже небольшого офисного файлового сервера) заставляет дважды подумать.
Очень хороший пост, большое спасибо, это мне очень помогло при установке LVM-over-RAID на Debian Wheezy. Вот шаги, которые я предпринял, чтобы решить эту проблему.
Обновите Grub2 до V2 +
Добавьте эти строки в /etc/apt/sources.list
deb http://http.debian.net/debian unstable main
deb-src http://http.debian.net/debian unstable main
apt-get update
apt-get install grub2
Возможно, вы сделали отдельный раздел слишком большим и не оставили достаточно места для установки GRUB2, и он перезаписал части пространства LVM. Что-то вроде длинного выстрела. Попробуйте свои действия, чтобы воссоздать вашу проблему, за исключением того, что на этот раз используйте один диск (пропустите RAID), создайте один раздел точно так же, как вы делали раньше, а затем оставшуюся часть. Если я прав, вы должны вести себя так же.
ОБНОВЛЕНИЕ: Итак, это неверный ответ. Я просматривал руководство GRUB2 и нашел это раздел в котором говорится:
Если вместо этого вы получаете только спасательную оболочку, это обычно означает, что GRUB по какой-то причине не смог загрузить «нормальный» модуль. Возможно, это удастся временно обойти: например, если причина сбоя в том, что «префикс» неправильный (возможно, это относится к неправильному устройству, или, возможно, путь к / boot / grub был неверно указан относительно устройство), то вы можете исправить это и вручную войти в нормальный режим:
# Inspect the current prefix (and other preset variables): set # Find out which devices are available: ls # Set to the correct value, which might be something like this: set prefix=(hd0,1)/grub set root=(hd0,1) insmod normal normalОднако любая проблема, которая оставляет вас в спасательной оболочке, вероятно, означает, что GRUB был установлен неправильно. Может быть более полезно попытаться переустановить его должным образом с помощью устройства grub-install (см. Вызов grub-install). При этом следует помнить о нескольких вещах:
- Порядок дисков в вашей операционной системе может отличаться от порядка загрузочных дисков в вашей прошивке. Не думайте, что ваш первый жесткий диск (например, «/ dev / sda») - это тот, с которого будет загружаться ваша прошивка. device.map (см. Карта устройств) можно использовать для переопределения этого, но обычно лучше использовать UUID или метки файловой системы и избегать полной зависимости от порядка дисков.
- По крайней мере, в системах BIOS, если вы укажете grub-install установить GRUB в раздел, но GRUB уже установлен в основной загрузочной записи, то установка GRUB в разделе будет проигнорирована.
- Если возможно, обычно лучше избегать установки GRUB в раздел (если только это не специальный раздел для использования только GRUB, например загрузочный раздел BIOS, используемый в GPT). Это означает, что GRUB может перестать читать свой основной образ из-за перемещения блоков файловой системой, например, при дефрагментации, выполнении проверок или даже во время нормальной работы. Установка на весь диск обычно более надежна.
- Убедитесь, что GRUB действительно умеет читать с устройства и файловой системы, содержащих / boot / grub. Он не сможет читать с зашифрованных устройств или из файловых систем, поддержка которых еще не добавлена в GRUB.