У меня проблема на сервере с 4 дисками по 1 ТБ под управлением Debian wheezy и GRUB 1.99-27 + deb7u3.
sda и sdb имеют разделы, зеркалированные с использованием (программное обеспечение Linux) RAID1, включая /boot. sdc и sdd имеют по одному разделу, отражая физический том LVM для данных. GRUB установлен в sda и sdb. я использовал mdadm к --fail и --remove sdc емкостью 1 ТБ и заменил старый диск (ST91000640NS) новым ST2000NX0243 емкостью 2 ТБ.
С новым приводом GRUB доходит до
GRUB loading.
Welcome to GRUB!
но не показывает меню. Индикатор диска на SDC горит постоянно, поэтому, предположительно, ядро GRUB пытается прочитать этот диск, даже если он не нужен для доступа к / boot / grub. Я пробовал два диска одной и той же модели, оба из которых отлично работают с smartctl, с тем же результатом. С пустым отсеком для sdc-диска все загружается нормально. Система загружается с активного USB-накопителя, и новый диск доступен, так что это не аппаратная несовместимость (*). Я уверен, что был удален sdc, и нет никаких указаний на то, что BIOS переупорядочил диски.
(*) это могло быть небезопасным предположением. Посмотри ответы.
Итак, у меня есть следующие связанные вопросы:
grub rescue> Подсказка? Может ли проблема 4K также помешать использованию диска для Linux RAID?Я думаю о 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-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 (boot) использует суперблок RAID версии 0.9, как и md1, md2 и md4 (это старые массивы). md3 супер 1.2, но не должен участвовать в загрузке.
Спасибо за предложения. После дальнейшего тестирования:
dpkg-reconfigure grub-pc, ничего не изменилось, и GRUB все еще зависает перед меню, когда новый диск подключен через SATA. Это не могло быть объяснено тем, что содержимое / boot / grub все равно не соответствует образу ядра. Точно так же физическая перестановка дисков не имеет значения.Welcome to GRUB! сообщения не печатаются - вместо этого доходит до смены графического режима. Он по-прежнему виснет при тех же условиях.debug переменная. Никакой полезной отладочной информации не выводится.grub-mkrescue из этой же системы тоже виснет.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 или любые соответствующие советы системного администратора.
Я собираюсь ответить на третью часть своего вопроса о процедуре установки GRUB с включенной отладкой. Я по-прежнему буду признателен за информированные предложения о том, где может заключаться проблема, или стратегии, которые можно решить с минимальным временем простоя и максимальной информацией о причине.
Некоторые общие моменты: GRUB предоставляет другие методы отладки - grub-mkrescue создаст .iso, который включает в себя все модули, которые могут вам понадобиться, так что, как живой USB, можно использовать для попытки перемещаться по массиву RAID и пытаться загрузить файл .cfg или даже ядро. В grub-emu эмулятор доступен в большинстве дистрибутивов, но больше ориентирован на то, как будет выглядеть меню. Более продвинутым является стандартный модуль GRUB для отладка с использованием gdb через последовательный кабель.
Итак, процедура получения отладочных сообщений описана в Руководство GRUB раздел 6, но не подробно. Первое, что вы можете рассмотреть, это выполнить отладку через последовательную консоль и запустить script перед screen для записи отладочных сообщений. Очевидно, вам нужны привилегии root. Обратите внимание, что компоновка диска в этом ответе не обязательно соответствует вопросу и является всего лишь примером. Предположим, что нормальный (не отладочный) 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! с последующими несколькими страницами отладочных сообщений перед отображением меню (или не в зависимости от обстоятельств).
Теперь я отвечаю на свой вопрос 1. Это проблема 4Kn («расширенный формат»)?
Да.
Диски 4Kn не так широко поддерживаются, как вы думаете; например, они несовместимы с Windows 7 или GRUB 1 или многими наборами микросхем Intel. В моем случае проблема связана с микросхемой контроллера южного моста Intel 82801I Enterprise (семейство ICH9) на материнской плате. Думаю, это тоже причина частичного отказа привода md_resync даже по USB. Анализ в приведенной выше ссылке, похоже, показывает, что драйвер Linux ata_piix отлично работает для 4Kn по сравнению с Intel ICH10, несмотря на отсутствие официальной поддержки со стороны Intel. Возможно, я нашел другое для ICH9. Я не проверял, может ли привод работать в режиме AHCI или SAS.
Информация о совместимости дисков может быть известна только производителю материнской платы или другому лицу, проводившему тщательный тест. Я слишком рано пришел к выводу, что «это не аппаратная несовместимость» только потому, что работают простые операции чтения и записи. Есть причина, по которой обновленный BIOS для этой материнской платы не поддерживает 4Kn: потому что материнская плата не делает это надежно.
Нет причин, по которым эквивалентный диск 512e не должен работать в таких ситуациях.
Чтобы ответить на ваш второй вопрос, есть ошибка, связанная с raid1 это было исправлено в 2.02.
Я надеюсь, что это поможет, даже если я не могу сказать, присутствовала ли эта ошибка до 2.02 ~ beta1 (версия, в которой сообщалось об ошибке).
редактировать: Кроме того, сразу после публикации этой статьи возник вопрос: является ли ваш RAID1 программным или аппаратным?