GRUB зависает перед меню, после обновления жесткого диска. Как отлаживать?
У меня проблема на сервере с дисками 4 x 1 ТБ, на которых запущены Debian wheezy и GRUB 1.99-27+deb7u3.
У sda и sdb есть разделы, зеркалированные с использованием (программного обеспечения Linux) RAID1, включая /boot
, У sdc и sdd есть по одному разделу, каждый из которых отражает физический том LVM для данных. GRUB установлен на sda и sdb. я использовал mdadm
в --fail
а также --remove
1 ТБ sdc и заменил старый диск (ST91000640NS) новым 2 ТБ ST2000NX0243.
С новым диском GRUB добирается до
GRUB loading.
Welcome to GRUB!
но не показывает меню. Индикатор диска на SDC горит постоянно, поэтому, предположительно, ядро GRUB пытается прочитать этот диск, даже если он не нужен для доступа к /boot/grub. Я пробовал два диска одной и той же модели, оба из которых хорошо работают с smartctl
с тем же результатом. При пустом отсеке для жесткого диска все загружается нормально. Система загружается с живого USB и новый диск доступен, так что это не аппаратная несовместимость (*). Я уверен, что это был sdc, который был удален, и нет никаких признаков того, что BIOS переупорядочил диски.
(*) это не могло быть безопасным предположением. Посмотри ответы.
Итак, у меня есть следующие связанные вопросы:
- Может ли измененный размер логического сектора (4096, а не 512 байт) вызывать проблемы, возможно, в поддержке RAID, встроенной в ядро GRUB? Почему бы мне не получить хотя бы
grub rescue>
незамедлительный? Может ли проблема 4K также помешать использованию диска для Linux RAID? - Какой самый быстрый способ решить это? [Предыдущие предложения включали: нужно ли переустанавливать GRUB с новым диском на месте, и в таком случае как? Будет ли GRUB спасательный USB (сделанный из той же системы) иметь такую же проблему? Это известная ошибка в GRUB, и я должен обновить? Ответы на эти вопросы: нет, да и нет.] Могу ли я постоянно настроить префикс образа GRUB, используемый Debian?
- Как можно было бы отладить этот этап GRUB? Это может быть чувствительно к тому, какие модули встроены, но как вы это выясните?
Я думаю о debug.cfg только с debug=all
и что-то вроде:
grub-mkimage -c debug.cfg -o dcore.img configfile normal raid fs multiboot
grub-setup -c dcore.img /dev/sda
Будет ли это работать? (Я обращаюсь к этому пункту 3 в своем собственном ответе, но зависание в моем случае, кажется, происходит до того, как активируется встроенная конфигурация.)
Подробнее о системе
В случае, если это помогает визуализировать, вот часть lsblk
выход:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 0 931.5G 0 disk
├─sdb1 8:17 0 957M 0 part
│ └─md0 9:0 0 956.9M 0 raid1 /boot
├─sdb2 8:18 0 9.3G 0 part
│ └─md1 9:1 0 9.3G 0 raid1 /
├─sdb3 8:19 0 279.4G 0 part
│ └─md2 9:2 0 279.4G 0 raid1 /var
└─sdb4 8:20 0 641.9G 0 part
└─md3 9:3 0 641.9G 0 raid1
├─vg0-home (dm-0) 253:0 0 1.4T 0 lvm /home
└─vg0-swap (dm-2) 253:2 0 32G 0 lvm [SWAP]
sdc 8:32 0 931.5G 0 disk
└─sdc1 8:33 0 931.5G 0 part
└─md4 9:4 0 931.5G 0 raid1
└─vg0-home (dm-0) 253:0 0 1.4T 0 lvm /home
sdd 8:48 0 931.5G 0 disk
└─sdd1 8:49 0 931.5G 0 part
└─md4 9:4 0 931.5G 0 raid1
└─vg0-home (dm-0) 253:0 0 1.4T 0 lvm /home
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 957M 0 part
│ └─md0 9:0 0 956.9M 0 raid1 /boot
├─sda2 8:2 0 9.3G 0 part
│ └─md1 9:1 0 9.3G 0 raid1 /
├─sda3 8:3 0 279.4G 0 part
│ └─md2 9:2 0 279.4G 0 raid1 /var
└─sda4 8:4 0 641.9G 0 part
└─md3 9:3 0 641.9G 0 raid1
├─vg0-home (dm-0) 253:0 0 1.4T 0 lvm /home
└─vg0-swap (dm-2) 253:2 0 32G 0 lvm [SWAP]
Это BIOS до 2010 года и не имеет возможности EFI.
Не имеет значения: в работающей системе следующее выдает ту же ошибку LVM от grub-probe 1.99, что и на grub-install, хотя, похоже, все работает (кажется, это исправлено в GRUB 2.02).
# grub-fstest /dev/sda cp '(loop0,msdos1)/grub/grub.cfg' grub.cfg
error: unknown LVM metadata header.
Методы отладки в ответе ниже показывают префикс образа, устанавливаемого в sd[ab]:
grub-mkimage -d /usr/lib/grub/i386-pc -O i386-pc --output=/boot/grub/core.img '--prefix=(mduuid/<UUID of sdN1>)/grub' biosdisk ext2 part_msdos part_msdos raid mdraid09
Я не знаю, почему "part_msdos" повторяется. Там нет таблиц gpt. md0 (загрузочный) использует суперблок RAID версии 0.9, как и md1, md2 и md4 (это старые массивы). md3 супер 1.2, но не должен участвовать в загрузке.
Обновить
Спасибо за предложения до сих пор. После дальнейшего тестирования:
- BIOS уже настроен на загрузку с использованием sda (ata1.00). После того, как GRUB был переустановлен на все диски с
dpkg-reconfigure grub-pc
, ничего не изменилось и GRUB по-прежнему зависает перед меню, когда новый диск подключен через SATA. Это не могло быть учтено тем, что содержимое / boot / grub не соответствует образу ядра. Точно так же физическая перестановка дисков не имеет значения. - Обновление до GRUB до 2.02 в Debian Jessie только приводит к тому, что
Welcome to GRUB!
сообщения не распечатываются - вместо этого они доходят до смены графического режима. Он все еще висит в тех же условиях. - Зависание, по-видимому, происходит до того, как встроенная конфигурация устанавливает
debug
переменная. Никакой полезной отладочной информации не выдается. - GRUB показывает меню при загрузке со съемного носителя, где префикс не использует UUID, и таким образом можно загрузить систему с физически присутствующим диском. Однако, TAB перечисление накопителей зависает. Как и ожидалось, цепная загрузка GRUB с жесткого диска зависает, как и раньше. Загрузка с USB-накопителя
grub-mkrescue
с той же системы тоже зависает. - В качестве отдельной ошибки в работающей системе (Linux 3.2.0-4-amd64) при попытке добавить новый диск 4Kn в массив RAID1 через внутренний SATA или USB приводит к
Bad block number requested
на устройстве, после чего система md отказывает диск,BUG: unable to handle kernel paging request
и ядро упс. (mdadm --remove
говорит, что сбойный элемент занят, и процесс md-resync не отвечает на SIGKILL. Я не пробовалecho frozen > /sys/block/mdX/md/sync_action
, Тестирование диска с помощьюdd
по SATA все выглядит нормально.). Конечно, драйверы Linux MD способны синхронизировать диск 4Kn со старыми дисками и не используют BIOS?
Таким образом, обходные пути могут включать монтирование не-RAID раздела как /boot/
; установка GRUB с аппаратно-зависимым префиксом; или перепрошивка BIOS. Наиболее разумная вещь, вероятно, заключается в том, чтобы связаться с поставщиком для замены дисков.
Другими словами, у вопроса 3 есть решение, неэффективность которого, возможно, является предметом запроса функции GRUB; вопрос 2 лаял не то дерево, поэтому я пересмотрел его; и вопрос 1, если это не слишком далеко от темы, теперь дополнительно о том, почему диск, очевидно, не может быть использован для Linux RAID.
Я был бы рад наградить вас достойным объяснением всего этого, кое-что об ошибке ресинхронизации RAID или анекдотами использования flashrom
для поддержки 4Kn, как сказать grub-install не использовать UUID или любые соответствующие советы системного администратора.
3 ответа
Сейчас я отвечаю на свой собственный вопрос 1. Это проблема 4Kn ("расширенный формат")?
Да.
Диски 4Kn не так широко поддерживаются, как вы думаете; например, они не совместимы с Windows 7, GRUB 1 или многими чипсетами Intel. В моем случае проблема заключается в чипе контроллера Intel 82801I Enterprise Southbridge (семейство ICH9) на материнской плате. Я думаю, что это также является причиной частичного сбоя привода к md_resync даже через USB. Анализ приведенной выше ссылки показывает, что драйвер Linux ata_piix работал нормально для 4Kn по сравнению с Intel ICH10, несмотря на отсутствие официальной поддержки Intel. Я мог бы найти по-другому для ICH9. Я не проверял, может ли привод работать в режиме AHCI или SAS.
Только производитель материнских плат или кто-то еще, кто провел тщательное тестирование, могут знать информацию о совместимости дисков. Я слишком рано пришел к выводу, что "это не аппаратная несовместимость" только потому, что сработали простые операции чтения и записи. Существует причина, по которой обновленный BIOS для этой материнской платы не поддерживает 4Kn: материнская плата не работает надежно.
Нет никаких причин, по которым эквивалентный диск 512e не должен работать в таких ситуациях.
Я собираюсь ответить на третью часть моего вопроса, о процедуре установки GRUB с включенной отладкой. Я все еще буду признателен за обоснованные предложения о том, в чем заключается проблема, или о стратегиях, которые необходимо решить с минимальным временем простоя и максимальным количеством информации о причине.
Некоторые общие моменты: GRUB предоставляет другие методы отладки - grub-mkrescue
создаст.iso, который включает в себя все модули, которые вам, возможно, понадобятся встроенные, так что можно использовать живой USB, чтобы попытаться перемещаться по массиву RAID и пытаться загрузить файл.cfg или даже ядро. grub-emu
Эмулятор доступен в большинстве дистрибутивов, но больше ориентирован на то, как будет выглядеть меню. Более продвинутым является стандартный модуль GRUB для отладки с использованием gdb
по последовательному кабелю.
Процедура установки GRUB с включенной отладкой
Итак, процедура получения отладочных сообщений упоминается в разделе 6 руководства по GRUB, но не подробно. Первое, что вы можете рассмотреть, это отладка через последовательную консоль и запуск script
до screen
записывать отладочные сообщения. Очевидно, вам нужны права суперпользователя. Обратите внимание, что расположение диска в этом ответе не обязательно соответствует вопросу и является лишь примером. Предположим, что обычный (не отладочный) GRUB установлен на другие диски соответствующим образом: это просто процедура установки отладочного GRUB на диск, который вы ожидаете загрузить. (Это означает, что сообщения отладки дают понять, какой диск загружается. Для установки в раздел RAID префикс, вероятно, будет одинаковым в обоих случаях, поэтому вы можете просто запустить одну и ту же команду для /dev/sda
как /dev/sdb
.)
Во-первых, проверьте, где находятся существующие файлы grub, /boot/grub
или более вероятно /boot/grub/<platform>
, В этом случае предположим, что они находятся в /boot/grub/i386-pc/
, Мы не будем изменять файлы, которые уже есть, но добавим дополнительный образ ядра с включенной отладкой. Если .cfg
файлы отсутствуют или были изменены, восстановить их как стандарт с grub-mkconfig -o /boot/grub/grub.cfg
,
Проверка установленных модулей и префикса
Быстрый и грязный способ показать, какие модули уже скомпилированы в образ ядра, - просто запустить grub-install
снова. Это работает в GRUB 2.02:
grub-install -v /dev/sda 2>&1 | grep '\(mkimage\|setup\)'
В простом случае без RAID или lvm это могло бы показать список как ext2 part_gpt biosdisk
, Однако GRUB 1.99 не использует -v
для многословия, так что используйте --debug
вместо. Мы совместим это с уловкой, чтобы на самом деле не устанавливать образ, чтобы сэкономить немного времени:
grub-install --debug --grub-setup=/bin/true /dev/sda 2>&1 | grep '\(-mkimage\|-setup\|true\)'
Обратите внимание, что grub-install
может запускать сценарии оболочки вместо вызываемых программ, поэтому вместо этого мы могли бы сделать что-то вроде:
# create grub-mkimage wrapper
cat > /usr/local/bin/grub-mkimage.sh <<"EOF"
echo Arguments to grub-mkimage: $*
/usr/bin/grub-mkimage $*
EOF
# create a dummy grub-setup
cat > /usr/local/bin/grub-setup.sh <<"EOF"
#!/bin/bash
echo Arguments are: $*
EOF
# run grub-install using the above
chmod u+x /usr/local/bin/grub-*.sh
grub-install --grub-mkimage=/usr/local/bin/grub-mkimage.sh \
--grub-setup=/usr/local/bin/grub-setup.sh /dev/sda 2>&1 \
| grep 'Arguments' | tee grub-args.txt
Пути, конечно, могут отличаться в зависимости от вашего дистрибутива и выбранной оболочки.
Установка переменной отладки
Теперь мы создаем файл, который мы можем вызвать debug.cfg
с настройками отладки. (Ядро генерирует нефатальную ошибку, если встречает комментарий на этом этапе, поэтому мы не будем его использовать.)
set pager=1
set debug='init modules disk ata,scsi,linuxefi,efi,badram,drivemap linux,fs,elf,dl,chain serial,usb,usb_keyboard,video'
set
Любая комбинация пробелов, ,
, ;
или же |
может использоваться для разделения имен модулей в строке.
Я извлек список средств отладки из источника GRUB 2.02 и заказал их семантически. 'all'
производит слишком много информации из памяти scripting
переводчик. Существуют дополнительные возможности для определенных файловых систем, таких как "xfs" и "reiserfs", а также "net", "partition" и "loader" ("loader" слишком поздно для того, что нас интересует, перед меню. Если мы можно получить меню, мы можем установить переменную отладки там.) К сожалению, в источнике 'mdraid_linux' нет сообщений отладки, но disk
показывает наиболее важные операции.
pager
переменная необходима для чтения отладочных сообщений, если вы не захватываете их через консоль (например, с помощью script
). Я нашел это pager
не работает без включения дополнительного модуля, такого как sleep
или же configfile
, что более чем вдвое увеличивает размер изображения. Переменная среды отладки вступает в силу независимо.
Установка
Теперь создайте вариант образа того, который вы хотите отладить:
grub-mkimage -p '(,msdos3)/boot/grub' -c debug.cfg \
-O i386-pc -o dcore.img -C auto ext2 part_msdos biosdisk
где список модулей из grub-install, который вы хотите отлаживать, и включает sleep
или что-нибудь еще, что вам нужно. Префикс -p
должны быть скопированы с вывода grub-install
также, как очевидно, это оказывает огромное влияние на то, что происходит после баннера GRUB. Однако вы можете поэкспериментировать с использованием кода устройства GRUB (как в этом случае), а не стандартного UUID. Вы можете показать UUID с lsblk -o NAME,TYPE,FSTYPE,LABEL,SIZE,STATE,UUID
или же ls -l /dev/disk/by-id/
и на дисках RAID с mdadm --detail /dev/sda
,
Теперь установите ядро, которое было только что создано, на тот диск, который обычно загружается:
cp dcore.img /boot/grub/i386-pc
grub-bios-setup -d /boot/grub/i386-pc -c dcore.img /dev/sda
Для версий GRUB до 2.0 grub-bios-setup
команда все еще может быть вызвана grub-setup
как в руководстве.
Перезагружать. Вы должны увидеть Welcome to GRUB!
затем несколько страниц отладочных сообщений перед отображением меню (или не так, как может быть).
Чтобы ответить на ваш второй вопрос, есть ошибка, связанная с raid1, которая была исправлена в 2.02.
Я надеюсь, что это поможет, даже если я не могу сказать, была ли эта ошибка или не присутствовала до 2.02~beta1 (версия, в которой сообщалось об ошибке).
edit: Кроме того, сразу после публикации возник вопрос: ваш RAID1 - программный или аппаратный RAID?